PHP: Go home static, you’re drunk

Kilka powodów dlaczego static powinien zniknąć, bądź przynajmniej stracić na popularności.

Zmienne statyczne

Na tapetę idzie taki przykład:

Mamy klasę A ze statyczną zmienną $var. Owa zmienna jest wspólna między wszystkimi instancjami, tj. każdy obiekt klasy A może dowolnie modyfikować jej wartość. Mamy więc obiekty, które nie posiadają pełnej kontroli nad swoim stanem – enakpsulacja właśnie dostała w twarz.

Drugi przykład:

Krótki ale jakże wymowny – teraz nie tylko obiekty klasy A mogą modyfikować stan $var ale i obiekty klasy B. Enkapsulacja dostała ponownie w twarz i cichutko chlipie w kącie.

Ile frameworków potraficie wymienić z podobnymi klasami? A jak zmienimy nazwę zmiennej na $db a klasy na Database?

Dalej będzie tylko gorzej.

Robiąc $var publiczną, dajemy możliwość zmiany stanu każdemu w dowolnym momencie, we wszystkich instancjach jednocześnie. I nawet nie trzeba się odwoływać do żadnej instancji.

Metody statyczne

Metody statyczne są dostępne globalnie, w każdym miejscu, klasie, funkcji. Wszędzie możemy napisać:

Jeśli taki zapis pojawi się w klasie, to wprowadzamy ukrytą zależność. Oczywiście nikt o niej nie wie, nawet autor – bo już zapomniał. Powiązaliśmy klasy między sobą, nie poprzez interfejs czy prototyp ale przez nazwę, zmieniliśmy Object Oriented Programming w Class Oriented Programming.

Kolejny przykład:

Metoda query musi być poprzedzona wywołaniem connect. Gdzieś na początku skryptu, czy może każdorazowo sprawdzamy $con? Chyba to drugie, bo przecież $con może być modyfikowany przez inne instancje Database. W sumie, jeżeli są inne instancje, to za cholerę nie wiadomo z czym właściwie jesteśmy połączeni.

Rozwiązaniem jest singleton. Nie będę pisał jak się go implementuje – zakładam, że czytelnik jakąś tam wiedzę posiada.

Proste wywołanie, a w zamian każdorazowo gdy chcemy wywołać query, getInstance sprawdzi, czy już nawiązaliśmy połączenie, czy dopiero trzeba to zrobić. W efekcie mamy jedną klasę globalną zapewniającą wszędzie, w każdej warstwie abstrakcji połączenie do bazy danych. Singleton rozwiązał też problem z modyfikowaniem zmiennych statycznych przez inne instancje – nie ma innych instancji.

Problem w tym, że gdzieś trzeba podawać dane potrzebne do nawiązania połączenia. Zaszyć je w deklaracji klasy. Podawać je każdorazowo jako parametry getInstance? Może gdzieś na początku programu pilnować się i wywoływać connect? Z innego obiektu statycznego? Czy wspominałem o tym że drugie połączenie do bazy wymaga osobnej klasy, nawet jeśli różni się tylko danymi dostępowymi?

Dlaczego w ogóle static?

Dla wygody. Krótkotrwałej i kończącej się czkawką.

Metody statyczne często są też używane przez ludzi przyzwyczajonych do programowania proceduralnego. Stają się tzw. helperami, podpięte pod jakąś klasę-kontener grupujący, świadczą funkcjonalność, która nie zawsze powinna być dostępna poza konkretną warstwą.

Mniej doświadczeni programiści, by uniknąć trudu przepychania instancji przez kolejne warstwy abstrakcji, omamieni łatwością implementacji tworzą klasy pełne statycznych metod. Później, łatwość wywołań dodatkowo zachęca do korzystania gdzie się chce, niezależnie czy klasa ma rację bytu na tym etapie czy nie.

Przykład z dokumentacji Laravela:

