http://stronger.epsi.pl/2008/02/22/traits-w-php/Wpisy z dziennika internetowego Jogger, wspomaganego przez JabberaWed, 10 Mar 2010 10:42:52 +0100JoggerPLhttp://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093179Trochę inaczej to wygląda, gdy używasz dokładnie tak samo działającej metody w różnych klasach. W Twoim przykładzie one się różnią (dla różnych klas jest tworzony obiekt SearchEngine z innymi parametrami), pomijając tutaj każdorazowe tworzenie obiektu przy każdym żądaniu szukiwajki - składam to na karb oszczędności w pisaniu :)A co jeśli masz w różnych klasach dać dokładnie tą samą funkcję, działającą tak samo etc?Wtedy pisanie:class A { function search () { return new SearchEngine (); }}class B { function search () { return new SearchEngine (); }}Jest nadmiarowością. Powtarzasz kod. Jeszcze gorzej, gdy powinna być tam jakaś konfiguracja etc, która zawsze będzie taka sama. OK, da się to obejść - tworzysz jeszcze jedną funkcję, która robi co trzeba z konfiguracją SearchEngine i zwraca obiekt, a w A::search () wywołujesz tąże funkcję etc etc...Natomiast Traitsy pozwalają na uproszczenie, ułatwienie zapisu:trait search { function search () { return new SearchEngine (); }}class A { use search;}class B { use search;}IMO ma to sens.Fri, 22 Feb 2008 18:02:16 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093179http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093251@MySZ:"A co jeśli masz w różnych klasach dać dokładnie tą samą funkcję, działającą tak samo etc?"Wyciągasz klasę nadrzędną, a te dwie różne implementujesz jako specjalizacja.Fri, 22 Feb 2008 20:03:26 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093251http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093297@mwd: to jest dobre tylko przy prostych przypadkach. Owszem, zawsze da się zastosować jakąś _kombinację_, ale to zawsze będzie jakaś nadmiarowość, której wielodziedziczenie, czy też wersja proponowana tutaj (traitsy) pozwalają uniknąć.Fri, 22 Feb 2008 20:52:25 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093297http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093439MySZ, jeśli w ogóle nie ma różnic, to po co implementować tą metodę wewnątrz klasy? Lepiej wówczas delegować ją do oddzielnej klasy, bo jej związek z przedmiotową klasą jest i tak dość luźny.mwd, nie możesz wyciągnąć wspólnej klasy bazowej, bo mówimy tu o klasach z różnych przodków. Nie ma tego w powyższych przykładach, ale takie jest założenie i cel Traitsów.Fri, 22 Feb 2008 23:46:02 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093439http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093449@str(): "MySZ, jeśli w ogóle nie ma różnic, to po co implementować tą metodę wewnątrz klasy?"Dla zachowania czytelności interfejsu. Razi mnie np pythonowe len() - imo poszczególne struktury powinny mieć metodę .len() zamiast stosowania globalnej funkcji.Fri, 22 Feb 2008 23:52:56 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1093449http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1094532MySZ, ależ czytelność interfejsu jest zachowana właśnie przez jawną deklarację interfejsu. Nie proponuję tu wprowadzania globalnych funkcji, a stworzenie klasy usługowej - w tym przypadku wyszukiwarki. Ponadto osobna klasa przyda się, jeśli chcesz w niej mieć więcej niż jedną metodę.Co do Twojej uwagi w pierwszym komencie o tworzeniu dodatkowej instancji - obiekty w PHP są *cholernie* szybkie, prawie tak szybkie jak prymitywy, a na pewno szybsze niż tablice. Nie oszczędzam czasu procesora - on jest tani, oszczendzam za to czas swój i koderów, którzy w przyszłości będą korzystać/rozbudowywać program. Czas programisty jest bardzo drogi (czego wszystkim życzę ;-)Sun, 24 Feb 2008 14:48:07 +0100http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1094532http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1185201> niektórzy developerzy nie odrobili lekcji i gówno wiedzą o interfejsach, kompozycji i delegacji odpowiedzialności do klas usługowychMiałbyś jakieś dobre linki do informacji lub tytuły książek na ten temat? Byłbym wdzięczny, bo gówno wiem :PWed, 11 Jun 2008 00:52:12 +0200http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1185201http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1189868Służę: A. Shallowai, J. Trott - Design Patterns Explained: A New Perspective on Object-Oriented Design (jest też jej polskie tłumaczenie, ale nakład został wyczerpany) - bardzo dobra książka. Ponadto klasyczna pozycja Design Patterns: Elements of Reusable Object-Oriented Software - sprawdź w Wikipedii pod hasłem "Gang_of_four_(software)". Na koniec jeszcze coś nowszego: M. Fowler - Patterns of Enterprise Application Architecture. Wszystkie godne polecenia, ponadto na www.dofactory.com znajduje się przystępnie rozpisany katalog wzorców.Mon, 16 Jun 2008 17:42:26 +0200http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1189868http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1189883Dziekowac.Mon, 16 Jun 2008 18:09:27 +0200http://stronger.epsi.pl/2008/02/22/traits-w-php/#c1189883