[oop] class locken

Door Ozzie PHP op 14-05-2014 17:53

2.648 views

Ola,

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?

Ozzie PHP

14-05-2014 21:32

Ah oké.. ik gebruik een universele class waar dat al in zit en daar is het zeker geen onzin. Maar voor de verdere discussie is dat een irrelevant detail.

Ger van Steenderen

14-05-2014 21:38

Als jij één universele class bouwt, voor wat dan?
Ik denk dat het binnen OOP zeer significant is.

Ozzie PHP

14-05-2014 21:42

Het is een class om data vast te houden. Het kan bijv. POST data zijn, of COOKIE data, maar ook configuratie data, of data afkomstig van een externe partij. Sommige frameworks noemen het ook wel een parameter bag. Het voordeel is dat je niet voor alles een niewe class hoeft te maken, maar gewoon één universele class gebruikt.

Wouter J

14-05-2014 22:48

Vervolgens maak je dus ook een LockedParameterBag of een ImmutableParameterBag of hoe je het ook noemt, die alleen maar getters bevat.

Ozzie PHP

14-05-2014 23:46

Hoe moet ik dan zonder setters de informatie setten? :-s

Ward van der Put

15-05-2014 07:04

Je kunt de setters private in plaats van public maken en vervolgens de parameter bag via de constructor vullen:

public __construct(array $parameters = array()) {...}

Ozzie PHP

15-05-2014 13:01

Dat zou kunnen, maar daar zie ik zelf wel nadelen aan. Ik zou dan rechtstreeks vanuit de constructor setten, en niet met aparte setters werken. En, het kan ook zo zijn dat ik op meerdere plekken iets wil toevoegen en de class daarna pas wil locken. Dat gaat in deze opzet niet.

Ward van der Put

15-05-2014 13:09

Je zou het bijvoorbeeld ook met de setters zelf kunnen regelen, een van de andere alternatieven. Laat de setters alleen parameters accepteren die nog niet in de locked paramater bag voorkomen. Komt een parameter wel voor, dan wordt die geweigerd of genegeerd. De verantwoordelijkheid over de juistheid van de parameters plaats je bij validators buiten de parameter bag, zodat je parameter bag uitsluitend bruikbare data bevat.

Ozzie PHP

15-05-2014 13:13

Maar ik snap niet echt wat je bedoelt Ward. Ik heb gewoon een object met setters en getters. op het moment dat je het object locket, dan kun je geen gegevens meer wijzigen/toevoegen/verwijderen. Doe je dat wel, dan volgt een exception. Dat is toch een prima oplossing? Of zie ik iets over het hoofd?

Ward van der Put

15-05-2014 13:47

Je kunt de storage "semi-permeabel" maken. Zó kun je er van alles insteken en weer uithalen, maar iets dat eenmaal vastligt, blijft vastliggen:


<?php
class ImmutableParameterBag
{
    private $Parameters = array();

    public function set($key, $value)
    {
        if (!array_key_exists($key, $this->Parameters)) {
            $this->Parameters[$key] = $value;
        }
    }

    public function get($key)
    {
        if (array_key_exists($key, $this->Parameters)) {
            return $this->Parameters[$key];
        } else {
            return null;
        }
    }
}
?>

Het hangt er echter nogal van af:

- wil je in één keer een locked object hebben (gebruik bijvoorbeeld de constructor);

- wil je meer gecontroleerd in stappen read-only data hebben (gebruik bijvoorbeeld de setters);

- wil je een open object hebben dat alleen op afroep locked wordt (gebruik bijvoorbeeld een methode).

Wáárom wil je data of objecten locked maken? Die vraag hoort er eigenlijk aan vooraf te gaan.

Reageren

Inloggen om te reageren