Hoe noem je je klassen?

[RickyHeijnen]

Sinds kort ben ik overgestapt naar OOP programmeren in PHP omdat ik met grote projecten aan de slag wil gaan, maar nu ik ermee wil beginnen loop ik tegen het volgende aan...

Ik weet precies hoe klassen, objecten en methodes werken, dat is allemaal geen probleem, het OOP zit er hier wel goed in. Ik weet alleen niet waarvan ik nu allemaal een klasse moet maken, hoe noem je die klassen en wat stop je in die klasse en waarvan maak je weer een nieuwe klasse??

Ik had al een beetje gezocht en kwam uit op Object Oriented Thinking / Object Georienteerd Denken, maar kan iemand mij een beetje in de richting sturen. En daarbij ook de vraag, hoe doen jullie dat, hoe beginnen jullie als je een klasse maakt?

[BasieP]

als je een OO ontwerp maakt zal je zien dat je bijv een klasse 'persoon' hebt.
hier staan de gegevens in van 1 persoon

daarnaast heb je een manager class voor somige classes.
zo zou persoon een manager class 'persoonManager' of 'persoonsManager' kunnen hebben.

hierin staan meerdere objecten van de classe 'persoon'

nu vraag ik mij ook wat af.
hoe heb jij ooit OOP geleerd zonder je classes namen te geven?

[Exirion]

BasieP schreef op zaterdag 19 november 2005 @ 21:55:
nu vraag ik mij ook wat af.
hoe heb jij ooit OOP geleerd zonder je classes namen te geven?

Idd, elke uitleg over OOP begint met voorbeelden daarvan

[EfBe]

Class, niet 'klasse'. Altijd engelse namen gebruiken, je weet nooit wie aan je code gaat werken over een jaar of 2 jaar. Een class vormt de definitie voor een object dat iets doet. Een class 'Person' is eigenlijk de definitie voor de container die de data die semantisch een 'persoon' representeert kan bevatten. Dus representeert het object een persoon. Dat illustreert overigens een object waarin geen behavior hoeft te zitten anders dan data management. Daarnaast heb je behavior classes, zoals de bovengenoemde PersonManager.

[tombo_inc]

ik moet eerlijk zeggen dat ik hier soms ook moeite mee heb. maar je moet eigenlijk gewoon heel simpel nadenken over wat voor object de klasse voorsteld. om maar een dwarsstraat te noemen:
als je een database abstractie laag gaat maken, dan noem je je baseclass bijvoorbeeld "DAL", en afgeleiden daarvan bijvoorbeeld "mysqlDAL".

[NMe]

zoetericky schreef op zaterdag 19 november 2005 @ 21:51:
Ik weet alleen niet waarvan ik nu allemaal een klasse moet maken,

Alles dat je als object kan zien, al dan niet tastbaar.

hoe noem je die klassen

Een zelfstandig naamwoord dat beschrijvend is voor wat je met de klasse doet.

en wat stop je in die klasse

Alles wat relevant is voor dat object. Voor een fiets hoef je niet op te slaan welke kleur de lucht is, wel hoeveel wielen hij heeft.

en waarvan maak je weer een nieuwe klasse??

Alles wat duidelijk te onderscheiden is als "iets anders". Om het voorbeeld van die eeuwenoude fiets maar weer aan te halen: wielen zou je vaak in een andere klasse zetten.

[whoami]

Het is niet omdat je weet hoe het syntaxtisch en semantisch allemaal in elkaar steekt, dat 'OOP hier wel goed zit'.
OOP is vooral een 'denkwijze', en het is die denkwijze die je onder de knie moet hebben, en niet alleen het 'hoe je een class in taal X moet schrijven'. Ik denk dat het daarom wel aan te raden is, dat je eens een goed boek zoekt over object georienteerd design ofzo (en dus niet taal specifiek).
Misschien heb je hier of hier wel wat aan. _{snel ff gegoogled, heb dit specifiek document zelf nooit gelezen; het is dan wel gericht op Java, maar ik denk dat het je wel moet helpen om de concepten te begrijpen}

EfBe schreef op zaterdag 19 november 2005 @ 22:06:
Dat illustreert overigens een object waarin geen behavior hoeft te zitten anders dan data management. Daarnaast heb je behavior classes, zoals de bovengenoemde PersonManager.

Dat is toch afhankelijk van hoe je ertegen aankijkt. Je kan evengoed behaviour in dezelfde class hebben, ipv met 2 classes te gaan werken.

