Temat: False Friend Class pattern ;)

Cześć!

Dziś chciałbym przypomnieć pewną konstrukcję z C++. Programiści tegoż języka znają klasy zaprzyjaźnione:

class A{

}



class B{

  friend class A;

}

Objaśnienie dla pozostałych: http://pl.wikipedia.org/wiki/Klasa_zaprzyja%C5%BAniona - w skrócie, dzięki deklaracji "friend class", klasa A może traktować prywatne atrybuty i metody klasy B jak swoje, tj. ma do nich dostęp.

Czemu o tym wspominam? Przeglądałem ostatnio nowości w PHP 5.4, zauważyłem nowe metody klasy Closure: ::bind() i ->bindTo(). Przyszło mi na myśl, że mogą umożliwiać zaprzyjaźnianie klas. Po chwili jednak zmieniłem zdanie - wszak klasy w C++ mogą wybierać przyjaciół, tutaj przyjaciele się narzucają. Wobec powyższego powstał wzorzec* False Friend Class: http://pastebin.com/cZYbCuhw ;)

Not big deal, just a ciekawostka.

---
* wzorzec, bo nie jest wbudowany w język. Na podstawie tego, możemy się przy okazji pokusić o stwierdzenie, że zbiór wbudowanych cech języka, to zbiór wspieranych przezeń wzorców projektowych.Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 07:28

Temat: False Friend Class pattern ;)

W skrócie, wymyśliłeś jakąś głupotę, wrzuciłeś w to magię, upewniłeś się że zaciemniłeś kod jak się tylko da, nadałeś mu głupią nazwę i uważasz że właśnie powstał wzorzec projektowy.
Jeżeli jest to wzorzec to już prędzej - antywzorzec.

Przypomina mi się jeden taki który naprodukował się jak idiota żeby napisać kilka linijek kodu pozwalającego z tekstu wybrać pierwsze słowo tylko po to by się przekonać że i do wybrania pierwszego słowa PHP ma funkcję.

Teraz już wiem czemu podpisujesz się "Programista Artysta". Uprawiasz sztukę dla sztuki.

I tak drogi Łukaszu naprodukowałeś się (bo z tego co widzę, Google nic nie mówi o False Friends Class więc zakładam że ten potworek jest Twój) tylko po to by zrobić coś co w PHP już jest i to w formie dość ciekawej bo:
~ możemy dokładać zestawy metod i atrybutów jak nam się podoba
~ nie musimy się przejmować konfliktami bo możemy wskazać dokładnie jakie metody wybrać (jeżeli 2 traitsy dostarczają te same metody to możemy skazać który traits użyć
~ możemy nakładać aliasy
~ możemy zmieniać widoczność dokładanych metod
~ możemy również dokładać funkcje anonimowe jak słusznie pokazałeś z pomocą innego mechanizmu

http://php.net/manual/en/language.oop5.traits.php

Pozdrawiam.

PS: Pewnie nie czepiał bym się gdybyś wspominał o starszych wersjach PHP chociaż tego potworka nie użył bym nawet jak by mi za to próbowali zapłacić ale mówisz o PHP 5.4 gdzie traitsy już są i mają się dość dobrze. Dariusz Półtorak edytował(a) ten post dnia 25.06.12 o godzinie 08:30

Temat: False Friend Class pattern ;)

Trochę za dużo magii jak dla mnie w tym 'wzorcu'.
Poza tym wzorzec to nie sam kod, właściwie kod możesz uznać za produkt implementacji wzorca.
Kiedy się powinno go stosować? Dlaczego? Co Ci daje jego implementacja, jakie korzyści? Jaka jest jego struktura?
Bez odpowiedzi na powyższe pytania nie masz co mówić o wzorcu.

Temat: False Friend Class pattern ;)

O Darku to nic nie powiem, bo jak zwykle spina poślady i myśli, że jest guru czegokolwiek :) Poza tym produkuje kilometrowe posty nie na temat, bez zrozumienia, żadna nowość... W najśmielszych snach bym nie wymyślił, że dostęp do prywatnych atrybutów innej klasy może mieć coś wspólnego z traitsami...

