OO-programming vs tabellen

[anoniem]

Momenteel ben ik bezig met het onder de knie krijgen van Object Oriented programmeren. Dan werk je met Classes en Objecten e.d. Nu heb ik een relationele database als basis. Neem eens het volgende voorbeeld In een raltionele database heb ik bijvoorbeeld de tabellen: Personen en Cursisten. In de tabel Cursisten staan extra gegevens die een gewoon persoon niet heeft als hij/zij geen cursist is het is dus een 1 op 1 relatie tblPersonen [b:f4e861086f]PersoonID (PK)[/b:f4e861086f] DateCreated Voornaam Achternaam Gebdatum etc etc tblCursisten [b:f4e861086f]CursistID (PK)[/b:f4e861086f] DateCreated PersoonID (FK) InternPostvak InternEmail etc etc in OO heb je dan als BaseClass Persoon en als inherited Class de cursist. maar wat doe je dan met die FK die wel in de tabel van Cursist staat? En met DateCreated. als iemand me snapt dan graag je advies :-) ps het gaat mij er om, om het strikt volgens de regels op te lossen en niet 'zogenaamd' slim

[anoniem]

In principe kun je alle velden van de database ook in de klasse opnemen. Daarbij kan het voorkomen dat twee members van de klasse Cursist per definitie gelijk zijn. Als dat het geval is, neem je dat veld slechts op in de basisklasse. In dit voorbeeld bijvoorbeeld DateCreated. Dit levert een member in de klasse Persoon op, zeg "pDateCreated". Omdat DateCreated ook een veld van Cursist is, levert die ook een member op in de klasse Cursist met de naam "cDateCreated". De "p" en de "c" voor de naam heb ik gekozen omdat de namen verschillend moeten zijn. Ik veronderstel nu dat pDateCreated == cDateCreated voor alle cursisten. Dan kan ik cDateCreated verwijderen uit de klasse, en overal waar je cDateCreated gebruikte deze vervangen door pDateCreated. Als ik het goed begrijp is PersoonID (FK) in de tabel CursistID vergelijkbaar met een pointer naar een Persoon. Deze pointer wijst echter per definitie naar zichzelf omdat een Cursist een het bijzonder een persoon is, en wel die persoon die in het veld PersoonID (FK) van de tabel CursistID staat. Dus overal waar je die pointer gebruikt kun je de pointer "this" (afhankelijk van de gekozen OO-taal) gebruiken (de pointer "this" verwijst naar zichzelf, dus praktisch heb je die pointer niet eens nodig). Minder members betekent minder geheugen per object en is dus beter.

[anoniem]

[quote:132fd9f77d="M Kelder"]Minder members betekent minder geheugen per object en is dus beter.[/quote:132fd9f77d] Interessante uitspraak... Misschien kan je door iets meer memberdata op te slaan wel runtime een hoop berekeningen besparen, waardoor je performance juist omhoog gaat. Is je geheugengebruik inderdaad wel hoger, maar het is geen slechtere oplossing... Onthoud: [i:132fd9f77d]"Premature optimization is the root of all evil"[/i:132fd9f77d] :wink:

[anoniem]

[quote:769e2de9b0="Capone"][quote:769e2de9b0="M Kelder"]Minder members betekent minder geheugen per object en is dus beter.[/quote:769e2de9b0] Interessante uitspraak... Misschien kan je door iets meer memberdata op te slaan wel runtime een hoop berekeningen besparen, waardoor je performance juist omhoog gaat. Is je geheugengebruik inderdaad wel hoger, maar het is geen slechtere oplossing... Onthoud: [i:769e2de9b0]"Premature optimization is the root of all evil"[/i:769e2de9b0] :wink:[/quote:769e2de9b0]Akkoord, het is zeker niet zo dat geheugengebruik altijd geoptimaliseerd moet worden, desnoods ten kosten van het CPU-gebruik. In dit geval is het natuurlijk wel waar, omdat het verwijderen van de members die ik aangaf runtime geen tijd kost.

[anoniem]