[ Voor 51% gewijzigd door whoami op 19-11-2005 23:21 ]

[prototype]

zoetericky schreef op zaterdag 19 november 2005 @ 21:51:
Sinds kort ben ik overgestapt naar OOP programmeren in PHP omdat ik met grote projecten aan de slag wil gaan, maar nu ik ermee wil beginnen loop ik tegen het volgende aan...

Het is vaker gezegd, maar php is nou niet per definitie de taal om OO vaardigheden op te doen. Enkele inconsistenties zijn daar de oorzaak van, maar met een beetje geluk zullen die in versie 6 verholpen zijn (?). Zie PHP toekomst development topic.

Ik weet precies hoe klassen, objecten en methodes werken, dat is allemaal geen probleem, het OOP zit er hier wel goed in. Ik weet alleen niet waarvan ik nu allemaal een klasse moet maken, hoe noem je die klassen en wat stop je in die klasse en waarvan maak je weer een nieuwe klasse??

Hehe, het weten hoe klassen, objecten en methodes syntactisch werken wil idd nog niet zeggen dat je weet hoe het OOP gebeuren in elkaar steekt. De vragen die je stelt getuigen er namelijk van, zoals wat stop je nou precies in een class. Dat is nou precies een van de dingen waar het om gaat bij goed OOP, namelijk abstractie, compositie, overerving etc...
De naam zegt het al, object orientatie. Je gaat je orienteren op objecten, en zoals in de echte wereld hebben objecten een naam, i.e. Computer, Persoon, Dier, Hond etc.. Al deze objecten kunnen abstracties zijn, i.e. Hond is minder abstract dan Dier, en daardoor concreter. Je zegt dan dat Dier een supertype is van Hond, en andersom Hond een subtype is van Dier, maar een Kat b.v. ook etc... Zowel een hond als een kat hebben dus iets gemeen met elkaar in dat ze een dier zijn, en misschien deze eigenschappen 'erven' of 'implementeren'. Het is aan jou om bij het ontwerpen dergelijke typeringen in de praktijk te brengen en hier slim gebruik van te maken bij het programmeren. Je modeleert classes naar het abstractieniveau dat vereist wordt van het systeem, i.e. je gaat alleen de dingen opnemen die van belang zijn voor de werking. Zo is voor een forum systeem b.v. alleen van belang dat er van een Gebruiker bekend is wat zijn naam is etc..., maar niet wat zijn schoenmaat bijvoorbeeld is, tenminste dat hangt af van de eisen die je aan het systeem stelt.
Compositie is ook een belangrijk punt, in dat je inziet dat je uit bestaande classes nieuwe classes kunt verkrijgen. Zo bestaat een Hond bijvoorbeeld uit Organen, en specifieker wel b.v. een Hart etc..
Om een lang verhaal kort te maken, OOP is niet alleen syntactisch weten hoe je een class moet maken etc... maar het is eerder een manier van denken.

[SH4D3H]

En toch zijn de genoemde voorbeelden van een dier of fiets een stuk makkelijker te "ontleden" dan bijv. een forum. Ik zou niet zo 1-2-3 een forum kunnen indelen in de verschillende onderdelen denk ik.

En dat zal het stuikelblok voor de meesten wel zijn, daar in de meeste tutorials dieren of fietsen ( dingen die je wel direct begrijpt ) gebruikt worden en niet echte praktijkvoorbeelden zoals het forum.

[JHS]

SH4D3H: Message, Topic, Forum, Catagory, User ? En dan zijn er natuurlijk vast nog een stuk meer, maar hier heb je de belangrijkste wel mee gehad .

[maurad3r]

JHS schreef op zondag 20 november 2005 @ 11:11:
SH4D3H: Message, Topic, Forum, Catagory, User ? En dan zijn er natuurlijk vast nog een stuk meer, maar hier heb je de belangrijkste wel mee gehad .

En ook een forum ala react (dit forum dus ) is zo opgebouwd? Tot op zo'n diep niveau als een bericht? Is het wel nuttig om tot zo'n diep niveau door te boren met klassen? Ik vind het ook altijd lastig om met server side talen (ook php in mijn geval) te bepalen welke entiteiten een klasse moeten zijn en welke niet.

