Traits w PHP Opcje

[pitbull82]

Witam

Tak się zastanawiam nad przydatnością traits w php. Nie wiem czy dobrze rozumiem ideę, ale widzę ich zastosowanie jako np. zastąpienie globalnych funkcji zdefiniowanych przez użytkownika. Do tej pory można sobie było zdefiniować funkcję, ale nigdy nie było wiadomo czy w kolejnej wersji php nie wprowadzą funkcji o takiej samej nazwie i będzie problem. Teraz wystarczy dodać taką funkcję do traits i może być wykorzystana w klasach które tego potrzebują. Jako przykład traits widziałbym np. wrzucenie tam funkcji umożliwiających operacje na plikach/katalogach typu usuwanie katalogu z zawartością i potem wykorzystywanie w klasach które potrzebują takiej funkcjonalności.

Proszę o opinię czy dobrze to rozumiem. Może Wy macie jakieś inne pomysły/odczucia?

Pozdrawiam

[hind]

mechanizm Traits jest opisywany jako "kopiuj" i "wklej" kawałka kodu, umozliwia dziedziczenie po więcej niż jednej klasie (extends)

[thek]

Nie ma to jak sięgnąć do paru miejsc:
http://php.net/manual/en/language.oop5.traits.php
http://webhosting.pl/PHP.5.4.wprowadzi.obs...ch.%5Btraits%5D
http://blog.wsoczynski.pl/2011/03/22/jezyk...hp-pt-3-traits/
Przeczytawszy na pewno wiele wątpliwości rozwiejesz, ale w najprostszym wariancie to jest faktycznie umożliwienie różnym klasom dostępu do do tych samych funkcjonalności.

[skowron-line]

Do listy linków @thek -a dorzucę jeszcze
https://wiki.php.net/rfc/traits

[wookieb]

http://forum.php.pl/index.php?s=&showt...st&p=908472

[mortus]

umozliwia dziedziczenie po więcej niż jednej klasie (extends)

Niezupełnie, a już na pewno bez słówka extends. W PHP klasy mogą nadal dziedziczyć tylko po jednej klasie. Traits-y natomiast umożliwiają danej klasie przejęcie pewnych funkcjonalności i/lub cech, które może posiadać również inna klasa, zupełnie niezależna (nazywa się to dziedziczeniem poziomym). Traits-y to przeważnie zbiory tych funkcjonalności, a czasami zbiory pewnych ustawień (properties), jednakowych dla kilku różnych klas. Obiekt klasy A, posiadający trait B, nie jest obiektem klasy B, jak to jest w przypadku dziedziczenia pionowego.

[wookieb]

@mortus w innych językach klasa dziedziczy również tożsamość traits-a (Ruby, Scala), czyli istnieje możliwość wykonania operacji

Kod

object instanceof TraitName; // true jeżeli używa traits-a

[mortus]

@mortus w innych językach klasa dziedziczy również tożsamość traits-a (Ruby, Scala), czyli istnieje możliwość wykonania operacji

Kod

object instanceof TraitName; // true jeżeli używa traits-a

Dobrze wierdzieć, bo myślałem, że jednak nie. Sprawdzę, jak jest w PHP, jak będę miał możliwość.

[wookieb]

W php tak nie jest...

[thek]

Dlatego idealnie do traitsa pasuje jego słówko dodające "use". Klasa więc używa traitsa i jego własności czy metod, które dostarcza. Do pewnego stopnia traitsy więc są natychmiast dostarczalną wersją interfejsów (choć same także modą mieć metody abstrakcyjne i coś wymuszać tym samym). O ile jednak interfejsy mówią, że klasa musi posiadać to czy tamto, o tyle traitsy mogą wprost już dać określone możliwości z samego faktu deklaracji jego użycia przez klasę. Część osób, nie bez powodów, widzi jego wykorzystanie w pewnych sytuacjach jako zastępnik Dependancy Injection Container.

@wookieb: fajna właściwość... i co najważniejsze - logiczna. W końcu jeśli klasa używa konkretnego traitsa, to można się posłużyć wszystkim co on udostępnia, więc można to nazwać instancją traitsa, która jest bogatsza o to, czego traits jest "częścią". Szkoda, że PHP nie idzie tą samą drogą...

Powód edycji: [thek]: Małe dopowiedzenia ;)

[wookieb]

@wookieb: fajna właściwość... i co najważniejsze - logiczna. W końcu jeśli klasa używa konkretnego traitsa, to można się posłużyć wszystkim co on udostępnia, więc można to nazwać instancją traitsa, która jest bogatsza o to, czego traits jest "częścią". Szkoda, że PHP nie idzie tą samą drogą...

Ale jest rozwiązanie. Traits + interface
http://www.slideshare.net/wookieb/iteratory slajd 32

[Crozin]

Do tej pory można sobie było zdefiniować funkcję, ale nigdy nie było wiadomo czy w kolejnej wersji php nie wprowadzą funkcji o takiej samej nazwie i będzie problem.

Narzędziem do rozwiązywania tego problemu są przestrzenie nazw.