......

Pokazałem prostą technikę włamania do obiektu za pomocą podstawowych mechanizmów PHP. A czy Wy widzicie tam może słowo "ciekawostka" i emotikonę wskazującą na humorystyczny akcent?

N/C :)

Temat: False Friend Class pattern ;)

Łukasz K.:
O Darku to nic nie powiem, bo jak zwykle spina poślady i myśli, że jest guru czegokolwiek :) Poza tym produkuje kilometrowe posty nie na temat, bez zrozumienia, żadna nowość... W najśmielszych snach bym nie wymyślił, że dostęp do prywatnych atrybutów innej klasy może mieć coś wspólnego z traitsami...

Ok. Wytłumaczę jeszcze raz. Prosto i zrozumiale. Tak że nawet Ty zrozumiesz.
1. Coś jest w innej klasie dlatego że POWINNO BYĆ W INNEJ KLASIE.
2. Coś jest prywatne bo POWINNO BYĆ prywatne. Jak by ktoś chciał by dana metoda była dziedziczona to zrobił by ją chronioną.
3. Mechanizm który opisujesz można osiągnąć stosując traitsy, w lepszy, bardziej elegancki, czytelny i możliwy do bezproblemowego debugowania sposób który przy okazji oferuje znacznie więcej niż to co pokazujesz.

......

Pokazałem prostą technikę włamania do obiektu za pomocą podstawowych mechanizmów PHP. A czy Wy widzicie tam może słowo "ciekawostka" i emotikonę wskazującą na humorystyczny akcent?

N/C :)

W skrócie - pokazałeś coś co nie jest zabawne i dodatkowo jest bezużyteczne. I jeszcze nazwałeś to wzorcem projektowym. Jak bym chciał "włamywać się" do obiektów to zamiast robić coś tak głupiego, zmienił bym metodę/atrybut na publiczny za pomocą refleksji w obrębie klasy, użył co trzeba i przywrócił prywatny/chroniony dostęp.
Bez magi, bez zaciemniania, bez głupot.

Pomijam fakt że było by to bezdennie głupie z uwagi na owe 2 punkty które wymieniłem na początku postu.

Jak publikujesz coś na forum publicznym - chyba jasne że ktoś inny podda to krytyce. Dowcip czy nie dowcip.

Temat: False Friend Class pattern ;)

Ej, ale po co? Łamiesz enkapsulację i nie robisz nic więcej. Z klasami zaprzyjaźnionymi znanymi z C++ nic wspólnego to nie ma, wszak to klasa, która udostępnia swoje atrybuty, deklaruje przyjaźń, a nie klasa zewnętrzna, jak u Ciebie. To jest wejście od dupy strony, a nie przyjaźń :)

Temat: False Friend Class pattern ;)

Dariusz Półtorak:

Łukasz K.:
O Darku to nic nie powiem, bo jak zwykle spina poślady i myśli, że jest guru czegokolwiek :) Poza tym produkuje kilometrowe posty nie na temat, bez zrozumienia, żadna nowość... W najśmielszych snach bym nie wymyślił, że dostęp do prywatnych atrybutów innej klasy może mieć coś wspólnego z traitsami...

Ok. Wytłumaczę jeszcze raz. Prosto i zrozumiale. Tak że nawet Ty zrozumiesz.
1. Coś jest w innej klasie dlatego że POWINNO BYĆ W INNEJ KLASIE.
2. Coś jest prywatne bo POWINNO BYĆ prywatne. Jak by ktoś chciał by dana metoda była dziedziczona to zrobił by ją chronioną.

Co Ty nie powiesz, geniuszu Ty mój :D

3. Mechanizm który opisujesz można osiągnąć stosując traitsy, w lepszy, bardziej elegancki, czytelny i możliwy do bezproblemowego debugowania sposób który przy okazji oferuje znacznie więcej niż to co pokazujesz.