Neem nu een webshop: moet je dan bijvoorbeeld ook een klasse product maken? En moet je in die klase zelf al gegevens uit de database halen of moet dat de eindgebruiker van die klasse doen? Met een server side taal lijkt het mij altijd zo'n overhead omdat je de klasse maar heel weinig gebruikt aangezien hij na iedere actie weer herladen moet worden.

[PrisonerOfPain]

Maurad3r schreef op zondag 20 november 2005 @ 12:58:
Neem nu een webshop: moet je dan bijvoorbeeld ook een klasse product maken? En moet je in die klase zelf al gegevens uit de database halen of moet dat de eindgebruiker van die klasse doen? Met een server side taal lijkt het mij altijd zo'n overhead omdat je de klasse maar heel weinig gebruikt aangezien hij na iedere actie weer herladen moet worden.

Ik zou 'product' tot value object gemaakt hebben, met een product DAO (getProductByName/Id, getProductsByCategory, etc.) en een product list class. Product gaat in iedergeval niet zelf zijn gegevens uit de database vissen, het is een product, geen database-io-class.

[twiekert]

PrisonerOfPain schreef op zondag 20 november 2005 @ 13:14:
[...]

Ik zou 'product' tot value object gemaakt hebben, met een product DAO (getProductByName/Id, getProductsByCategory, etc.) en een product list class. Product gaat in iedergeval niet zelf zijn gegevens uit de database vissen, het is een product, geen database-io-class.

inderdaad, je object heeft immers weinig van doen met je persistence mechanism. dat kan namelijk ook een xml file zijn of een compleet andere database. Dit betekent trouwens niet dat je object helemaal geen retrieve/update/delete operaties mag hebben, als deze maar door de DAO worden geimplementeerd.

Het ontwerpen van een goede OR-laag is een van de moeilijkste dingen die er zijn, zeker als er veel complexe relaties tussen objecten liggen, dat wordt je DAO laag al heel snel complex..

[BasieP]

Maurad3r schreef op zondag 20 november 2005 @ 12:58:
En ook een forum ala react (dit forum dus ) is zo opgebouwd? Tot op zo'n diep niveau als een bericht? Is het wel nuttig om tot zo'n diep niveau door te boren met klassen? Ik vind het ook altijd lastig om met server side talen (ook php in mijn geval) te bepalen welke entiteiten een klasse moeten zijn en welke niet.

idd, hoever zou je bijv een forum in classes kunnen doen?

aangezien je 1 pagina opbouwt, en je dan al je data weer kwijt bent.
hoe doet bijv. react dit? ik neem aan dat ze niet een object maken van elke post die bijv in dit topic gedaan word. aangezien ze deze net zo goed in een loopje direct uit de DB kunnen printen (evt. na een paar functies)
om dan eerst een object aan te maken van elke post, en deze daarna weer weg te gooien is vrij nutteloos lijkt mij zo.
Wat ook zou kunnen is om eerst ALLE posts in objecten te zetten, en dan op de container bijv een ubb parser oid er overheen te halen, en dan alle objecten te printen.
het nadeel daarvan lijkt me alleen dat de performance hard naar beneden gaat.

zodoende mijn vraag:
in hoeverre zou een forum als dit OO moeten?

[twiekert]

je kan ook objecten (tijdelijk) cachen in een session of in een globale memcache in het geheugen.

[maurad3r]

BasieP schreef op zondag 20 november 2005 @ 13:40:
[...]

idd, hoever zou je bijv een forum in classes kunnen doen?

aangezien je 1 pagina opbouwt, en je dan al je data weer kwijt bent.
hoe doet bijv. react dit? ik neem aan dat ze niet een object maken van elke post die bijv in dit topic gedaan word. aangezien ze deze net zo goed in een loopje direct uit de DB kunnen printen (evt. na een paar functies)
om dan eerst een object aan te maken van elke post, en deze daarna weer weg te gooien is vrij nutteloos lijkt mij zo.
Wat ook zou kunnen is om eerst ALLE posts in objecten te zetten, en dan op de container bijv een ubb parser oid er overheen te halen, en dan alle objecten te printen.
het nadeel daarvan lijkt me alleen dat de performance hard naar beneden gaat.

zodoende mijn vraag:
in hoeverre zou een forum als dit OO moeten?

Ja idd, daar zit ik dus ook mee!
Welke entiteiten zouden jullie als klassen pakken en hoe hebben die dan een relatie met elkaar?

twiekert schreef op zondag 20 november 2005 @ 13:33:
[...]