Jako przykład traits widziałbym np. wrzucenie tam funkcji umożliwiających operacje na plikach/katalogach typu usuwanie katalogu z zawartością i potem wykorzystywanie w klasach które potrzebują takiej funkcjonalności.

Takie rzeczy jak odczytywanie katalogów czy usuwanie plików to dosyć skomplikowane operacje i powinny być one wykonywane przez zupełnie osobne obiekty.

Część osób, nie bez powodów, widzi jego wykorzystanie w pewnych sytuacjach jako zastępnik Dependancy Injection Container.

Mógłbyś podać przykład takiej sytuacji, bo szczerze powiedziawszy ciężko mi jest sobie to wyobrazić.

@wookieb: fajna właściwość... i co najważniejsze - logiczna. W końcu jeśli klasa używa konkretnego traitsa, to można się posłużyć wszystkim co on udostępnia, więc można to nazwać instancją traitsa, która jest bogatsza o to, czego traits jest "częścią".

Nie do końca logiczna, bo PHP umożliwia manipulowanie tym traitsem (można to słówko jakoś sensownie tłumaczyć). Innymi słowy metoda zdefiniowana jako publiczna w traitsie może zostać "przestawiona" na prywatną w danej klasie. Jednak nawet nie to jest tutaj powodem - nigdy (nie potrafię znaleźć sytuacji poza jakimiś mechanizmami refleksji) nie powinno się interesować czy dany obiekt korzysta z traitsa czy nie - to jego wewnętrzna sprawa. W takich miejscach powinno użyć się interfejsów.

Co do samego pytania. Traitsy jakiejś wielkiej rewolucji nie wprowadzają - a przynajmniej nie powinny. Mało widzę dla nich sensownych zastosowań. Ale i w pewnych miejscach mogłyby być całkiem użyteczne. Gdzie? Na przykład przy domyślnej (albo jednej z predefiniowanej) implementacji interfejsu. Załóżmy, że mamy jakiś interfejs co do którego jesteśmy pewni, że większość jego implementacji będzie wyglądać dokładnie tak samo. Przykładowo interfejs Symfony\Component\DependencyInjection\ContainerAwareInterface. Niemal w całym (a może i w całym) frameworku jak i w kodach aplikacji na nim zrealizowanych ten interfejs jest implementowany w następujący sposób:

[PHP] pobierz, plaintext 
class ... implements ContainerAwareInterface {
  private $container;
 
  function setContainer(ContainerInterface $container = null) {
    $this->container = $container;
  }
}
[PHP] pobierz, plaintext 

Nic by się nie stało gdyby istniał traits Symfony\Component\DependencyInjection\ContainerAwareInterfaceImplementation, wtedy w większości miejsc można by zastosować:

[PHP] pobierz, plaintext 
class ... implements ContainerAwareInterface {
  use ContainerAwareInterfaceImplementation;
}
[PHP] pobierz, plaintext 

Oczywiście wszędzie sprawdzałoby się czy dany obiekt implementuje interfejs ContainerAwareInterface, a nie traitsa ContainerAwareInterfaceImplementation.
Jednak nawet i tak nieinwazyjne zastosowanie ma wady - bo co jeśli ktoś zmieni definicję tego traitsa? Bardzo nieciekawy w diagnostyce problem.

[thek]

@Crozin: W przypadku prostszych, mniejszych, aplikacji użycie DIC może być nieco sztuką dla sztuki, jeśli przewidujemy użycie raptem kilku możliwości, które są bardzo szablonowe. Przykładem takiego prostego rozwiązania jest zapis/odczyt danych. Jeśli mamy do czynienia naprawdę z kobyłą elastyczną - ma to sens, bo nigdy nie wiemy przecież co nam za źródło ostatecznie może posłużyć. Jeśli jednak znamy ograniczenia, możemy się ograniczyć do jednej klasy lub właśnie traitsa, który nam to połączenie ze źródłem umożliwi. Definiujemy sobie traitsa z tym połączeniem i już mamy spokój. Zwyczajnie dajemy use TraitsPołączenia klasie i zapominamy. Zauważ, że nie bez powodu pisząc swój tekst używałem słów: "może", "w określonych wypadkach/sytuacjach". Nie są to jedynie zabiegi stylistyczne z mojej strony i jestem świadom, że ma to rozwiązanie swoje wady i zalety.

To co potem rozważałeś to właśnie dobry przykład dla prostego serwisu. "Zapytałbym" o to, czy to co mnie interesuje ma traitsa RDBConnection i byłbym pewien co do możliwości operacji na jakiejś tam bazie danych, którą to ów traits by mi udostępniał. Owszem, mógłbym zamiast traitsa użyć osobnej klasy połączenia, DIC pozwalający mi na elastyczne podejście do tego, czy inne rozwiązanie problemu zaproponować, ale równie dobrze mogę użyć traitsa, który będzie równie zapewne prostszy i szybszy w implementacji niż elastyczniejsze ale przez to bardziej złożone mechanizmy.