[quote:1e8545346e] in OO heb je dan als BaseClass Persoon en als inherited Class de cursist. [/quote:1e8545346e] Waarom doe je dat zo ? Er is namelijk geen regel die je verplicht om de cursist van de persoon af te leiden. Sterker nog ... het is beter om dat niet te doen, omdat je dan niet meer verplicht bent om cursisten personen te laten zijn. Dat klinkt misschien vreemd, maar het levert (straks) wel vrijheid op. Wat als je besluit dat je verschillende soorten cursisten hebt ? Als je keihard die link naar 'persoon' hebt gelegd dan zul je je complete data-structuur/code moeten herzien om daar iets anders dan een persoon aan te koppelen. De relatie leg je toch al (via je Foreign Key). Zo'n Foreign-Key betekent niks meer dan dat je binnen je klasse een property krijgt van het type waar je heen verwijst. In dit geval krijg je dus een Cursist met een property van het type Person. Het enige gemeenschappelijke dat is dat beiden een 'dateCreated'-veld hebben. Je krijgt dus een constructie als [basis Data object] -> [Persoon-klasse] [basis Data object] -> [Cursist-klasse] Dat geeft je straks voordelen als je lessen en roosters wilt hebben want alle objecten krijgen gaan dan vanzelf hun 'dateCreated' bijhouden. Nog een reden om het niet te doen ? Als je klassen van elkaar afleid dan is de verleiding groot om die allemaal in een tabel te gooien met alle overbodige lege velden tot gevolg. En een ander probleem ... wat als je besluit om een ander soort database te gebruiken ? Overigens zijn er al componenten die zoiets 'automatisch' oplossen. Je wilt eigenlijk niet weten hoe 'makkelijk' het kan worden. btw : Ik weet niet in hoeverre je .Net kent maar je zou eens op zoek moeten gaan naar info over Linq. http://netfx3.com/content/LINQHome.aspx

[anoniem]

Zoals ik al zei, ik ben het aan het leren. Toen ik ermee begon vroeg ik me meteen al af waarom ik eigenlijk een klasse Persoon en Cursist zou maken. Ik zie een tabel als een klasse. Daar staat alles al in. De gegevens bind je aan de klasse FormView, DetailsView of wat dan ook. Waarom doe ik dit zo vraagt Jafo...tja, dit doe ik zo n.a.v. lessen die ik volg. Daar hebben ze als BaseClass Product. Inherited Classes zijn dan bijvoorbeeld Car, Book en Dvd. Product heeft als properties: ID, Name etc.. Een Car heeft als extra properties Merk, Bouwjaar etc. Een boek zoiets als Publicatiedatum. Mijn 'probleem' is dat ik voor elke Cursist en Docent bij moet houden wanneer het is aangemaakt. Maar ook voor Person. Stel je ook voor dat ik moet bijhouden wie een persoon en cursist of docent heeft aangemaakt. Laat ik in iedere geval een ding vaststellen, een Klasse Cursist is nutteloos zonder een Klasse Person. Zo ook de Klasse Docent. Stel je voor, ik heb een webservice die Persoonsgegevens aanlevert. Dan kan ik daar door een klasse Cursist te gebruken er een cursist van maken. Of met de klasse Docent er een docent van maken. Maar ik stel de vraag niet voor niets, ik pretendeer niet het goed te doen. Daarom vraag ik het jullie juist :D

[anoniem]

[quote="JaFO"][quote:53cf84f9e2] btw : Ik weet niet in hoeverre je .Net kent maar je zou eens op zoek moeten gaan naar info over Linq. http://netfx3.com/content/LINQHome.aspx[/quote:53cf84f9e2] 1. Linq is heel mooi maar ik moet straks "oude" bestaande applicaties kunnen aanpassen en die werken vast niet met linq. 2. Linq wordt wellicht niet ondersteund door providers (maar dit is een aanname van mij, dat weet ik niet zeker.) ps. ik maak websites met ASP.NET en C#

[anoniem]

