[rozdajozadarmo]

Gdy chcę zastosować zasadę Composition over inheritance w #php, ale chcę przy okazji uniknąć powielania tego samego kodu w klasach implementujących interfejs, to czy dobrym pomysłem jest używanie Traitów?

[MacDada]

@rozdajozadarmo: tak, traity lub klasy abstrakcyjne

Ale… ile masz tych metod? Może interface jest zbyt duży i powinien być rozbity na kilka mniejszych? Jedna z zasad SOLID: https://en.wikipedia.org/wiki/Interface_segregation_principle

[MacDada]

@rozdajozadarmo: Jako przykład popatrz na PSRowy LoggerInterface. Ma on sporo metod.

Żeby więc uniknąć duplikacji przy tworzeniu implementacji, dostępny jest LoggerTrait i AbstractLogger.

[rozdajozadarmo]

@MacDada:

Ale… ile masz tych metod?

Na razie nie mam żadnych. To pytanie czysto teoretyczne.

Jako przykład popatrz na PSRowy LoggerInterface. Ma on sporo metod. Żeby więc uniknąć duplikacji przy tworzeniu implementacji, dostępny jest LoggerTrait i AbstractLogger.

Dzięki, zapoznam się.

[rozdajozadarmo]

@MacDada

Dzięki za linki do Loggera. Tak właśnie sobie własnie to wyobrażałem. Mam tylko jedną wątpliwość. Po co robią Trait oraz klasę abstrakcyjną? Obie rzeczy robią dokładnie to samo.

Podejrzewam, że po prostu czasami używają dziedziczenia z klasy abstrakcyjnej, a czasami używają Traita, tylko po co?

[MacDada]

@rozdajozadarmo: Bo nie ma jedynej słusznej metody – w takiej sytuacji są zawsze te dwie opcje i twórcy PSR dostarczyli je do użycia.

A które rozwiązanie użyć? To już zależy trochę od sytuacji i osobistej preferencji.

Osobiście unikam traitów i użyłbym klasy abstrakcyjnej. Jest to powszechniejsze rozwiązanie i dużo lepiej zakorzeniony pomysł. Dziedziczenie pionowe to klasyka OOP.

Traity pojawiły się w PHP „niedawno” i służą trochę jak „zautomatyzowane kopiuj–wklej” – z

[Jurigag]

@MacDada: imho trait wg mnie powstał po to aby stosować je w różnych klasach które nie "mogą" rozszerzać z jakiegoś powodu tej samej abstrakcyjnej klasy(bo są one po prostu czymś innym)

[rozdajozadarmo]

@MacDada
Dzięki za wyjaśnienie.

Osobiście unikam traitów i użyłbym klasy abstrakcyjnej. Jest to powszechniejsze rozwiązanie i dużo lepiej zakorzeniony pomysł. Dziedziczenie pionowe to klasyka OOP.

No właśnie. Tak więc jeśli chcę stosować zasadę Composition over inheritance, to raczej powinienem użyć Traitów. Prawda (nie chcę wchodzić w dyskusję czy dziedziczenie jest złe czy nie :))

Traity pojawiły się w PHP „niedawno” i służą trochę jak „zautomatyzowane kopiuj–wklej” – z zewnątrz klasy nie

[MacDada]

jeśli chcę stosować zasadę Composition over inheritance, to raczej powinienem użyć Traitów

@rozdajozadarmo: Możesz rozszerzyć możliwości obiektu poprzez zrobienie nowego obiektu i kompozycję albo poprzez dziedziczenie. I jeśli masz do wyboru obie opcje –> zalecana jest raczej kompozycja niż dziedziczenie.

Tu masz przykład takiej sytuacji: https://gist.github.com/MacDada/4527f591f0f8437b804e1d3cd24bd0be

Mając do wyboru 3 powyższe opcje, zasada mówi, żeby preferować kompozycję. Traity traktuje się jako dziedziczenie poziomie (w przeciwieństwie do rozszerzania klas, czyli dziedziczenia pionowego).

[rozdajozadarmo]

@MacDada

Wychodzi na to, że dotychczas nieświadomie używałem właśnie kompozycji (sposobu z composition.php :)

Dzięki za wyjaśnienie sprawy traitów, nie patrzyłem na nie wcześniej jak na dziedziczenie poziome.