algemeen: programmeren met interfaces

[anoniem]

Hallo, Ik zit met een vraag: Ik heb een ontwerp van een programma hierin heb ik een datalayer bedacht waarin een aantal klasses zitten zoals: User, House, etc.. Deze datalayer praat met een database. Bovenop deze datalayer ligt een programlayer deze bevat dezelfde klasses deze linken dan eigenlijk direct naar de datalayer. Waarom dan de datalayer? Ik wil de mogelijkheid houden om de datalayer te maken voor bv. een filesysteem, SQLite, MySQL, Oracle and so on... Nu zit ik met het volgende probleem: Hoe pak je dit aan? Ik dacht het volgende: Je wilt eigenlijk een 'interface van interfaces'. Daarmee bedoel ik al de datalayer klasses worden als interface voorgesteld en je implementeert ze voor een specifieke optie. Je wilt echter wel zeker weten dat ze er allemaal zijn daarom: interface van interfaces. Ik heb alleen geen idee hoe zoiets eruitziet. Ik dacht aan het volgende: Voor iedere klasse een interface dus bv: IUser,IHouse,I... Je zou dan de klasses (die deze dus implementeren) als volgt krijgen MySQLUser,FileUser,.. In het programma zou dit er dan bv uitzien als: IUser user = new MySQLUser() Dan heb je echter altijd in je programma die naamsafhankelijkheid. De vragen zijn dus: 1. Hoe voorkom je die naamsafhankelijkheid 2. Hoe kun je ervoor zorgen dat 1 implementatie dus bv MySQL* ook daadwerkelijk alle interfaces implementeert? 3. Is het slim om de verschillende implemenaties over dll's te verdelen? En waar laat je dan de interface specificatie? Oh ja trouwens: het wordt waarschijnlijk in C# geimplementeerd. Bedankt en groet, Marcel

[anoniem]

C# he? Okay, waarom zou je interfaces gebruiken? Nou, simpel. Via een interface wordt het object achter deze interface gewoon gemaskeerd. De zogenaamde black box. Je krijgt alleen maar toegang tot dit object via hetgeen de interface je aanbiedt. Wat je verder alleen maar hoeft te doen is objecten maken die deze interface ondersteunen. Hoe deze objecten de interface ondersteunen is voor het gebruik ervan helemaal niet meer van belang. Je bent nu bezig met multi-tier programmeren. Dit betekent dat je programma in diverse lagen wordt opgedeeld en ieder laag biedt bepaalde functionaliteit. Maar nu wil jij graag dat de database layer onafhankelijk blijft van de gekozen database. Tja, daar bestaat eigenlijk al iets voor en dat heet ADO.NET waarmee je dus met iedere willekeurige database kunt communiceren. Dat is in principe de extra layer die jij wilt hebben. Je kunt of voor ADO kiezen of je maakt een soortgelijke layer waarmee je datalayer kan communiceren. Dit betekent dus een generieke interface die is verbonden met de database naar keuze. Je geeft vanuit de database layer een Query of andere opdracht naar deze layer en de layer kijkt naar de geselecteerde database en levert de gevraagde gegevens op. Dus geen MySQLUser componenten of zo maar gewoon een User component. Goed, je vragen: 1) Naamsafhankelijkheid is niet te voorkomen als je 1 interface gebruikt die door meerdere objecten wordt ondersteunt. Je zult immers moeten aangeven welke interface je dient te gebruiken. Wel zou je deze class types in een array kunnen opnemen en dan het juiste type selecteren op basis van de index. Class type uitlezen en er een nieuw object van maken. Simpel. 2) Wel, als dit niet het geval is krijg je zeer waarschijnlijk een runtime error. Verder gewoon een kwestie van netjes programmeren. 3) Verdelen over meerdere DLL's? Verdeel het dan liever over meerdere assemblies want die kun je dan vervolgens laden in je uiteindelijke applicatie. Bovendien, door functionaliteit over assemblies te verdelen zijn deze ook bruikbaar vanuit andere .NET talen.

[anoniem]

1 [url=http://www.dofactory.com/Patterns/PatternAbstract.aspx](abstract) factory[/url] 2 waarschijnlijk gesteld met het oog op andere ontwikkelaars(?): goede documentatie schrijven. 3 kan: prog.data.dll (interfaces), prog.data.mysql.dll (mysql impl.), prog.data.mssql.dll (sql server impl.) maar in't algemeen kun je voor ooa, ood en oop veelal de zeer uitgebreide en door sun ter beschikking gestelde resources (patterns catalog, reference apps etc.) doorspitten. uiteraard is (het oop gedeelte, iig) java specifiek. hetgeen jij wilt verwezenlijken wordt bijv. [url=http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html]hier[/url] zeer uitgebreid behandeld.