Przykrycie konstruktora metodą

Question

<?php

class Person
{
    private $name;
    private $surname;
    
    private function __construct($name, $surname)
    {
        $this->name    = $name;
        $this->surname = $surname;
    }
    
    public static function born($name, $surname)
    {
        return new self(
            $name,
            $surname
        );
    }
    
    public function changeName($newName)
    {
        $this->name = $name;
    }
}

$newPerson = Person::born('event', '15');
$newPerson->changeName('efik');

Oto kodzik. 

Mówię o zaletach. Klasy Person nie wywoła się w żaden sposób jak tylko poprzez znaną metodę born. Nikt nigdzie w kodzie nie stworzy tego poprzez new Person(). 

Chciałbym poznać opinię waszą na temat tego rozwiązania. 

Temat jest też poruszony na PHPersach

Answer 1

Moje zdanie:
Jako iż nie potrafię tego lepiej wytłumaczyć odwołam się do "Rzeczywistości"
Klasa Person nie powinna być odpowiedzialna za "rodzenie nowej osoby".  ( Osoba sama się rodzi?? :D ) Nie powinna wgl posiadać takiej metody. Tą funkcją powinna zajmować się "Matka" tzn fabryka(factory method) która tworzy Ci odpowiednią osobę. :)

PS: Można dodać jeszcze final

Comments

No tak, ale pomińmy nomenklaturę osoby.

W momencie, gdy mam tylko jeden rodzaj obiektu który tworzę używanie fabryki będzie generacją niepotrzebnego kodu.

Racja - stworzy to nam możliwość W PRZYSZŁOŚCI dodania nowych typów podobnych do tego obiektu. Ale w tej chwili wydaje się to zbędne.

jeżeli już by zamieniać to factory method.

---

tej chwili może tak, ale kto wie ...

Moim zdaniem powinieneś zerknąć sobie jak projektował Norbert repozytorium MyDrinks na GH.

Czekamy na opinię innych^^

---

Z final jest tak że PHPSpec nie łapie go ze względu na mechanizm refleksji :D

---

W ramach zaproszenia od efika  jaki jest cel tego żeby osoba rodziła drugą siebie? xD

---

Hmm jest to agregate root w domenie. Powinien być jedyną "wtyczką" dostępu do wszystkich innych encji. W rzeczywistości polega to na tym, że poprzez tą klasę istnieje dostęp do zachowań innych klas, które są w kontekście agregatu.

Ona nie rodzi drugiej siebie. Ona hermetyzuje ściśle informacje o swojej implementacji poprzez stworzenie prywatnego konstruktora (którego nie da się nigdzie indziej wywołać) i przykrycie go specjalną metodą wytwórczą.

---

Skoro już factory, to nie można zapomnieć zakodzić service, który nam je zwróci. Oczywiście wszystko ma swój własny interfejs, prawda?

---

Zależy, co rozumiesz przez "wszystko" @Comandeer

---

To się nazywa "Named Constructors" i rozwiązuje zagadnienie przeciążania konstruktorów w PHP, przy okazji ma zalety wyżej wymienione.

W niektórych przypadkach jest to ok, ale w chwiil, gdy nie ma się zupełnej pewności odnośnie ostatecznego wyglądu encji to lepiej pomyśleć o prostej factory method.

 

http://verraes.net/2014/06/named-constructors-in-php/

Problem raczej uznaję za rozwiązany.

---

To zamykaj ;)

Answer 2

Dostałem feedback na ChatRepajr.

Wady tego kodu mogą być takie: Narusza to w pewien sposób zasady SOLID, a dokładnie zasadę pojedyńczej odpowiedzialności no i zasadę open/close, czyli otwarte na rozszerzenia i zamknięte na zmiany.

O ile open/close rozumiem o tyle zastanawiam się nad SRP i nie do końca widzę w jaki sposób?