[OOP] Welke programmeer standaarden

[Verwijderd]

Bestaat er misschien een soort van standaard van programmeerstandaarden voor object georienteerd programmeren? En dat een beetje globaal te gebruiken is voor allerlei talen die OO ondersteunen? Ik was zelf bezig met het standaardiseren van m'n code, zoals naamgevingen en de manier waarop bepaalde functies werken en alles, maar toen bedacht ik me dat er misschien al een goed doordachte standaard bestaat.

Mijn vraag is eigenlijk welke standaarden hier gebruikt worden?

[Alarmnummer]

Per taal en platform is dat anders. Java heeft bv geen prefixen voor interface, .NET heeft de I als prefix en bij Delphi zet je er een T voor. Hoofdletters dito. Dat is dus per taal anders. En verder heb je per taal ook weer aparte dingen. Java heeft bv geen properties, dus loop je te werken met getters/setters. c# en delphi ondersteunen wel properties, dus getters/setters is daar overbodig.

[ Voor 36% gewijzigd door Alarmnummer op 06-11-2005 12:04 ]

[whoami]

Een standaard bestaat er niet.
De meeste bedrijven hebben wel elk zo hun eigen guidelines die je moet volgen (als je daar werkt).

Voor Java bestaat er weer een andere guideline dan voor .NET voor wat naamgeving betreft (Bij java beginnen de method namen bv met een kleine letter (camelcase), in .NET beginnen ze met een hoofdletter (pascal-case)).

Wat bedoel je met de 'manier waarop functies werken' ? Bedoel je hiermee hoe je ze documenteert ?

[Cloud]

Vaak verschillen dit soort dingen nog wel tussen verschillende programmeertalen, maar je kunt eens googlen op Design Patterns. Dit zijn patronen waarmee je kunt werken, die voor bepaalde doeleinden zeer geschikt zijn
Andere dingen zoals naamgeving enzo, dat is meer persoonlijk en ik geloof niet dat daar echte standaarden voor bedacht zijn. Vaak doen talen dat zelf al gedeeltelijk, door bijvoorbeeld te eisen dat iets wel of niet met een hoofdletter begint. De werking van functies is helemaal iets waarvan ik denk dat het buiten Design Patterns niet beschreven staat in standaarden. Zelfs Design Patterns hebben nog veel ruimte voor vrijheid binnen de functies en de omschrijvingen ervan

edit:
Eigenlijk moet je met OOP gewoon zorgen dat je ook echt de kracht van OOP gebruikt. Dus klassen, erving, etc. Op die manier werk je vaak netjes en correct. Maar zoals hierboven ook al vermeldt, is er niet éen standaard, maar gewoon veel verschillende

[ Voor 17% gewijzigd door Cloud op 06-11-2005 12:07 ]

[Verwijderd]

Maar regels zoals een functie die false terug moet geven als hij mislukt, die gelden toch voor elke OO taal? Wat ik me af vraag is of er een systeem van standaarden bestaat voor dat soort "regels".

[whoami]

Verwijderd schreef op zondag 06 november 2005 @ 12:09:
Maar regels zoals een functie die false terug moet geven als hij mislukt, die gelden toch voor elke OO taal? Wat ik me af vraag is of er een systeem van standaarden bestaat voor dat soort "regels".

Moeten ?
Veel hangt gewoon af van wat jij wil, en wat er volgens jou het beste is.
Wat is mislukken in jouw voorbeeld ? Als bv een 'Save' operatie naar een database mislukt, omdat er geen connectie is met een DB, dan kan er bv evengoed een exceptie gegooid worden.

[Alarmnummer]

whoami schreef op zondag 06 november 2005 @ 12:11:
[...]


Moeten ?
Veel hangt gewoon af van wat jij wil, en wat er volgens jou het beste is.
Wat is mislukken in jouw voorbeeld ? Als bv een 'Save' operatie naar een database mislukt, omdat er geen connectie is met een DB, dan kan er bv evengoed een exceptie gegooid worden.

In dit geval zou een exception beter zijn omdat het een uitzonderlijke situatie is die aandacht vereist. Op het moment dat je een false terug stuurt kan je het sneller negeren. Verder kan je in een exception veel meer informatie zetten (bv een cause exception) en met het returntype van een functie kan je dit toch een stuk minder snel.

