Een vraagje... ik heb een class waarin ik data kan opslaan en deze class kan ik locken zodat er geen data meer aan kan worden toegevoegd.
Nu had ik dus in die class een is_locked() method gemaakt, zodat ik kan zien of een object gelockt is.
Echter, nu zit ik daar nog even over na te denken en nu vraag ik me af of die is_locked() method wel nodig is? Want, zo besef ik me ineens, het zou raar zijn om eerst te kijken of het object gelockt is, en zo nee om dan pas gegevens toe te voegen. Blijkbaar wil je gegevens toevoegen en mag het object op dat moment simpelweg niet op slot zitten. Dus hoef je dit ook niet te testen!
Zijn jullie het eens met mijn gedachte dat het dus onzin is om een is_locked() method te hebben?
Ik wil een object kunnen locken zodat de data niet gewijzigd kan worden. Stel ik krijg data van buitenaf, dan wil ik die kunnen setten. Misschien wil ik er nog iets aan toevoegen, maar daarna moet het object op slot, zodat het niet meer gemanipuleerd kan worden. That's all :)
Het is niet iets heel spannends hoor. Ik geef bij de getter trouwens een exception als de key niet bestaat.
Dan zou een exception in de setter inderdaad al afdoende zijn: "Let op, deze waarde ligt al vast."
Bij data van buitenaf zou ik er wel voorzichtig mee omgaan. Als object X iets vastlegt, dan kán object Y dat mogelijk niet meer veranderen wanneer dat wel dringend gewenst is. Dan heb je via de achterdeur te veel afhankelijkheden ingebouwd.
>> Dan had je dus het object niet moeten locken en zit er dus een fout in je logica :)
Maar daarvoor hoef je het object niet te locken. Je kunt ook een QA-regel vastleggen die code met logic exceptions in de productieomgeving verbiedt.
Je krijgt een log en loom raketbesturingssysteem als je alle check & balances inbouwt. PHP-applicaties zijn geen tropisch eiland die geheel zelfvoorzienend moeten zijn.
Oh, dat zeg ik ook niet, maar dat is een persoonlijke keuze/afweging natuurlijk.
Je kunt niet alles afvangen, maar dit soort zaken kun je prima afvangen. En ik ga niet daarvoor een "productie" en "test" versie maken. Dat kleine beetje performance weegt niet op tegen de fouten die er uit voort kunnen komen.
>> En ik ga niet daarvoor een "productie" en "test" versie maken.
Dat hoeft ook niet. Een unittest schrijven is niet veel meer werk dan een constrolestructuur toevoegen. Code die een unittest doorstaat, blijft daarmee vrij van een controlestructuur die 99,999% van de tijd overbodig is.
Je neigt nu naar een aparte lockable ParameterBag-klasse om logische fouten van developers voor te zijn. Zou je dan niet liever wat aan unittesting gaan doen?
Daar heb ik me eerlijk gezegd nooit verdiept. Misschien ga ik dat ooit wel doen, maar voorlopig hou ik het maar bij deze manier. Maar ik snap wel wat je bedoelt te zeggen.
Ward, bij een Unit Test is de kans nog steeds vrij groot dat je dingen gaat testen/implementeren die compleet overbodig zijn. BDD is dan veel beter, zoals PHPspec en Behat. (waarbij PHPspec zeg maar BDD op Unit Testing niveau is)