To traitsy też oferują możliwość włamania do obiektu? Pokaż.

Pomijam fakt że było by to bezdennie głupie z uwagi na owe 2 punkty które wymieniłem na początku postu.

Wciąż nie rozumiesz, że piszesz nie na temat, czy po prostu brniesz, bo już zacząłeś? :)Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 11:58

Temat: False Friend Class pattern ;)

Jacek R.:
Ej, ale po co? Łamiesz enkapsulację i nie robisz nic więcej. Z klasami zaprzyjaźnionymi znanymi z C++ nic wspólnego to nie ma, wszak to klasa, która udostępnia swoje atrybuty, deklaruje przyjaźń, a nie klasa zewnętrzna, jak u Ciebie. To jest wejście od dupy strony, a nie przyjaźń :)

Napisałem to chyba? ;) [Fakt, nie wprost]. Dlatego nazwałem to False Friend i użyłem np. $betrayalTool. Oczywiście, że nie powinno się tego robić (no chyba, że mamy do czynienia z jakąś zew. klasą, do której MUSIMY się dobrać).

W oryginale nazwałem to Rapist Class, ale uznałem, że nie powinniśmy aż tak brutalnie nazywać tego, na co pozwala PHP 5.4. Byłeś jednak blisko z tym ostatnim zdaniem ;)Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 11:59

Temat: False Friend Class pattern ;)

Łukasz K.:

Jacek R.:
Ej, ale po co? Łamiesz enkapsulację i nie robisz nic więcej. Z klasami zaprzyjaźnionymi znanymi z C++ nic wspólnego to nie ma, wszak to klasa, która udostępnia swoje atrybuty, deklaruje przyjaźń, a nie klasa zewnętrzna, jak u Ciebie. To jest wejście od dupy strony, a nie przyjaźń :)

Napisałem to chyba? ;) [Fakt, nie wprost]. Dlatego nazwałem to False Friend i użyłem np. $betrayalTool. Oczywiście, że nie powinno się tego robić (no chyba, że mamy do czynienia z jakąś zew. klasą, do której MUSIMY się dobrać).

W swoich wypowiedziach i zarzucaniu że "mówię nie na temat" zapominasz właśnie o tym o czym mówi @Jacek. Hermetyzacja to jedno z podstawowych założeń obiektówki. Sama hermetyzacja zawsze jest z jakiegoś powodu stosowana. Nikt bez przyczyny nie deklaruje metody/atrybutu jako prywatny/chroniony. Jeżeli ktoś nie chciał by dana metoda była publicznie dostępna i dziedziczona czyniąc ją prywatną to miał ku temu dobry powód.
Jeżeli do czegoś MUSISZ się dobrać to znaczy że coś robisz źle od samego początku i właśnie do początku powinieneś wrócić próbując przemyśleć cały problem ponownie. Robienie głupot nie jest odpowiedzią.

To traitsy też oferują możliwość włamania do obiektu?

Nie oferują bo nie ma takiej potrzeby. I jak już mówiłem, nie powinno się czegoś takiego robić. Zapoznaj się z traitsami i przemyśl to co robisz zamiast zadawać głupie pytania. Poza tym prościej by było zrobić taką głupotę za pomocą refleksji bo właściwie nie musimy nic robić dodatkowo. Tylko zmieniamy właściwości danej metody, stosujemy ją jak by była publiczna bez żadnych sztuczek i przywracamy te właściwości żeby nie robić jakiś konfliktów dalej. Ponownie - pomijając idiotyzm takiego rozwiązania.Dariusz Półtorak edytował(a) ten post dnia 25.06.12 o godzinie 12:42

Temat: False Friend Class pattern ;)

Dariusz Półtorak:

Łukasz K.:

atrybuty, deklaruje przyjaźń, a nie klasa zewnętrzna, jak u Ciebie. To jest wejście od dupy strony, a nie przyjaźń :)

Napisałem to chyba? ;) [Fakt, nie wprost]. Dlatego nazwałem to False Friend i użyłem np. $betrayalTool. Oczywiście, że nie powinno się tego robić (no chyba, że mamy do czynienia z jakąś zew. klasą, do której MUSIMY się dobrać).