inderdaad, je object heeft immers weinig van doen met je persistence mechanism. dat kan namelijk ook een xml file zijn of een compleet andere database. Dit betekent trouwens niet dat je object helemaal geen retrieve/update/delete operaties mag hebben, als deze maar door de DAO worden geimplementeerd.

Het ontwerpen van een goede OR-laag is een van de moeilijkste dingen die er zijn, zeker als er veel complexe relaties tussen objecten liggen, dat wordt je DAO laag al heel snel complex..

Maar WAT moet ik dan vertellen tegen mijn DAO laag? Stel ik wil de prijs veranderen van een product? Dan roep ik dus de DAO aan, maar met wat voor argumenten dan? Of moet ik voor iedere update een aparte functie in mijn DAO schrijven? dus, update_product, delete_product, update_klant, delete_klant.. etc?

[maurad3r]

twiekert schreef op zondag 20 november 2005 @ 13:45:
je kan ook objecten (tijdelijk) cachen in een session of in een globale memcache in het geheugen.

Het zal best werken, maar mijn gevoel zegt dat het niet echt een oplossing is (niet dat mijn gevoel veel waard is ), ik geloof ook niet dat er veel projecten zullen zijn die deze methoden gebruiken

[misfire]

Een klasse is een eenheid van verantwoordelijkheid. Die eenheid bestaat uit een verzameling van gegevens en operaties. Je moet dus kijken naar je gegevens en operaties en hoe je dingen kunt groeperen in niet-overlappende verantwoordelijkheden. Dat betekent dat de indeling van je klassen voornamelijk afhangt van wat je aan het maken bent: er zijn geen algemene spelregels die altijd werken.

Een simpel voorbeeld: stel je modelleert een auto voor een garage applicatie. Van de auto wil je iets bijhouden over wielen. Misschien wil je van de auto alleen het aantal wielen weten, dan maak je een simpele numerieke variabele "aantalWielen". Misschien wil je per wiel het type wiel, de soort velg en het merk band bijhouden. Dan heb je een eenheid van gegevens die per wiel apart is, en dan maak je daar een aparte klasse voor.

De naamgeving van objecten is in de regel altijd enkelvoudig en is zo natuurlijk mogelijk: dwz zo min mogelijk afkortingen of technische verwijzingen (geen "PersMan" of "PM_001" klasses).

Ik ben het niet eens met de suggestie "altijd Engelse namen gebruiken". Of iets Persoon of Person genoemd is een klein verschil, maar als je met domeinen met veel jargon te maken hebt dan is het veel handiger om het jargon aan te houden, of dit nu Nederlands of Engels is. Stel je maakt een juridisch systeem met een NatuurlijkPersoon en een RechtsPersoon, hoe ga je dit in het Engels noemen? Veel jargon heeft niet eens een vergelijkbaar woord in een andere taal. Je vervreemd je ook van het taalgebruik van je klant/gebruiker, en daarmee krijg je meer afstand van het echte probleem.

[Verwijderd]

BasieP schreef op zondag 20 november 2005 @ 13:40:
idd, hoever zou je bijv een forum in classes kunnen doen?
[..]
om dan eerst een object aan te maken van elke post, en deze daarna weer weg te gooien is vrij nutteloos lijkt mij zo.
[..]
in hoeverre zou een forum als dit OO moeten?

Volledig OO! Performance domweg geen issue. Hardware is nou eenmaal spot goedkoop en software niet. Niet gebruik maken van objecten betekend in dit geval dat je "view" voor alles verantwoordelijk is wat in de regel domweg betekend dat je niet te onderhouden code hebt geschreven.

Je view zou domweg helemaal geen notie moeten hebben waar de objecten vandaan komen. Deze geeft ze enkel weer. Door alles netjes te scheiden van taak kun je heel makkelijk delen code vervangen als daar reden toe is (bugs, veranderen van wensen). Je code wordt door goed gebruik van OO dus onderhoudbaar.

misfire schreef op zondag 20 november 2005 @ 14:23:Ik ben het niet eens met de suggestie "altijd Engelse namen gebruiken". Of iets Persoon of Person genoemd is een klein verschil, maar als je met domeinen met veel jargon te maken hebt dan is het veel handiger om het jargon aan te houden, of dit nu Nederlands of Engels is. Stel je maakt een juridisch systeem met een NatuurlijkPersoon en een RechtsPersoon, hoe ga je dit in het Engels noemen? Veel jargon heeft niet eens een vergelijkbaar woord in een andere taal. Je vervreemd je ook van het taalgebruik van je klant/gebruiker, en daarmee krijg je meer afstand van het echte probleem.

