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 vond de eerdere uitleg van Wouter over verantwoordelijkheden op vier niveaus eigenlijk wel aardig. Die is_locked() hoort er namelijk hooguit in als je de verantwoordelijkheid bij de klasse zelf legt.
Ik snap niet helemaal wat je bedoelt. Of ik begrijp jou niet, of jij mij niet.
De vraag is, is die is_locked() method überhaupt nodig. In 1e instantie dacht ik van wel. In 2e instantie van niet, want waar heb ik die eigenlijk voor nodig?
Stel ik wil iets toevoegen aan een class, dan is het raar om eerst te checken of ik wel iets kan toevoegen. Blijkbaar wil ik iets toevoegen, en als op dat moment heb object op slot zit, dan zit er blijkbaar iets fout in m'n logica. Of zie jij dat anders?
Soms is het nuttig, meestal niet. Je kunt bijvoorbeeld een class hebben die tijdelijk read-only moet zijn.
Vervolgens is de vraag of je dat dan wel moet afhandelen met een is_locked(). Dat zou je kunnen doen als je het op het niveau van de klasse zelf wilt oplossen, maar je kunt het ook oplossen op de drie andere niveaus die Wouter noemde: de setters, een hiërarchie van klassen of de applicatie.
>> Soms is het nuttig, meestal niet. Je kunt bijvoorbeeld een class hebben die tijdelijk read-only moet zijn.
Kun je een voorbeeld geven?
De class die ik nu heb kun je alleen locken en niet unlocken. Stel je krijgt bijv. externe data binnen, dan kun je het object locken zodat je geen data kunt toevoegen of wijzigen.
Nu had ik dus keurig een public is_locked method gemaakt, zodat een andere class kan testen of het object gelocket is. Het idee was zeg maar dit:
<?php
if (!$foo->is_locked()) {
$foo->add($bar);
}
?>
Maar achteraf zat ik dus te bedenken... oké.. ik wil iets toevoegen, maar stel dat het object wél gelocked is. Wat dan? Dan kan ik dus de data niet toevoegen. En dat slaat volgens mij nergens op. Dus, ik wil iets toevoegen, maar ojee... het object zit op slot dus dan voeg ik maar niks toe. Volgens mij, en zeg het me aub als ik het verkeerd zie of als ik iets over het hoofd zie, slaat dat nergens op. Volgens mij moet je op het moment dat je iets gaat toevoegen simpelweg zelf 100% zeker weten dat dit ook kan. En vanuit dat oogpunt heeft volgens mij die is_locked() method dus geen enkele toegevoegde waarde. Mee eens?
Uitputtelijke resources zijn een voorbeeld. Tijdens het formatteren van een harde schijf kun je er bijvoorbeeld niets op opslaan.
Een ander voorbeeld is een active record pattern voor objecten die maar door één gebruiker of proces tegelijk kunnen worden gewijzigd.
Voor al die situaties geldt, zoals gezegd, dat het ook anders kan, zonder is_locked(). Je zou bijvoorbeeld de setters tijdelijk dienst kunnen laten weigeren. Of je legt de verantwoordelijkheid bij de applicatie en laat die de toestand van het systeem als geheel controleren.
Hmm... oké.. ik denk dat de situaties die jij noemt niet van toepassing zijn op de objecten die ik voor ogen heb.
Bij mij gaat het gewoon om objecten die onderdeel zijn van het framework. Ik zou bijv. in zo'n object de POST data kunnen opslaan. Door het object te locken, voorkom ik dat iemand de POST data kan wijzigen, want dat wil je natuurlijk niet. Maar die is_locked method voegt dus niets toe, dus die sloop ik eruit.