[whoami]

Alarmnummer schreef op zondag 06 november 2005 @ 12:12:
[...]


In dit geval zou een exception beter zijn omdat het een uitzonderlijke situatie is die aandacht vereist.

Dat bedoelde ik ook.

Op het moment dat je een false terug stuurt kan je het sneller negeren. Verder kan je in een exception veel meer informatie zetten (bv een cause exception) en met het returntype van een functie kan je dit toch een stuk minder snel.

Idd, tenzij je natuurlijk begint zoals in C, en waar je bv aan iedere return-value een 'beschrijving' hangt. (0 is success, -1 is fout omwille van reden A, -2 fout omwille van reden B, etc...).
Maar of je dat wilt....

[frickY]

Je zou bijv naar richtlijnen kunnen kijken welke zijn opgesteld voor Open Source-projecten. Daarbij worden altijd bepaalde eisen gesteld aan je code. Waar de comments staan, hoe je vars naar een functie gooit, etc

Voor PEAR modules voor PHP vind je deze bijvoorbeeld hier; http://pear.php.net/manual/en/standards.php

[Verwijderd]

Maar als een functie een exception geeft, kun je 'm toch ook nog false terug laten geven om zodat de code die hierna wellicht nog wordt uitgevoerd hier rekening mee kan houden?

[Alarmnummer]

Verwijderd schreef op zondag 06 november 2005 @ 12:58:
Maar als een functie een exception geeft, kun je 'm toch ook nog false terug laten geven om zodat de code die hierna wellicht nog wordt uitgevoerd hier rekening mee kan houden?

1) de code die de exception voor de kiezen krijgt houd er automatisch rekening mee omdat je door de exception uit je normale flow knalt (je springt naar de exception handler)
2) dat zou dan alleen op gaan bij boolean functies. Op het moment dat je een functie hebt die iets anders terug stuurt (bv een string) dan heb je een probleem.

[ Voor 4% gewijzigd door Alarmnummer op 06-11-2005 13:01 ]

[Verwijderd]

Als de functie iets anders teruggeeft kan hij toch nog steeds false terug geven bij een error?

Maar ik was even in de war met die exceptions, bij php laat ik een functie namelijk bij een fout, trigger_error aanroepen en false terug geven zodat de code erboven weet dat het is misgegaan... Maar dit geldt natuurlijk voor andere talen niet.

[Nick_S]

Als jij een functie hebt, die bijvoorbeeld een String als return value heeft, ga je niet bij een error de String "false" teruggeven. (Je kan al helemaal niet de boolean value False terug geven, aangezien je een String terug moet geven)

Je kan dan drie dingen terug geven:

een lege String
een null value
een exceptie

Je zal alleen heel goed in je documentatie aan moeten geven welke van de drie je bij een bepaalde situatie terug geeft.

ps. Ik maak gebruik van het String voorbeeld, maar hier kun je natuurlijk elke klasse invoegen.

[Verwijderd]

Volgens mij kan dit bij php wel gewoon.

[Verwijderd]

Maar goed, naast deze detaildiscussie lijkt me het antwoord op de hoofdvraag (bestaan er standaarden voor OO) gewoon "nee". Design patterns zijn al genoemd. Dat vind ik persoonlijk het dichtst in de buurt komen van een standaard, maar dat is het stiekem toch niet. Het zijn 'proven solutions to common problems'. Overigens behoorlijk interessant. Ik moet er zelf nog een hoop van leren. Ik denk dat je het meeste hebt aan de opmerking van Wolkje: zolang je de features van OO slim gebruikt ben je in de meeste gevallen ok bezig.

[NMe]

Verwijderd schreef op zondag 06 november 2005 @ 13:37:
Volgens mij kan dit bij php wel gewoon.

PHP is dan ook niet strong-typed, en is bovendien om allerlei redenen een slecht voorbeeld van een OO-taal.

[Verwijderd]

Dan is het me duidelijk. Ik zal de designpatters nog eens bekijken, vroeger begreep ik niet echt het nut van de meeste maar misschien nu wel. iig iedereen bedankt voor de inbreng!