Linq is een onderdeel van .Net/C# Het is niks meer/minder dan weer een setje standaard features die je 'gratis' krijgt zodra je .Net versie 3.5 kunt ondersteunen. Op dat punt is MS echt bizar snelle stappen aan het maken. Of je dat zelf kunt gaan gebruiken ligt er aan wie beslist welke provider er wordt gekozen. Als je vast zit aan een specifieke provider doordat een klant dat 'eist' dan heb je pech. Maar dat probleem kom je in zekere zin zowiezo al tegen omdat je een provider moet hebben die ASP.Net ondersteunt. [quote:e5eb78e888] Maar ik stel de vraag niet voor niets, ik pretendeer niet het goed te doen. [/quote:e5eb78e888] Het probleem is dat er geen 'goed' of 'fout' antwoord is. Dat hangt echt af van het doel van je applicatie en hoe flexibel je straks wilt of moet kunnen zijn. Hierdoor is het moeilijk om je 'de' oplossing aan te reiken en krijg je net zo veel verschillende methodes als er antwoorden worden gegeven. Er is op zich niks mis mee met het idee om iedere tabel rechtstreeks als object-klasse te zien, want bij een genormaliseerde database zijn tabellen meestal redelijk zelfstandige onderdelen. Het enige 'probleem' van die aanpak is dat je het model en de data in een enkele klasse dumpt. Je kunt namelijk een stap verder gaan en dat splitsen door gebruik te maken van een 'data-provider'. Die manier van werken is wellicht iets te 'slim' en te flexibel voor jou op dit moment. Microsoft zelf gebruikt het data-provider-model overigens vrij vaak dus het kan heel handig zijn om daar bekend mee te worden. Het voert iets te ver om dat even uit te leggen maar als je Googled op 'data provider model' of boeken zoekt over design patterns dan kom je daar meer over te weten. Het is echter wel een flinke stap richting geavanceerd OO ontwerp ... Dat je datums wilt bijhouden voor je onderdelen (zoals cursist, docent, etc.) is eigenlijk vrij logisch, want het levert je straks heel veel extra informatie tijdens het debuggen op (wie schreef die cursist weg, wie wijzigde hem, etc.) en zo. Een ander probleem waar je zeker tegen aan zult lopen is dat het niet altijd loont om het geheel zelf uit te zoeken. Er bestaan bijvoorbeeld componenten die de hele link naar de database en de bijbehorende tabellen voor hun rekening nemen. Zo is er bijvoorbeeld [url=http://www.devexpress.com/Products/NET/Libraries/XPO/]eXpress Persistent Objects van DevExpress[/url]. Wat je daar mee kunt is gewoon te ziek voor woorden en het is iets dat ter zijner tijd beslist onderdeel van .Net gaat worden in de vorm van Linq. Overigens ... ik ben zelf geen Asp.Net expert, maar ik pik een hele hoop op van een collega die daar wel dagelijks mee werkt en die heeft mij al heel wat laten zien op dat punt. Vandaar dat ik XPO al ken en in gebruik heb gezien.

[anoniem]

Dat XPO is precies wat ik wil van OO. En als ik XPO zo snel even bekeken heb dan snap ik dat meteen. Binnen Visual Studio kun je een zogenaamde Class Diagram maken. Maar hoe je relaties legt tussen de verschillende Classes is me niet duidelijk en wellicht is dat ook niet mogelijk. eh...ik begin net met OO, onhoud dat :wink: Maar ik [i:d7d4203731]denk [/i:d7d4203731]relationele database. ik [i:d7d4203731]leef [/i:d7d4203731]relationele database. Als ik een screenshot zie van een relationele database dan snap ik het systeem in enkele seconden. Mits goed gemaakt uiteraard. Als ik een webapplicatie moet maken dan denk ik altijd, maak een relationele database en trek het een jasje aan. Maar, je hebt gelijk, is er is niet slechts één juiste manier. Daartegenover staat: Onderzoek heeft uitgewezen dat 80% van de software - gemaakt door de zogenaamde [i:d7d4203731]knappen koppen[/i:d7d4203731] - niet doet wat het moet doen. Een goed voorbeeld daarvan is; software geschreven voor de logistiek binnen een distributiecentrum. Er zijn 500 distributiecentra in Nederland en allemaal hebben ze hun eigen maatoplossing. Terwijl ik dan denk. Er komen spullen binnen, worden tijdelijk opgeslagen en gaan er weer uit. Hoe kun je daar 500 manieren voor bedenken? Men zegt dan: elk distibutiecentrum heeft zijn eigen manier. Ik zeg dan: neen, het systeem is voor elk gelijk: ontvang spullen, sla ze op, voer ze uit. Dat is maar een manier. En meer zijn er ook niet. Een andere gerelateerd probleem is het volgende: Ik maak de Class Persons etc. Maar nu wilde ik dit aan een GridView koppelen. Weg Sorting en weg Paging. Moet ik dat zelf maken. Is dit dan niet het paard achter de kar spannen?

