[OO] Static-Methods of Static-Prop van een Non-Static-Classe

[Don Kedero]

Het psychologisch probleem doet zich voor in de volgende situatie, maar kan zich gerust op andere plaatsen voordoen daar het een persoonlijke manier van werken is. Ik vroeg mij dan ook af welke manier jullie prefereren. Ik tracht het te illustreren met het volgende voorbeeld:

• DA (DataAccess; namespace)
• DA.XmlProvider : IProvider (class)
• DA.SqlProvider : IProvider (class)

• BC (BusinessComponent; namespace)
• BC.Klant (class)
• BC.Afspraak (class)

• DE (DataEntities; namespace)
• DE.Klant (class)
• DE.Afspraak (class)

Oplossing 1: (static methods van een static-classe):

- BC.Klant.Detail(IProvider provider, int nummer)
- BC.Klant.Lijst(IProvider provider)
- BC.Klant.Opslaan(IProvider provider, DE.Klant klant)
- BC.Afspraak.Detail(IProvider provider, int nummer)
- BC.Afspraak.Lijst(IProvider provider)
- BC.Afspraak.Opslaan(IProvider provider, DE.Afspraak afspraak)

Ik kan van overal in mijn code zaken doen met Klant en Afspraak mits ik een Provider meegeef. Op sommige plaatsen gebeuren er heel wat acties met deze klasses, en is het meegeven van die provider toch een beetje overkill (denk ik).

Oplossing 2: (static properties van non-static-classes)

• Manager (namespace)
• Manager.BusinessComponent (class)
• Manager.BusinessComponent.Klant (property)
• Manager.BusinessComponent.Afspraak (property)

Ik kan van overal in mijn code zaken doen met Klant en Afspraak, de eerste maal dat ik deze property aanspreek wordt er een instantie gemaakt van BC.Klant met als constructor argument de Provider. op deze manier wordt mijn code iets overzichtelijker.

[mulder]

Wat is je doel, static classes? Beide oplossingen komen nogal vaag over imho?

[Don Kedero]

Mijn doel is om "makkelijk" te werken, dus niet telkens een instantie aanmaken van mijn "Provider" die toekennen aan elke methode die ik aanroep in mijn "BusinessComponent"-classes (want dit is infeite altijd hetzelfde). Maar gewoon op 1 lijn kunnen zetten van 'haal nu alle klanten op'. En ervoor te zorgen dat ik de code uiteraard van overal op dezelfde manier kan aanspreken. (en dit gaat met beide manieren)

Maar hiervoor zijn er verschillende manieren, een Static-Property die aan Lazy Loading doet, en mijn "BC.Klant" instanciëerd wannner nodig (met provider, en dit in een in een variabele steek zodat dit maar 1 malig gebeurd). Of in mijn "BC.Klant" static methods maken, en telkens mijn provider meegeven?

Het is misschien een beetje een knoop in mijn gedachten?

[ Voor 5% gewijzigd door Don Kedero op 03-09-2010 11:06 ]

[mulder]

Gebruik je die Providers doorelkaar in je applicatie of is dat ter illustratie? Misschien het Factory Pattern toepassen?

[Don Kedero]

Nee die gebruik ik niet door elkaar, het is gewoon de bedoeling dat de applicatie bijvoorbeeld met SQL databases overweg kan alsook met ODBC of met XML-files (dit zou in een configuratie staan per applicatie). En dit zou de provider afhandelen via een Interface (IProvider)

Infeite is mijn 'property' toch wel ergens een soort van Factory pattern, want daar wordt er een instantie gemaakt voor mijn BC (en wordt deze in een variabele geplaatst zodat ik infeite met een soort van Singelton werk). Of sla ik de bal volledig mis?

[ Voor 5% gewijzigd door Don Kedero op 03-09-2010 11:25 ]

[B-Man]

Don Kedero schreef op vrijdag 03 september 2010 @ 11:25:
Nee die gebruik ik niet door elkaar, het is gewoon de bedoeling dat de applicatie bijvoorbeeld met SQL databases overweg kan alsook met ODBC of met XML-files (dit zou in een configuratie staan per applicatie). En dit zou de provider afhandelen via een Interface (IProvider)

Infeite is mijn 'property' toch wel ergens een soort van Factory pattern, want daar wordt er een instantie gemaakt voor mijn BC (en wordt deze in een variabele geplaatst zodat ik infeite met een soort van Singelton werk). Of sla ik de bal volledig mis?

Als je afhankelijk van een property een implementatie wil instantieren, waarbij de gebruiker enkel tegen een interface aan programmeert, dan heb je inderdaad een factory nodig op de plaats waar je de instance "maakt".
Je kunt overwegen om direct met Dependency Injection aan de slag te gaan. Indien je met Java werkt is bijvoorbeeld Google Guice interessant.