Hermetyzacja to jedno z podstawowych założeń obiektówki. Sama hermetyzacja zawsze jest z jakiegoś powodu stosowana. Nikt bez przyczyny nie deklaruje metody/atrybutu jako prywatny/chroniony.

To traitsy też oferują możliwość włamania do obiektu?

Nie oferują bo nie ma takiej potrzeby. I jak już mówiłem, nie

Twój upór jest przezabawny :) Zrozum, że pokazuję, że PHP5.4 umożliwia na łamanie zasad hermetyzacji poprzez wzorzec przeciwny do Friend Class z C++. Nie zachęcam do notorycznego używania tego podejścia, chociaż w niektórych przypadkach taka magia może się przydać.

Temat: False Friend Class pattern ;)

Łukasz K.:

Zrozum, że pokazuję, że PHP5.4 umożliwia na łamanie zasad hermetyzacji poprzez wzorzec przeciwny do Friend Class z C++.

Po pierwsze - to nie jest wzorzec. Tutaj masz definicję
Po drugie - fakt, że da się coś robić, nie oznacza, że należy np. pisany przeze mnie kod może być nierozwijalny i mogłoby się go nie dać użyć już w 10 minut po napisaniu, bo byłby tak zagmatwany. Mógłbym coś takiego napisać, pewnie większość z nas potrafi, ale czy jest jakikolwiek sens? Czy zrobiłbym to świadomie?

Nie zachęcam do notorycznego używania tego podejścia, chociaż w niektórych przypadkach taka magia może się przydać.

Jeżeli projekt jest dobry, zależności i powiązania między klasami poprawne, to nie, nie przyda się i nie może, a jeżeli dojdziesz do momentu, gdy rzeczywiście kusi, to albo przemyśl wszystko raz jeszcze, bo może wpadniesz na inny pomysł, albo pora na refaktoring:)

Temat: False Friend Class pattern ;)

Łukasz K.:
Twój upór jest przezabawny :) Zrozum, że pokazuję, że PHP5.4 umożliwia na łamanie zasad hermetyzacji poprzez wzorzec przeciwny do Friend Class z C++. Nie zachęcam do notorycznego używania tego podejścia, chociaż w niektórych przypadkach taka magia może się przydać.

1. Jeżeli komuś się to przyda to znaczy że to co robi jest bezsensownie zaprojektowane i powinien wrócić do deski kreślarskiej. A jeżeli komuś w ogóle takie rozwiązanie przyjdzie do głowy to powinien zacząć się uczyć OOP od początku (nawet jeżeli ktoś chciał by obejść hermetyzację z jakiegoś powodu dla testów to już prędzej sięgnął by po refleksje).
2. PHP umożliwia łamanie zasad hermetyzacji od 8 lat poprzez refleksje.
3. "False Friend Class" to nie wzorzec projektowy. To Twój wymysł. I do tego jak napomknąłem wielokrotnie - głupi.
4. "Friends class" to nie wzorzec projektowy. To element języka C++. Dość częsta pomyłka. Poczytaj "Patterns of Enterprise Application Architecture" Fowlera. Wspomina on o takich pomyłkach i ludziach którzy je popełniają. Z jakiegoś nieznanego powodu niektórzy ludzie próbują nazwać wszystko co robią i podpiąć to pod wzorce projektowe.
5. Wspomniałem o traitsach na początku bo bliżej im do "friends class" niż temu Twojemu potworkowi. I przede wszystkim do tego się odnosiłem ignorując Twój pomysł z łamaniem hermetyzacji (patrz punkt 1).
6. Mój "upór" wynika z tego że jestem ciekaw co wyniknie z tego tematu.

Temat: False Friend Class pattern ;)

Dariusz Półtorak:
6. Mój "upór" wynika z tego że jestem ciekaw co wyniknie z tego tematu.