[anoniem]

[quote:95cb793d05="Wiep Corbier"]Dat XPO is precies wat ik wil van OO. En als ik XPO zo snel even bekeken heb dan snap ik dat meteen. Binnen Visual Studio kun je een zogenaamde Class Diagram maken. Maar hoe je relaties legt tussen de verschillende Classes is me niet duidelijk en wellicht is dat ook niet mogelijk. eh...ik begin net met OO, onhoud dat :wink: [/quote:95cb793d05] Een 'relatie' leg je doordat je in plaats van een property van een 'simpel' type (zoals een integer) je een property van de gewenste klasse maakt. Je krijgt dan in principe een 1 op 1 relatie tussen de twee klassen (in het class diagram aangeduid als een 'association' ). Als je een 1 op n relatie (een rooster met leerlingen bijvoorbeeld) dan heb je een verzameling nodig. In C# gaat dat simpel door gebruik te maken van een van de vele generieke collecties. De simpelste is List. Je zou dat dan definieeren als "List<Leerling> leerlingenlijst;" [quote:95cb793d05]... Daartegenover staat: Onderzoek heeft uitgewezen dat 80% van de software - gemaakt door de zogenaamde [i:95cb793d05]knappen koppen[/i:95cb793d05] - niet doet wat het moet doen. Een goed voorbeeld daarvan is; software geschreven voor de logistiek binnen een distributiecentrum. Er zijn 500 distributiecentra in Nederland en allemaal hebben ze hun eigen maatoplossing. Terwijl ik dan denk. Er komen spullen binnen, worden tijdelijk opgeslagen en gaan er weer uit. Hoe kun je daar 500 manieren voor bedenken? Men zegt dan: elk distibutiecentrum heeft zijn eigen manier. Ik zeg dan: neen, het systeem is voor elk gelijk: ontvang spullen, sla ze op, voer ze uit. Dat is maar een manier. En meer zijn er ook niet. [/quote:95cb793d05] 500 programmeurs en je hebt minimaal 500 oplossingen die net iets anders zijn. ;) De meeste systemen doorlopen een soort van evolutie naar mate het bedrijf groeit en de eisen veranderen. Je zult het bij het bouwen van databases ook gezien hebben. [quote:95cb793d05] Een andere gerelateerd probleem is het volgende: Ik maak de Class Persons etc. Maar nu wilde ik dit aan een GridView koppelen. Weg Sorting en weg Paging. Moet ik dat zelf maken. Is dit dan niet het paard achter de kar spannen?[/quote:95cb793d05] Het sorteren/groeperen/etc. zit in de collectie-klasses ingebouwd, afhankelijk van het soort dat je hebt gebruikt. Je hoeft dus niet zelf een klasse "Persons" te schrijven,want op zijn simpelst is dat gewoon List<Person>. Zo lang je Gridview deze lijst ziet zal het sorteren van de lijst er voor moeten zorgen dat het grid de 'nieuwe' volgorde toont. Het voert mij even te ver om dat tot in detail uit te leggen, want C# boeken doen dat toch veel en veel beter.