Hoezo
moet je voordat je de methode begint de pre-condities checken? Pre lijkt me nou niet zozeer Pre in de zin dat het vooraan je method moet staan. Het gaat erom dat er aan een aantal voorwaarden voordaan moet worden worden, zo niet dan krijg je een Exception.
Daarnaast kan je ook heel duidelijk de
voorwaarden bij mijn aanpak zien, omdat ze expliciet vermeld staan ipv
impliciet. Verder kan het bij jouw aanpak zelfs gebeuren dat er
geen foutmelding wordt opgeworpen omdat een stuk code niet werd
uitgevoerd (tenslotte is de voorwaarde impliciet vermeld, dus
misschien zie je hem bij een refactor-beurt wel over het hoofd).
Tja, ik neem aan dat je documentatie en source naast elkaar houd als je met je programma aan de slag gaat, dus ook bij een refactor. Expliciter dan "als de waarde null is krijg je een NullPointerException" kun je het niet krijgen lijkt mij. Test jij alle post-condities op het einde van je source ook nog eens expliciet?
Dat had inderdaad een IllegalArgumentException of iets in die geest
moeten zijn. Het was die avond al vrij laat
Het ging me ook niet zozeer om de kleine dingen.. het was maar voor een postje op GoT, niet een hartslagmeter
Ik hou ook niet van vriendelijke functies, maar helaas zijn de methodes bij String ook op deze manier gemaakt, dus vandaar deze vriendelijkheid. In mijn eigen objecten doe ik het ook niet.
Hm, ja dat klopt wel inderdaad.
Je krijgt inderdaad meteen te zien waar het is fout gegaan. En verder
heb je geen debugger nodig hoor, je kan het ook netjes uit de
stacktrace halen
Ik moet zeggen dat ik dat wel een heel zwak argument vind
Je kan het uit de stacktrace halen, maar "netjes" wil ik dat al niet noemen. Als je met het door jou genoemde refactoring dmv van automatische refactoring namen van variablelen gaat wijzigen gaat het al mis.
En aangezien dat het enige echte voordeel wat ik er in kan zien ben ik niet bepaald overtuigt. Hoe ik het zie is dat jij en ik allebei op basis van de dezelfde gegevens, dezelfde code met dezelfde functionaliteit en maintainability (mist je het op de correcte manier doet natuurlijk) als resultaat. Het verschil is alleen dat mijn code sneller en compacter is, en het me minder tijd kost, en dat jij na 5 jaar de WAO in moet omdat je gek wordt van al die null-checks schrijven
Maar ieder z'n ding, zolang ik je niet hoef te betalen mag je doen wat je wilt van mij
Het Collection framework is bedoelt als een heel generiek framework,
maar bij specifieke classes ben ik zelf zo streng mogelijk en Null
objecten zijn vaak ongewenst (dus die verbied ik ook).
Zoals ik al zei, op een plek waar je geen null wilt, en het maken van code die op null checkt een ander effect heeft (meer dan alleen de stacktrace), heb ik daar niks op tegen. Sterker dan dan doe ik het zelf ook natuurlijk
Je code wordt inderdaad trager en groter, maar ik kan wel garanderen
dat mijn code niet bij incorrecte invoer verder gaat en dat vind
ik dus erg belangrijk.
Tja, als ik al die onnodige checks van jou weggooi heb ik een functie die in iedere usecase precies hetzelfde doet, behalve dat de Exception.toString() er anders uitziet. Het verschil zit em erin dat mijn code sneller is bij uitvoer met een correcte parameter, en jou code (soms, zeker niet altijd) sneller is bij een incorrecte parameter.
En wat bedoel je dat de designer dit met
assertions had kunnen oplossen?
Niet zozeer "dit", ik wou er alleen maar mee aangeven dat het detecteren van een ongewenste "null" gewenster is door het controleren van post-conditions, als door het verderop detecteren bij het aanspreken van een functie met een not-null pre-conditie.
Oftwel, eigenlijk hoor je bij
goed testen meer dingen te vinden als:
Hey, op regel 666 krijg ik "null" terug van functie
code:
1
| Invoer mijninvoer = krijgInvoerVanRaarDevice(); |
terwijl in de post-conditions staat dat dit niet mag, als:
Hey, op regel 1313 voer ik
code:
1
| Invoer bewerkteinvoer = bewerkInvoer(mijninvoer); |
en ik krijg een NullPointerException("null") (of in jou geval NullPointerException("invoer mag geen null zijn)) terug.
Dit alles doet niks af aan het belang van pre-conditions, maar zoals ik al zei bij mijn manier van werken zijn die ook gegarandeerd.
Zoals ik boven al heb gezegd, je hebt nu een voorwaarde impliciet in
je code staan en dat vind ik persoonlijk een vrij slechte manier van
werken.
En zoals ik al zei, je post conditions staan er net zo impliciet in. Je hebt toch documentatie, waarin je posts en pre staan. Na het maken van je functie test je toch of ie voldoet aan die voorwaarden? Na veranderingen in de code toch ook?
Het kan zelfs gebeuren dat met jouw manier van aanpak objecten
in een inconsistente toestand achterblijven en dat zal bij mij minder
snel gebeuren.
Zoals ik al zei, vanuit het oogpunt van optimalisatie zou je bovenaan sommige functies een null-check kunnen zetten. Het kan namelijk voorkomen dat je in mijn variant eerst wat objecten aanmaakt voor de nullpointer gesignaleerd wordt. Dit gaat natuurlijk alleen op als je verwacht dat je in je productie systeem er vanuit gaat dat nullpointers normaal zijn. (Wat voor het merendeel van de functies niet het geval is mag ik hopen).
Mocht je objecten aanmaken die "binnen de scope van je functie voor een inconsitente toestand zorgen" (hm je weet wel wat ik bedoel hoop ik, sockets etc.) dan mag ik aannemen dat je die met finally opruimt! (Zo niet, shame on you Alarmnummer!
)
Gebeurt dat buiten de "scope" van je functie en heb je het zo gemaakt dat de NullPointerException pas daarna valt zet ik er natuurlijk ook een null-check voor (of desnoods net als jou bovenaan).
Het blinde eind van een varken kan zien dat als in dit voorbeeld "source" null is je een nullpointer exception krijgt, ook als er niet if (source == null) etc. voostaat. Aangezien de gemiddelde ITer nog
net iets slimmer is
Een complexere functie hoort gewoon goed getest te worden, ook op nulls, of je die null-checks van jou nou bovenaan hebt staan of niet (die kun je nl. ook vergeten).
Ik ben het op verschillende plaatsen tegengekomen, maar wat de meeste
indruk heeft gemaakt is de behandeling hiervan bij DBC. Ik heb het dus
niet zelf bedacht. En kijk verder de java classes maar eens door, je
zult zien dat ze hun invoer ook checken.
Ik nam al niet aan dat je het zelf bedacht. Ik zie niet in waarom je in Design By Contract deze functie op deze manier zou moeten schrijven. Test dan op z'n minst ook de post-conditions.
[edit]
onder linux zijn alleen maar ruckeditors uit.. grr.. wat een pokke dingen!
Gaat het over Java hier? Eclipse Eclipse Eclipse (of doet je geliefde jIDEA het ook onder linux eigenlijk?)
Als het over console gaat, probeer Joe eens
:strip_icc():strip_exif()/u/5288/jester.jpg?f=community)
:strip_exif()/u/9959/glimi.gif?f=community)
:strip_exif()/u/31626/eend.gif?f=community)
:strip_exif()/u/11775/SoulTaker.gif?f=community)
:P]
Dat mogen ze wel overnemen naar Java. -- Waarom ga je dan geen Nice gebruiken? Dat is (nog) niet realistisch. Misschien voor mijn projectjes thuis, maar hier op het werk kan dat IMO gewoon niet, omdat we hier met Java tools werken. Ik krijg niet de indruk dat ik de Nice compiler zomaar overal bij kan betrekken. 
/u/13469/ada.png?f=community)
De laatste keer dat ik dat prog aanraakte snapte de syntax highlighting het niet als ik escaping gebruikte in een shellscript geloof ik.