Ik ben het met je eens als we het over Excell functies hebben, die kunnen namelijk ook in het nederlands. Voor de rest compleet oneens. Immers een programmeer taal is doorgaans engels (for while etc) en daarom ben ik voorstander om het leesbaar te houden in 1 taal. Code moet immers leesbaar zijn voor je collega's, niet voor je klanten.

[ Voor 37% gewijzigd door Verwijderd op 20-11-2005 14:35 ]

[NMe]

BasieP schreef op zondag 20 november 2005 @ 13:40:
zodoende mijn vraag:
in hoeverre zou een forum als dit OO moeten?

OO zoog in PHP tot en met versie 4. In versie 5 begint het er al meer op te lijken, maar is het nog steeds rampzalig. React is AFAIK nog voor PHP4 gemaakt, dus het zou me niets verbazen als Parse weinig tot geen OO gebruikt, maar dat kan ik niet met zekerheid zeggen, aangezien ik hun code niet ken.

In PHP5 heeft het opdelen van een forum tot op een laag niveau zoals "messages" nog wel nut, maar in PHP4 waag ik dat enigszins te betwijfelen omdat OO daar niet veel meer betekent dan "structures, maar dan met methods erbij".

Als je een forum als dit netjes in OO wil implementeren, waarbij je even de taal waarin je dat doet buiten beschouwing laat, dan zul je toch moeten denken aan wat JHS hierboven al noemt, hoewel het dus afhankelijk van de taal in meer of mindere mate zinnig kan zijn om het anders aan te pakken.

Verwijderd schreef op zondag 20 november 2005 @ 14:30:
Volledig OO! Performance domweg geen issue. Hardware is nou eenmaal spot goedkoop en software niet.

Ah, ok. Performance is geen issue? Zullen we de mensen van Parse maar zeggen dat ze kunnen ophouden met optimalisatie dan? Bij een forum, en zeker bij een drukbezocht forum als dit (waar we het dus ook over hadden) is performance wèl een issue, aangezien ik me niet kan voorstellen dat iemand het leuk vindt om met zijn breedbandverbinding 20 seconden op elke pagina te moeten wachten.

Niet gebruik maken van objecten betekend in dit geval dat je "view" voor alles verantwoordelijk is wat in de regel domweg betekend dat je niet te onderhouden code hebt geschreven.

Wacht even hoor. Zeg je nu dat alles wat niet OO geprogrammeerd is, niet te onderhouden is? Dat lukt me anders prima in procedurele talen als Pascal en C, dus ik vraag me af waar je dat gekke idee vandaan haalt. De programmeur maakt nette, onderhoudbare code, niet de denkwijze -hoewel een denkwijze natuurlijk wel aardig wat werk uit handen kan nemen.

[ Voor 37% gewijzigd door NMe op 20-11-2005 14:39 ]

[twiekert]

Maurad3r schreef op zondag 20 november 2005 @ 13:49:
[...]

Ja idd, daar zit ik dus ook mee!
Welke entiteiten zouden jullie als klassen pakken en hoe hebben die dan een relatie met elkaar?


[...]

Maar WAT moet ik dan vertellen tegen mijn DAO laag? Stel ik wil de prijs veranderen van een product? Dan roep ik dus de DAO aan, maar met wat voor argumenten dan? Of moet ik voor iedere update een aparte functie in mijn DAO schrijven? dus, update_product, delete_product, update_klant, delete_klant.. etc?

In principe zou elke class een eigen DAO moeten hebben.

voorbeeldje:

PHP:

<?

class Product {
    
    private $iProductID = null;
    private $sProductDescription = null;
    
    
    public function __construct() {
        
    }
    
    
    /* SET FUNCTIONS */
    public function setProductID($p_iProductID) {
        
        if (is_int($p_iProductID)) {
            $this->iProductID = $p_iProductID;
        } else {
            throw new Exception('blaat productID geen int!');
        }
    }
    
    public function setProductDescription($p_sProductDescription) {
        $this->sProductDescription = $p_sProductDescription;
    }
    
    /* GET FUNCTIOS */
    public function getProductID() {
        return $this->iProductID;
    }
    
    public function getProductDescription() {
        return $this->sProductDescription;
    }
    
    