W imię wygody, autorzy ukryli całkiem niezły kontener zależności pod postacią statycznej metody. Tak! Route jest tylko fasadą, za którą stoi wywołanie komponentu z kontenera.

Z dokumentacji Fuela

Zmienne i metody statyczne. Ktoś kto nie będzie potrafił przekazać potrzebnych instancji między warstwami, odwoła się bezpośrednio – bo może. Zaś ci, którzy potrafią – nie potrzebują takiej wygody.

W starszych frameworkach jak Kohana, Codeigniter czy stary Zend, static jest znacznie więcej. Można im jednak wybaczyć, powstawały w czasach gdy PHP nie oferował obecnych narzędzi.

Dziś, static może pójść w kąt i być używany wtedy, gdy jest konieczny, a nie kiedy jego jedyną zaletą jest wygoda.

(fot. CC by CalEvans)

Programista, web developer i kontestator. Od wielu lat freelancer - kontraktowiec. Miłośnik dobrego kodu, zabawy z nim, samokształcenia i rosyjskiej myśli wojskowej. Czasem człowiek - koło ratunkowe i wulgarna sowa.

  • Łukasz Kużyński

    Nie posuwałbym się do stwiedzenia, że „static” powinno zniknąć. Jest parę dobrych przykładów, gdzie statyczne metody są bardzo przydatne.

    Metody „fabryki”
    https://github.com/symfony/HttpFoundation/blob/master/Request.php#L253

    Asercje
    https://github.com/beberlei/assert/blob/master/lib/Assert/Assertion.php#L513

    Słowniki
    https://gist.github.com/wookieb/6375474

    Memoizery
    https://gist.github.com/wookieb/6375534

    Oraz wiele innych

    W skrócie – metody statycznych jak najbardziej można używać pod jednym warunkiem – nie przechowują stanu aplikacji, który chcielibyśmy potem zmienić/przetestować z poziomu kodu.

    • Potfur

      Wszystko co wymieniłeś nie musi być statyczne, a skoro nie musi – to lepiej żeby nie było.

      • Łukasz Kużyński

        Dlaczego metoda „fabryka” miałaby nie być statyczna? Asercje są bardzo użyteczne, wstrzykiwanie ich byłoby bardzo uciążliwe i nie przynosiło żadnych korzyści.

        • Potfur

          A dlaczego miała by być?
          Kontenery zależności nie są statyczne, a świetnie się spisują w roli fabryk.

          Korzyść była by taka, że nie wiążę się z klasą.

          • Łukasz Kużyński

            Hmm ale podane przykłady nie mają nic wspólnego z DIC.

            Request::createFromGlobal tworzy obiekt instancji Request wykonując dodatkową logikę w której nie ma żadnych zależności „serwisowych”. Taką logikę trudno byłoby zrealizować na poziomie DIC.
            Poza tym jak zrealizowałbyś powyższą metodę z poziomu DIC-a? Tworząc dodatkową klasę generującą Request?

            Asercje – nadal się upieram, że nie powinno się ich wstrzykiwać.

            W artykule ująłeś tylko tą złą stronę metody/właściwości statycznychzasłaniając się DIC-iem. Jednakże nie wokół DIC cały PHP się kręci 🙂 Po prostu wypadałoby zawrzeć jeszcze przykłady kiedy static ma rację bycia 🙂

            Co do „powiązania z klasą” to fakt, masz racje, że w przypadku fabryki dość często można na stałe powiązać metodę z klasą jednakże w 99,99 % przypadków właśnie taki będzie najbardziej pożądany efekt użycia tej metody. W przypadku konieczności rozszerzenia wspomnianego obiektu Request, można by było pokusić się o mała modyfikację „createFromGlobal” jednakże żaden z 0,01% programistów tego nie zrobił 🙂

          • Potfur

            Mają. Sporo kontenerów pozwala zarejestrować komponent jako funkcję anonimową.

            Podaj proszę rzeczowe argumenty na rzecz statyczności asercji z wyjątkiem „wygodniej” i „prościej”, gdyż są subiektywne. Prościej – tak, wygodniej – IMHO tylko przez chwilę.

            Unikam wiązania klasy z inną klasą przez nazwę np. wywołanie statycznej metody fabryki. Później zmiana klasy fabryki będzie polegać na „zmień wszystkie wystąpienia X na Y” 😀

            Podał bym, jednakże gdy pisałem, nie byłem w stanie wymyślić żadnego przykładu gdzie static byłby konieczny.
            Tam gdzie był by wygodny … cóż takich jest pełno 🙂

          • Łukasz Kużyński

            „Sporo kontenerów pozwala zarejestrować komponent jako funkcję anonimową.” A to już wymaga konieczności budowania kontenera z poziomu kodu PHP co jest niemiłosiernie niewygodne, albo możliwości definiowania funkcji w xml, yml co jest śmieszne 🙂

            https://gist.github.com/wookieb/6376333
            DRY

            „Później zmiana klasy fabryki będzie polegać na „zmień wszystkie wystąpienia X na Y” :D” Przecież od tego jest DIC, gdzie zrobisz to za jednym zamachem :).

            „Podał bym, jednakże gdy pisałem, nie byłem w stanie wymyślić żadnego przykładu gdzie static byłby konieczny.” Na upartego… to np http://www.php.net/manual/en/language.oop5.overloading.php#object.callstatic 😀

            Nie rozważamy problemu z poziomu „konieczny” lecz „bardziej optymalny”. Router, który jest obiektem również nie jest zawsze konieczny. Dla bardzo prostych zastosowań nie jest nawet potrzebny.

          • Potfur

            Prosty kontener: https://gist.github.com/Potfur/5476498

            Fabryka statyczna w kontenerze? Podoba mi się ta wizja 🙂

            Tak, „konieczny”, zapraszam do ponownego przeczytania tekstu i zastanowienia się nad niepotrzebnymi powiązaniami / tight couplingiem.

            Nadużywanie, sztywne trzymanie się DRY i później za jedną malutką funkcjonalnością ciągnie się tuzin statycznych klas, z których wykorzystuje się 1 czy 2 metody. Bo komuś nie chciało się zamknąć pudełka.

            PS. Napisz proszę tekst, odnieś się do mojego i wykaż że nie mam racji, że static ma sens, gdzie warto go używać.
            Z chęcią dowiem się gdzie popełniam błędy 🙂

          • Łukasz Kużyński

            Ale jaki to ma związek z tym co powiedziałem, że wolałbym unikać definiowania kontenera w php?

            „Fabryka statyczna w kontenerze? Podoba mi się ta wizja :)” Od tego jest DIC aby wspomniany przez Ciebie „refactoring” nie był żadnym problemem.

            Więc bezsensowne powtarzanie się (w tym przypadku użycia jaki omawiamy) jest lepsze tylko dlatego aby nie użyć statica? I nie 1 czy 2 metody a cały świetny zestaw (odsyłam do https://github.com/beberlei/assert).

            Nie. Sama treść artykułu jest ok. Cały czas chcę Ci przekazać to, że brakuje w nim przykładów dobrego użycia „static” a w komentarzach je wymieniłem.

          • Potfur

            A ja ci usilnie powtarzam, że dla mnie nie są „dobre”.
            I na tym poprzestańmy 🙂

      • Piotrek Koszuliński

        Co to za argument, że skoro nie musi to lepiej żeby nie było? ;/

        • Potfur

          Zastanów się jakie są konsekwencje: $A->a() , $A::a() i A::a()
          Póki sami nie przeanalizujesz każdego z przypadków każda moja odpowiedź będzie brzmieć jak hejt.

  • sbl

    Czekam na kolejny wpis, w którym zaprezentujesz rozwiązanie zastępujące „static”.
    Swoją drogą czytając ten wpis mam wrażenie, że Twój kod żyje własnym życiem skoro piszesz, że każda klasa może nadpisać statyczną zmienną itd. Jeśli sam jej nie nadpiszesz gdzie indziej to sama raczej się nie nadpisze prawda? 🙂
    Wiadomo, za dużo statica to nie zdrowo, ale jak @ukaszkuyski:disqus napisał, w fabrykach, aseracjach jest przydatna 🙂

  • spawnm

    Z skrajności w skrajność? Wydaje mi się że kiedyś sam mi przyznałeś że static w przypadku factory jest słuszny, zmiana zdania? ;] @Łukasz Kużyński dobrze pisze, polać mu.

    • Potfur

      Tak. Przemyślałem porządnie fabryki i nie potrzebują bycia statycznymi.

      • Łukasz Kużyński

        Warto dopisać Twoje przemyślenia w artykule 🙂

      • Sebastian Malaca

        Nie potrzebują, ale nie ma też żadnego powodu żeby nie były 🙂
        IMO, wszystkie klasy bezstanowe nie mają powodu posiadać nic statycznego, ale też nic nie stoi na przeszkodzie (tzn. nie ma w tym nic złego), że owo static gdzieś tam jest.
        Że zależności?
        A czym się różni:
        $a = new A();
        $a->execute();
        od:
        A::execute();
        ?
        Zależność taka sama.
        Że np. w Javie jest mniej static’ów? Bo tam można napisać:
        new A()->execute();

        • Potfur

          W PHPie już też można 🙂

          • Sebastian Malaca

            też prawda 😛

  • Kowal

    Nie zawsze nadmierna ilość warstw abstrakcji jest dobra przy średnich i małych aplikacjach według mnie do statica nie można się przyczepić. Argumenty, że nie wiadomo gdzie co jest w danym staticu do tego podając jako przykład bazę danych według mnie jest skrajnością albo świadczy o tym, że programista nie panuje nad własnym kodem. W czasach kiedy trzeba godzić wydajność/szybkość tworzenia kodu ze stabilnością static ma rację bytu ograniczając ilość warstw abtrakcji przez które jak to ładnie ująłeś trzeba się przepychać.

    • Kowal

      P.S.
      Ten artykuł to doskonały przykład jak często teoretycy sa oderwani od praktyki… uczestniczyłem kiedys w takim projekcie (akurat dot.net’owym) gdzie było tyle warstw abstrakcji, że zamiast ułatwiać powstawanie aplikacji to nie dość że zwalniało to produkcję to jeszcze kulała na wydajności….

    • Grzegorz

      Ależ dokładnie. Weź biedny programisto i przebij się przez 4 warstwy abstrakcji, jeśli można na skróty. Już dawno wyleczyłem się z pisania Pięknego Kodu dla samej jego natury. Najważniejszy jest kod funkcjonalny i dopasowany do obecnych i najbliżcych potrzeb aplikacji, a nie rozdmuchany i wydumany. Zakładając że nie pracujemy przy kupie++, to zawsze jest coś takiego jak reafktoring i brakujące poziomy abstrakcji, czy elastyczność możemy dodać poprzez odpowiednie przebudowanie kodu. Nigdy, powtarzam nigdy nie jesteśmy w stanie napisać aplikacji, która rozwiązywała by wszystkie problemy i zapewniał wsparcie dla wszystkich, nawet tych jeszcze niepoznanych procesów biznesowych. Tyle jeśli chodzi o praktykę.

      • piotrooo

        Najważniejszy jest kod utrzymywalny i testowalny – często zdarza się że właśnie taki kod ma dużą „ziarnistość” inaczej mówiąc jest rozdmuchany.

      • Sebastian Malaca

        Przy małych aplikacjach, które są pewnego rodzaju ‚one-shotami’ tzn. piszesz-oddajesz-zapominasz, to rzeczywiście można sobie na wiele pozwolić (a raczej wiele pominąć), ale jeżeli aplikacja ma działać x lat, to ten czas ‚zmarnowany’ na dobry kod, to czas, który zyskasz wcześniej czy później.

        Im więcej osób pracuje nad aplikacją, im dłuższy ma być jej czas życie, tym istotniejsze są te wszystkie „głupie i niepotrzebne” praktyki, techniki i wzorce opisywane przez „teoretyków bez praktyki”.

        To, że nigdy nie napiszemy aplikacji, która rozwiąże każdy problem, to prawda, ale możemy napisać taką, której rozwój w wielu kierunkach (potencjalnie wymaganych przez biznes) nie będzie drogą przez mękę 🙂

    • Sebastian Malaca

      „Argumenty, że nie wiadomo gdzie co jest w danym staticu […] świadczy o tym, że programista nie panuje nad własnym kodem”
      Albo, że aplikacja jest duża i pracuje nad nią sporo osób.

      • Kowal

        To popełniają kolejny błąd… nie dokumentują…

        • Sebastian Malaca

          Jestem zwolennikiem dokumentacji (sam kiedyś o tym pisałem http://sebastian-malaca.blogspot.com/2013/07/wiecej-nie-znaczy-wolniej-cz-8.html ). Jednak nie przesadzajmy:)

          Nie wierzę, że dokumentacja byłaby w tym przypadku rozwiązaniem. Wydaje mi się wręcz, że kod, który wymaga sięgania do dokumentacji za każdym razem, gdy go dotykamy nie jest kodem dobrym.

          Static nie jest zły sam w sobie, ale wielokrotnie jest źle wykorzystywany.

          Robienie czegoś i usprawiedliwianie się, że „dorzucę to do dokumentacji”, „napiszę komentarz” itp. nie jest dobrym pomysłem, bo wymaga nieustannej aktualizacji tych dokumentów. Poza tym, programista nie zawsze może tam trafić.
          Co innego z bibliotekami (czytamy dokumentację i tutoriale), a co innego z kodem, nad którym pracujemy.

          Nie żyjemy w idealnym świecie i nie wierzę, że każdy programista zanim dotknie jakiegokolwiek kawałka kodu bierze się za dokumentację. Z drugiej strony nie sądzę nawet, że byłby to idealny świat, bo z doświadczenia wiem, że dobrze napisany kod nie wymaga niczego więcej poza przeczytaniem tylko jego 🙂

          • Marek

            Fajne wnioski 🙂

  • Jacek Jackowiak

    Wiele osób piszących w Javie ograniczyło zmienne statyczne (wraz z modyfikatorem final) w zasadzie tylko do definiowana stałych. Co do zmiennych to faktycznie nie widzę większego sensu. Metody od biedy jeszcze czasami się przydadzą, ale ich wystąpienia w sumie widywane są dość rzadko (faktorki, asercje – ale to też trochę inaczej wygląda bo istnieje coś takiego jak statyczne importy, czyli importy coś pewnie można by zastąpić phpowymi traitami).

  • Filip Górny

    Nigdy nie widzialem zeby ktos ta serio podwazal podstawy OOP.
    Co zamiast staticow, np w prostych helperach (typu klasa z lista funkcji formatujacych stringi), zmienne globalne?
    Fabryki jako singleton?

    Pamietaj tez o late static bindings.

    • Potfur

      Bardzo często helper jest po prostu błędem architektonicznym.
      Tight coupling w imię enkapsulacji? Nie dziękuję.

      Nie, wygodniej było by: $arr = ($arr = [])->merge([], [], []);

      🙂

      • Filip Górny

        Na pewno byłoby dużo wygodniej, jednak w phpie array nie jest obiektem, a ArrayObject jakoś nie przyjął się tak jak DateTime.
        Mamy więc masę funkcji globalnych przez które php jest często wyśmiewane.

        Zgadzam się z Tobą że porządna architektura powinna unikać staticów, ale nie popadajmy w skrajność. Nie sugerujmy żeby usuwać static z języka, jest to rzecz która istnieje w wielu innych technologiach i jej użycie znalazło zastosowanie, a celem (moim zdaniem) takiego rozwiązania było unikanie potrzeby tworzenia instancji, oraz umożliwienie re-użycia kodu w podprogramach (task cronowy). Prosty przykład: kod do zapisu logów. Chcesz zapisać coś do loga w DTO, nie masz statica, jest godzina 15:55 a jutro demo – smuteczek 🙂

        Ostatnio zauważam modę na DI i ‚service pattern’ w światku php’owym (również js). Moim zdaniem przyczyniło się do tego głównie SF2. W ZF 1 mieliśmy pełno staticów, np do pobrania konfiguracji czy też przetłumaczenia stringa (albo słynne Zend_Registry).

        Statyczne klasy to kod, który powtarza się w wielu warstwach i biblioteka w której ten kod się znajduje powinna być odizolowana od całej logiki biznesowej, ba – od całej aplikacji. Kod taki nie powinien wymagać tworzenia instancji (bo po co?), musi być dostępny globalnie.

        Dyskutować można długo i pewnie dojdziemy do (co widzę po moim poście) powtarzania tego samego w kółko. Czasem static jest lepszy, czasem nie. Wszystko zależy od aplikacji, od wymogów, od jej rozmiaru.

        Twój post ma wiele ciekawych argumentów ale nie popadajmy w skrajność. Moglibyśmy napisać podobnego o metodach magicznych, o sensie istnienia interfaców podyskutować z pythonowcami itp itd.

        • Potfur

          Powtórzę wniosek tekstu (ostatnie dwie linie) – static tylko wtedy gdy jest konieczny.
          Wygoda statica – dla mnie nie jest argumentem, mści się wcześniej czy później.

          PS. Nie mam loggera na staticach i – to cię zaskoczy – nie mam smuteczku. 🙂

    • Jacek Jackowiak

      W javie tych staticów też raczej coraz mniej. Ze staticami jest sporo problemów. Ciężko to mockować do testów, a zysk jest niewielki, bo możesz sobie po prostu wstrzyknąć klasę z metodami instancyjnymi.

      Przykład z PI jest nietrafiony uważam, bo w tym przypadku jest to stała (w Javie powinna mieć dodatkowo atrybut final). Stałe owszem powinny być statyczne, ale zmienne to już raczej rzadki case.

      • Filip Górny

        PI to stała, ale np. sin() już nie.

        Czy taka klasa wymaga instancji? Nigdy.

        Jest potrzebna wszędzie, jej wstrzykiwanie czy inicjowanie w każdej klasie byłoby udręką.

        Zmienne statyczne praktycznie zawsze powinny być użyte jako stałe. W PHP robi to lekki bałagan bo przecież mamy constanty.

        • Jacek Jackowiak

          Możesz z powodzeniem wstrzykiwać singleton aplikacyjny z niestatycznymi metodami. Zaleta jest taka, że taką klasę można bez problemu zamockować w innych testach, statycznych metod nie zmockujesz.

          • Filip Górny

            Zgadzam się, ale to nie odpowiada na mój komentarz 🙂

            Nie chcę bronić staticów, lecz w niektórych sytuacjach na prawdę mają zastosowanie. Zdaje sobie jednak sprawę że takie sytuacje wynikają ze źle rozplanowanej architektury na samym początku lub też (z czym się spotykam w codziennej pracy) z powodu „przestarzałego” frameworka.

          • Jacek Jackowiak

            Właśnie odpowiada 😉 Potrzebna jest instancja po to, by móc pracować na niestatycznej, testowalnej metodzie. Nie mogę przetestować swojej klasy niezależnie od Math. Moje testy zależą od tego, czy Math.sin() zwróci prawidłowy wynik czy nie. A to kłóci się z podstawową zasadą testów jednostkowych.

          • Marek

            To że w javie jest statycznie to nie jest dobry argument. Java też ma listę swoich grzechów 🙂

  • letMeSee()

    Wpis trochę przykry. Ja mam wrażenie że autor zna trochę więcej niż przeciętny programista teorii i snuje jakieś chore wnioski. Zamiast pokazać jakieś nowe zastosowania statica autor podpiera się teorią. Szkoda bo potem sam pisze że:
    „Statica nie zastąpię.
    Zmienia się wtedy architektura… a tego nie da się wszędzie zrobić.”.
    Co już moim zdaniem zupełnie podsumowuje tekst. Na prawdę szkoda, bo zaglądam na ten portal w nadziei że nauczę się czegoś ciekawego, a niestety zamiast tekstów doświadczonych programistów PHP, ciekawych rozwiązań i dobrych kawałków kodu widzę takie właśnie ‚pseudoartykuły’. Kurde wchodzę na portal od czasu jego powstania i liczyłem na dobre teksty PHPowców :/ poprawcie się!

    • thejw23

      A o czym byś chciał przeczytać? Jakich ciekawych rozwiązaniach? Jakim dobrym kodzie? Rzuć kilka pomysłów, może uda się coś z tego zrealizować.

      • letMeSee()

        Dla mnie liczy się to co praktyczne. W internecie szukam ciekawych rozwiązań, dobrych i przemyślanych implementacji wzorców typowo pod PHP, nowych technologii – tego co dzięki nim mogę dostać a co stracić, tips & tricks, tutoriali, itp.

        Czasem coś tutaj znajdę, ale ostatnio tylko jakieś ślepe wywody o teorii. W takich tematach jak ten wolałbym może nie pochwałę statica, ale pokazanie jego zalet, bo nie chodzi o to żeby uczyć się o wadach języka, tylko o to żeby z tego języka brać jak najwięcej jakiby on nie był.

        • Marek

          Chodzi o to że static nie ma zalet. A jeśli myślisz że ma zalety to się po prostu mylisz. Są pewne konstrukcje języka których nie powinno się stosować i static zalicza się do nich.
          Ktoś w ogóle pamięta goto ? To jest znamienny przykład. Smutne jest to że zdaje się że ta instrukcja została dodana do tego język co bardzo źle świadczy o kierunku w którym się rozwija ten język. (http://www.php.net/manual/en/control-structures.goto.php)

          Znacznie lepiej skorzystać z DI (http://pl.wikipedia.org/wiki/Wstrzykiwanie_zale%C5%BCno%C5%9Bci). Kod jest łatwiejszy w konserwacji i można go łatwiej przetestować.

          • letMeSee()

            Nie znam lepszej implementacji singletona niz static:
            http://www.youtube.com/watch?v=UPfdb5y2SOI
            Poza tym mozna to zobaczyc w wielu frameworkach, no ale coz – static bez sensu.

            Oczywiscie jest wiele konstukcji jezyka ktore sa bez sensu obecnie bo np PROGRAMUJEMY W PHP GLOWNIE W OOP. GOTO jak powiniennes dorze wiedziec to byla konstrukcja wymyslona jeszcze za czasow programowania proceduralnego zeby (jak sie wtedy wydawalo) programowanie bylo mniej proceduralne i (sic!) lepsze. To ze zaimplementowali ja w phpie jako jezyku wieloparadygmatowym. To ze piszesz tylko w phpie obiektowo nie znaczy ze mozesz powiedziec ze to jest slabe. Nie potrzebne ci to bylo i nie korzystales to po co psioczysz?

            Static jest bo OOP w phpie opiera sie na klasach a nie na np.prototypach, wiec mozna to zaimplementowac bo KLASY w programowaniu obiektowym to nie COP tylko nadal OOP.

            Nie meczmy sie nad teoria, bo jest zawykle (w informatyce, w szczegolnosci) rozumiana wielorako i rozne jezyki roznie to implementuja. Jak nie chcesz korzystac ze statica to nie korzystaj. Ciekawe jak w phpie zbudowalbys obecne frameworki czy funkcjonalnosci z ktorym sam korzystasz.

            Zeby nie bylo. Twierdze ze oczywiscie da sie to wszytsko ladnie obudowac wzorcami i poobcinac jezyk do minimum, ale… po co?

          • Marek

            php jest kiepskie. Obecnie to chyba najgorszy język programowania w jakim można pisać. Ciekawe czy ktoś wymyślił już konkurs na najgorszy język programowanie 😉

            Z ciekawości czy znasz jakiś inny język poza php ?

          • letMeSee()

            Tak znam: Ruby, JS, Java.
            Zawodowo pracuje w PHP i nie twierdze ze jest najgorszy. Nie chodzi o jezyki tylko o funkcjonalnosci, a php dla webu (do tylko tam sie nadaje) jest ok. Jedyne co mnie boli to to, ze wszystko co znalazlo zastosowanie w m.in. Javie (frameworki, ORM) probuje sie przeniesc na duzo wolniejszego php co w konsekwencji powoduje spadek szybkosci. I te aplikacje na tych kobylach sa na prawde wolne.

            Oceniam PHP jako bardzo dobry jezyk programowania.

          • Marek

            php było dobre kiedyś. Teraz można śmiało powiedzieć że pisanie w php uwstecznia.

          • nrm

            ee tam, FUD. PHP jest tak dobre jak nigdy w swojej historii. 😉

          • Potfur

            Jakich funkcjonalności w obecnych frameworkach nie da się napisać bez użycia statica?

          • letMeSee()

            Gdzie ja napisalem ze pewnych funkcjonalnosci NIE DA sie napisac bez uzycia statica?
            Przeczytaj jeszcze raz koncowke mojego postu 😉

            Od razu wytlumacze ostatnie 2 slowa „po co” bo zaraz znowu ktos sie przyczepi. Po co to obudowywac jak ta sama funkcjonalnosc mamy juz gotowa (static)?

          • Potfur

            Nigdzie nie napisałeś, tak tylko się zastanawiasz jak by zbudować obecne frameworki bez staticów.

            Napisz mi proszę jeszcze, cóż to za funkcjonalność jest obudowywana a jaką daje static?

          • letMeSee()

            Po prostu w rozmowie z przedmowca myslalem ze chodzi mu o factory.

      • Kamil

        źal, chyba nie taka jest idea portalu.

        i nie wierze co czytam, go home static. Zgadzam się z LetMeSee w pocałości.

  • Paweł Nowak

    W tekście masz wyraz: enakpsulacja właśnie dostała w twarz.
    a potem jest:
    Enkapsulacja dostała ponownie w twarz i cichutko chlipie

    Tego pierwszego nie da się wymówić. Które jest poprawne?

    • rpicheta

      A czy to pierwsze wydaje Ci sie polskim slowem? 😉
      Odnosnie artykulu, mam pytanie. Skoro nie trafnie jest uzywac metod statycznych to jak napisac np. klase Helpera w Symfony2 np. do operacji na tablicy danych? Skoro bede z niej korzystal w wielu miejscach i nie potrzebuje instacji klasy do tego? Jakas wskazowka? 🙂 Pozdrawiam

      • Potfur

        Moja pewnie „niepopularna” opinia jest taka, że jeżeli potrzebujesz helpera to robisz coś źle.
        Wskazówka: trait, dziedziczenie, wstrzyknięcie?

        • RPicheta

          Traity niestety odpadają, projekt niestety nie jest w php 5.4 napisany, wstrzykniecie: masz na mysli serwisy? (mowa o sf2)
          Za wszelkie podpowiedzi serdeczne bug zapłać 🙂

Send this to a friend

webmastah.weekly
Cotygodniowa porcja linków ze świata WEBDEV BEZ spamu, TYLKO samo mięcho!
Zobacz poprzednie wydania. Dołącz do 2 tysięcy webdeveloperów!
HTML5, CSS3, JS (React, Angular, Ember, Vue), PHP, SQL