Dariuszu, fakt jest taki - tak jak ja bywam czepliwy, tak ty bywasz uparty :D

Temat: False Friend Class pattern ;)

Michał Wachowski:

Dariusz Półtorak:
6. Mój "upór" wynika z tego że jestem ciekaw co wyniknie z tego tematu.

Dariuszu, fakt jest taki - tak jak ja bywam czepliwy, tak ty bywasz uparty :D

Odkąd pamiętam byłem uparty :P Więc to żadne zaskoczenie.Dariusz Półtorak edytował(a) ten post dnia 25.06.12 o godzinie 13:51

Temat: False Friend Class pattern ;)

ale o co tyle krzyku?
po co tyle emocji personalnych?

jest jakiś pomysł - jest krytyka, zarówno jedno i drugie trzeba umieć przyjąć na klatę

Temat: False Friend Class pattern ;)

[wycofuje, nie chce mi sie dyskutowac]Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 17:11

Temat: False Friend Class pattern ;)

[wycofuje, bo nie chce mi sie dyskutowac na takim zenujacym poziomie, EOT]Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 17:11

Temat: False Friend Class pattern ;)

Ok, od razu napiszę, że dla mnie to EOT. Napisałem temat, możecie go przyjąć albo nie. Nie chce mi się dyskutować z osobami, które nie rozumieją kawałka prostego kodu, a rzucają się o definicję tak płynną, że aż paruje.

Co do cech i ich wrzucenia w kocioł, to traktuje to jako probe wymadrzenia sie na sile magicznymi traitsami, ktore tu pasuja jak swini siodlo.

Brak dostrzegania analogii miedzy friend class a tym co zaprezentowalem, uwazam za chory dowcip.

Odwolywanie sie do mechanizmow refleksji, ktora z zalozenia powinna penetrowac kod, w sytuacji, gdy sam kod bez penetracji staje otworem, jest dziwne.

Mnie tam tez private jakos specjalnie nie podniecaja - moze dlatego, ze umiem ich uzywac, i nie musze rzucac definicjami z liceum, zeby sie dowartosciowac.

Moge oczywiscie przyjmowac krytyke, ale bez dopowiadania, czego to ja nie sugeruje, na czym to ja sie nie znam, i jakich to bledow projektowych nie popelniam... na podstawie w zasadzie przykladowego kodu... do tego pokazujacego jedynie mechanizm obecny w PHP 5.4... smieszne.

"Not big deal, just a ciekawostka."

Milego dnia zycze :)

EOT.Łukasz K. edytował(a) ten post dnia 25.06.12 o godzinie 17:13

Temat: False Friend Class pattern ;)

generalnie łamanie enkapsulacji nie jest najlepszym pomysłem, takie silne sprzężanie klas nie jest dobrym pomysłem, używanie magii w php nie jest dobrym rozwiązaniem ;) oczywiście czasem są wyjątki i mimo wszystko trzeba zrobić coś wbrew dobrym zasadom programowania (czy ogólnym założeniom paradygmatu), ale rozwiązanie to nigdy nie zostanie wzorcem projektowym - to są sytuacje, których trzeba unikać, a nie popularne problemy dla których się tworzy uniwersalne rozwiązania

Temat: False Friend Class pattern ;)

Łukasz K.:

Sebastian Malaca:

Łukasz K.:

Zrozum, że pokazuję, że PHP5.4 umożliwia na łamanie zasad hermetyzacji poprzez wzorzec przeciwny do Friend Class z C++.

Po pierwsze - to nie jest wzorzec. Tutaj masz definicję

Jest :)

Skoro tak uważasz to go udokumentuj w sposób dla wzorców właściwy (Sebastian zwrócił Ci uwagę na braki z tym związane). Może w trakcie dokumentowania dostrzeżesz, że nie za bardzo można to jako wzorzec przedstawić. Nie każdy mechanizm jaki używamy/wymyślamy, a który daje się jakoś ogólniej zastosować (nie wnikam tutaj w analizę merytoryczną tego co napisałeś) staje się od razu wzorcem.