    public function retrieve($p_iProductID) {
        ProductDAO::retrieveByPK($this, $p_iProductID);
    }
    
    
    public function hasValidState() {
        //check hier of het object een valid state heeft
        // zijn alle benodigde gegevens er wel om je database bij te werken?
        // dit zijn dus de businessrules
        
        return true;
    }
}


class ProductDAO {
    
    static public function retrieveByPK(Product $p_oProduct, $p_iProductID) {
        
        // do DB stuff en haal product op uit database met behulp van de PK
        // dit ff als test:
        $dbrow['ProductID'] = 10;
        $dbrow['ProductDescription'] = 'Ik ben een product';
        
        $p_oProduct->setProductID($dbrow['ProductID']);
        $p_oProduct->setProductDescription($dbrow['ProductDescription']);
    }
    
    static public function updateProduct(Product $p_oProduct) {
        
        //check of Product in een valid state is
        if ($p_oProduct->hasValidState()) {
            
            //query hier je database met een update met de getXXX functies van Product.
            
            
        } else {
            throw new Exception('Er is iets mis...');
        }
    }
}


$oProduct = new Product();
$oProduct->retrieve(10);

echo $oProduct->getProductID();
echo $oProduct->getProductDescription();

$oProduct->setProductDescription('Ik heet nu anders');
ProductDAO::updateProduct($oProduct);

echo $oProduct->getProductDescription();
?>

Er schort nog vanalles aan deze code maar het is meer een idee zoals ik het aanpak. update/delete/insert functies horen eigenlijk niet van buiten de class bereikbaar te zijn. Een algemene save() functie moet aan de hand van de object state bepalen of een bestaand product geupdate moet worden of een nieuwe geinsert of verwijderd.

Maurad3r schreef op zondag 20 november 2005 @ 13:51:
[...]

Het zal best werken, maar mijn gevoel zegt dat het niet echt een oplossing is (niet dat mijn gevoel veel waard is ), ik geloof ook niet dat er veel projecten zullen zijn die deze methoden gebruiken

Objecten tijdelijk ergens in het geheugen opslaan is hartstikke handig voor het aanmaken of bewerken van een object.

Stel je voor dat iemand een webapp heeft waarin orders aangemaakt kunnen worden. Een order heeft als attributen een klantobject, orderregel objecten en de ordergegevens zelf (levertijd, datum etc).

Zou je dit niet tussentijds opslaan in het object (in een session) dat moet je of:

- al deze gegevens in een FORM bewaren om ze later in één keer te submitten en op te laten slaan.

- deze gegevens één voor één in de database submitten; waardoor je met een halve order kan blijven zitten, bijvoorbeeld een order met een gekoppelde klant met ordergegevens maar geen orderregels

Door zo'n object in een sessions/memcache/file of welk cache systeem dan ook op te slaan kan je rustig het object opbouwen totdat het compleet is en het dan in één keer persisten naar de database als alle gegevens voor die order compleet zijn

Dezelfde code kan je dan dus ook gebruiken op een webshop als mandje. De klant kan dan rustig z'n producten bij elkaar zoeken en pas als tie tevreden is de order invoeren in de database.
Zou je dit niet doen dan moet je weer een of ander custom winkelmand ding gaan programmeren die de spullen in een session gooit en pas als de klant wil bestellen deze session gegevens gebruiken om een Order object aan te maken en die weer te saven, beetje omslachtig

[misfire]

Ik ben het eens met mark platvoet over het feit dat je performance en oo-design zo veel mogelijk moet scheiden, maar niet omdat hardware goedkoop is en software niet. Een goed oo-design zou juist moeten zorgen voor een goede performance, omdat je een duidelijke focus hebt en weinig tot geen overlap. Slechte oo-designs met veel onnodige constructies en indirecties maken de zaak traag, of slechte technologische keuzes (te veel remoting, verkeerde frameworks, enz).

Verwijderd schreef op zondag 20 november 2005 @ 14:30:
["Niet alle code in het Engels"]
Ik ben het met je eens als we het over Excell functies hebben, die kunnen namelijk ook in het nederlands. Voor de rest compleet oneens. Immers een programmeer taal is doorgaans engels (for while etc) en daarom ben ik voorstander om het leesbaar te houden in 1 taal. Code moet immers leesbaar zijn voor je collega's, niet voor je klanten.

Ik ben nog steeds benieuwd naar de vertaling van mark platvoet voor een NatuurlijkPersoon en een RechtsPersoon. Ik zie niet in hoe code leesbaarder wordt door af te wijken van het jargon van de klant. Als het goed is snappen mijn collega's en ik het jargon van de klant, anders zouden we het probleem van de klant ook niet begrijpen.

Begrijp me niet verkeerd: ik ben niet tegen Engels in code, ik ben alleen tegen Engels-omdat-de-rest-ook-Engels-is, of omdat het wel eens ooit in India onderhouden zou moet worden oid. Als dat soort problemen niet actueel zijn waarom er dan moeite voor doen? Misschien is het over 2 jaar wel heel goedkoop om IT te outsourcen naar Suriname, en daar spreekt men beter Nederlands dan Engels.

[Verwijderd]

UML, anyone? Lijkt me toch dat de persoon hier een probleem heeft met het modelleren en niet met OO. Nu is UML natuurlijk nog altijd best practise, maar ik denk dat het je toch wel een beter beeld geeft van een systeem.

[twiekert]

en voor de volledigheid: http://en.wikipedia.org/wiki/Unified_Modeling_Language

Maar als de topicstarter moeite heeft om te zien waarvan nu classes gemaakt moeten worden dan heeft UML ook niet zoveel zin.

[NMe]

Verwijderd schreef op zondag 20 november 2005 @ 14:58:
UML, anyone? Lijkt me toch dat de persoon hier een probleem heeft met het modelleren en niet met OO. Nu is UML natuurlijk nog altijd best practise, maar ik denk dat het je toch wel een beter beeld geeft van een systeem.

UML is een manier om je ontwerp weer te geven, geen denkwijze. De OO-denkwijze kun je prima uitdrukken zonder ook maar één stukje UML te gebruiken.

[Remus]

Ik denk dat de TS het boek 'Applying UML and patterns ' - 'An introduction to Object-Oriented Analysis and Design and the Unified Process' van Craig Larman moet lezen. Goede introductie over hoe je OO modeleert en met welke patterns je je keuzes kunt onderbouwen.

[BasieP]

twiekert schreef op zondag 20 november 2005 @ 14:35:
Objecten tijdelijk ergens in het geheugen opslaan is hartstikke handig voor het aanmaken of bewerken van een object.

Stel je voor dat iemand een webapp heeft waarin orders aangemaakt kunnen worden. Een order heeft als attributen een klantobject, orderregel objecten en de ordergegevens zelf (levertijd, datum etc).

Zou je dit niet tussentijds opslaan in het object (in een session) dat moet je of:

- al deze gegevens in een FORM bewaren om ze later in één keer te submitten en op te laten slaan.

- deze gegevens één voor één in de database submitten; waardoor je met een halve order kan blijven zitten, bijvoorbeeld een order met een gekoppelde klant met ordergegevens maar geen orderregels

Door zo'n object in een sessions/memcache/file of welk cache systeem dan ook op te slaan kan je rustig het object opbouwen totdat het compleet is en het dan in één keer persisten naar de database als alle gegevens voor die order compleet zijn

dat klinkt idd interessant.
Nu blijft het zo dat wanneer een willekeurige gebruiker op een willekeurig topic van een forum klikt je niks kan 'opslaan' dat nodig zou zijn voor een eventuele nieuwe pagina.
bij een webshop heb je idd dat er gegevens bewaard moeten worden door een aantal pagina's heen, maar op een forum ben je de meerwaarde al gauw kwijt, aangezien 90% lezen is, en je de informatie zodoende maar 1x nodig hebt.
voor het posten van informatie in een topic heb je voor het 'reply' scherm slechts 1 waarde nodig, namelijk de 'id' van het topic. Dit kan je heel makkelijk met get vars doen, en hier heb je geen objecten voor nodig.
enige waar ik aan kan denken bij een forum dat OO zou kunnen, is de login procedure. Deze kan idd met een sessie worden opgeslagen, en hier zou je dingen als rechten in kunnen zetten.
Wanneer je deze met elke pagina meegeeft hoef je niet telkens in de DB te graven naar dingen als username, userid, en rechten.

[NMe]

Modbreak:

Berichten met betrekking tot welke taal je moet gebruiken voor variabelenamen, types, enzovoorts afgesplitst naar Welke taal moet je gebruiken voor naamgeving in je code?.

[Genoil]

Tombo_inc schreef op zaterdag 19 november 2005 @ 22:07:
ik moet eerlijk zeggen dat ik hier soms ook moeite mee heb. maar je moet eigenlijk gewoon heel simpel nadenken over wat voor object de klasse voorsteld. om maar een dwarsstraat te noemen:
als je een database abstractie laag gaat maken, dan noem je je baseclass bijvoorbeeld "DAL", en afgeleiden daarvan bijvoorbeeld "mysqlDAL".

Ja sorry dat ik het moet beamen maar je hebt er idd wat moeite mee . "DAL" is imo een slechte naam (een van) de baseclass(es) van een DAL. De afgeleide "mysqlDAL" is dan nl. een contradictio in terminis: is het nou mysql of een abstractielaag? Dan kun je beter "Connection" en "MysqlConnection" gebruiken.

[PrisonerOfPain]

Genoil schreef op maandag 21 november 2005 @ 09:22:
Dan kun je beter "Connection" en "MysqlConnection" gebruiken.

Ik vind op mijn beurt de term Connection weer te breed, tenzij je de class zo ontwerpt dat er ook bijvoorbeeld socket verbinden van afgeleid kunnen worden ("SocketConnection"), anders zou ik gaan voor een abstracte "SqlConnection" class.

[.oisyn]

Waarom SQL, dat heeft er toch niets mee te maken? Je hebt een verbinding met een relationele database, dus ik zou 'm dan (R)DBConnection noemen. SQL is slechts een taal die de database begrijpt om gegevens voor jou op te halen.

[PrisonerOfPain]

.oisyn schreef op maandag 21 november 2005 @ 15:11:
Waarom SQL, dat heeft er toch niets mee te maken?

Waarschijnlijk vanwegen de .Net SqlConnection alleen zal die zijn naamgeving te danken hebben aan de naam van de database server. DBConnection of DatabaseConnection zou inderdaad beter zijn.

[Hydra]

BasieP schreef op zondag 20 november 2005 @ 13:40:
idd, hoever zou je bijv een forum in classes kunnen doen?

Ik weet niet hoe het in dit forum gedaan wordt (bovendien IMHO niet erg interessant), maar in grote (web)applicaties worden over het algemeen meerlaagste structuren gebruikt. Alles wat uit een DB komt, wordt door een laag gemapped naar objecten, dus inclusief alle data. Persoonsdata naar een persoon object, vacatures naar een vacature object, opleidingen binnen een persoon naar opleidingsobjecten e.d. Deze business objecten worden dan naar de applicatielaag doorgestuurd, welke deze bijvoorbeeld weergeeft of aanpast. Een aangepast object kan dan door de DB laag naar de DB teruggeschreven worden.

Het grote voordeel hiervan is, dat het veel makkelijker te onderhouden is dan een systeem waarbij rechtstreeks in de GUI laag met DB spul gewerkt wordt. In een goed systeem kun je erg makkelijk zien of er in de GUI laag iets misgaat, gewoon een breakpoint op de juiste plek en kijken hoe dat persoonsobject previes gemodificeerd wordt.

Dus het gaat ongeveer zo:
RDBMS <> DB Laag <> Business Objects <> Applicatie Laag <> User
Lagen zijn strikt van mekaar gescheiden, dit om rotzooi/chaos te voorkomen.

-NMe- schreef op zondag 20 november 2005 @ 14:35:
Ah, ok. Performance is geen issue? Zullen we de mensen van Parse maar zeggen dat ze kunnen ophouden met optimalisatie dan? Bij een forum, en zeker bij een drukbezocht forum als dit (waar we het dus ook over hadden) is performance wèl een issue, aangezien ik me niet kan voorstellen dat iemand het leuk vindt om met zijn breedbandverbinding 20 seconden op elke pagina te moeten wachten.

"Premature optimization is the root of all evil"

Vanwege optimization OO het raam uit gooien is geen goed idee. Een OO aanpak zal misschien niet de snelste zijn, maar we coden fora ook niet in assembly ofwel? Grote systemen halen hun performance sowieso niet uit het al dan niet OO zijn, over het algemeen is toch de backend de bottleneck. Een extra webserver plaatsen is over het algemeen een minder groot probleem dan een bijvoorbeeld backend die simpelweg de load niet aankan. Een extra DB server brengt een hoop extra problemen met zich mee.

[ Voor 31% gewijzigd door Hydra op 21-11-2005 16:08 ]