{"id":230482,"date":"2022-12-14T13:56:00","date_gmt":"2022-12-14T10:56:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230482"},"modified":"2022-12-14T13:58:26","modified_gmt":"2022-12-14T10:58:26","slug":"widzety-wordpress-wykrywanie-programowania-obiektowego","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/pl\/widzety-wordpress-wykrywanie-programowania-obiektowego\/","title":{"rendered":"Wid\u017cety WordPress: wykrywanie programowania obiektowego"},"content":{"rendered":"\n

Je\u015bli nie przeczyta\u0142e\u015b pierwszego posta z tej serii, polecam, poniewa\u017c zaczynamy pisa\u0107 kod obiektowy dla WordPressa za pomoc\u0105 Widgets API.<\/a><\/strong><\/p>\n

Seria ma uchwyci\u0107 kilka rzeczy:<\/p>\n

    \n
  1. pokaza\u0107 podstawowy szkielet wid\u017cetu i dlaczego jest zorientowany obiektowo,<\/li>\n
  2. przedyskutuj, jakie rzeczy powiniene\u015b by\u0107 w stanie zauwa\u017cy\u0107 i dlaczego<\/li>\n
  3. najpierw zaktualizuj Widget Boilerplate bezpo\u015brednio na tej stronie, a nast\u0119pnie wy\u015blij go do GitHub,<\/li>\n
  4. zbuduj widget wykorzystuj\u0105c API z boilerplate jako fundament naszej pracy.<\/li>\n<\/ol>\n

    Ale zanim to zrobi\u0119, chc\u0119 si\u0119 upewni\u0107, \u017ce wszyscy, kt\u00f3rzy to czytaj\u0105, s\u0105 zorientowani w podstawowych zasadach programowania obiektowego i maj\u0105 wszystko, co jest potrzebne do zbudowania rozwi\u0105zania zorientowanego obiektowo dla WordPressa.<\/p>\n

    W tym celu polecam:<\/p>\n

      \n
    1. Dwa filary programowania obiektowego: cz\u0119\u015b\u0107 1 z 2<\/a><\/strong><\/li>\n
    2. Dwa filary programowania obiektowego: cz\u0119\u015b\u0107 2 z 2<\/a><\/strong><\/li>\n
    3. Klasy abstrakcyjne, cz\u0119\u015b\u0107 1 \u2013 zachowanie abstrakcji<\/a><\/strong><\/li>\n
    4. Klasy abstrakcyjne, cz\u0119\u015b\u0107 2 \u2013 Klasy abstrakcyjne i interfejsy<\/a><\/strong><\/li>\n
    5. Niezale\u017cny programista WordPress<\/a><\/strong><\/li>\n<\/ol>\n

      Je\u015bli przeczyta\u0142e\u015b wszystkie te tre\u015bci, \u015bwietnie. B\u0119dziesz dobrze przygotowany do tego posta i kolejnych post\u00f3w. Je\u015bli nie, mog\u0105 by\u0107 pewne dziury w reszcie tego, co zamierzasz przeczyta\u0107, ale istota postu powinna by\u0107 wystarczaj\u0105co jasna.<\/p>\n

      O co dok\u0142adnie chodzi?<\/h3>\n

      Oto rzecz: W zesz\u0142ym tygodniu<\/a><\/strong> udost\u0119pni\u0142em fragment kodu wraz z kilkoma informacjami na temat API Widgets<\/a><\/strong>. Zamierzam wr\u00f3ci\u0107 do tego nieco wi\u0119cej w tym po\u015bcie, zanim przejdziemy do bardziej intensywnej cz\u0119\u015bci kodowania z dw\u00f3ch powod\u00f3w:<\/p>\n

        \n
      1. Chc\u0119, aby wszyscy czytaj\u0105cy to byli na tej samej stronie, co dotyczy pisania kodu obiektowego (przynajmniej w tym kontek\u015bcie),<\/li>\n
      2. Zdaj\u0119 sobie spraw\u0119, \u017ce ludzie pochodz\u0105 z r\u00f3\u017cnych \u015brodowisk i chc\u0119 si\u0119 upewni\u0107, \u017ce wszyscy jeste\u015bmy na tej samej stronie w jak najwi\u0119kszym stopniu, zanim przejdziemy dalej.<\/li>\n<\/ol>\n

        Je\u015bli masz do\u015bwiadczenie w pisaniu kodu zorientowanego obiektowo, zw\u0142aszcza na zaawansowanym poziomie, mo\u017ce ci si\u0119 to wydawa\u0107 prostsze; w przeciwnym razie mam nadziej\u0119, \u017ce uzbroi ci\u0119 to we wszystko, czego potrzebujesz, aby wykry\u0107 praktyki zorientowane obiektowo nie tylko dotycz\u0105ce tego interfejsu API, ale tak\u017ce podczas czytania kodu innych os\u00f3b.<\/p>\n

        Jak wykry\u0107 programowanie zorientowane obiektowo?<\/h2>\n

        By\u0107 mo\u017ce naturalnym pierwszym pytaniem jest, dlaczego musimy by\u0107 w stanie wykry\u0107, przeczyta\u0107 lub zrozumie\u0107 programowanie obiektowe przed jego napisaniem?<\/p>\n

        S\u0142owo o z\u0142ym kodzie<\/h3>\n

        Kr\u00f3tka odpowied\u017a na to jest taka:<\/p>\n

        Nie musisz, ale to jest pomocne. Je\u015bli potrafisz czyta\u0107 programowanie zorientowane obiektowo, b\u0119dziesz mia\u0142 przewag\u0119 w korzystaniu z tego, co oferuje jako paradygmat, poniewa\u017c b\u0119dziesz bazowa\u0107 na strategiach i pracy wykonanej przez innych w innych projektach.<\/p>\n

        Nie oznacza to, \u017ce nie b\u0119dziemy czyta\u0107 z\u0142ego kodu, ale zrobimy, co w naszej mocy, aby zidentyfikowa\u0107 z\u0142y kod, zidentyfikowa\u0107 problematyczne obszary, a nast\u0119pnie zrobimy wszystko, co w naszej mocy, aby unikn\u0105\u0107 w\u0142\u0105czenia go do naszej pracy.<\/p>\n

        Na razie jednak przyjrzyjmy si\u0119 interfejsowi API wid\u017cet\u00f3w<\/a><\/strong>, aby zobaczy\u0107, co mo\u017cemy zrobi\u0107, aby wykry\u0107 programowanie obiektowe.<\/p>\n

        Powr\u00f3t do programowania obiektowego<\/h3>\n

        W poprzednim po\u015bcie nakre\u015bli\u0142em dwie rzeczy, kt\u00f3re wskazuj\u0105, \u017ce API jest zorientowane obiektowo (przynajmniej w pewnym stopniu):<\/p>\n

          \n
        1. u\u017cycie s\u0142owa kluczowego extends ,<\/strong><\/li>\n
        2. funkcje, kt\u00f3re musimy wdro\u017cy\u0107.<\/li>\n<\/ol>\n

          Powodem, dla kt\u00f3rego chc\u0119 wr\u00f3ci\u0107 do tego tematu, jest to, \u017ce identyfikuje on dwie kluczowe rzeczy, kt\u00f3re s\u0105 cz\u0119\u015bci\u0105 podstawowych zasad zorientowanych obiektowo: Dziedziczenie<\/a><\/strong> i implementacja funkcji (kt\u00f3ra cz\u0119sto jest cz\u0119\u015bci\u0105 klas abstrakcyjnych<\/a><\/strong> ).<\/p>\n

          Uwaga zanim spojrzymy na powy\u017csze:<\/p>\n

          Kiedy spojrzysz na \u017ar\u00f3d\u0142o klasy WP_Widget<\/a><\/strong>, zauwa\u017cysz, \u017ce nie ma metod abstrakcyjnych. Ale niekt\u00f3re z funkcji, kt\u00f3re musimy zaimplementowa\u0107, o kt\u00f3rych wspomn\u0119 p\u00f3\u017aniej w tym po\u015bcie, s\u0105 g\u0142\u00f3wnymi kandydatami do metod abstrakcyjnych. I om\u00f3wi\u0119 te\u017c dlaczego.<\/p>\n

          Podzielmy powy\u017csze tematy na dwie oddzielne sekcje: Dziedziczenie i Abstrakcje.<\/p>\n

          Dziedzictwo<\/h3>\n

          W poprzednim po\u015bcie<\/a><\/strong> om\u00f3wi\u0142em dziedziczenie to wzgl\u0119dna g\u0142\u0119boko\u015b\u0107, wi\u0119c nie b\u0119d\u0119 tutaj omawia\u0142 tego tematu. Zaproponuj\u0119 kilka s\u0142\u00f3w, ale o wiele bardziej interesuje mnie om\u00f3wienie abstrakcji, kt\u00f3r\u0105 za chwil\u0119 zrobi\u0119.<\/p>\n

          Zanim jednak zag\u0142\u0119bisz si\u0119 w to zbyt daleko, zapoznaj si\u0119 z nast\u0119puj\u0105cym kodem:<\/a><\/strong><\/p>\n

          <?php\nclass AcmeWidget extends WP_Widget \n{ \n    public function __construct() \n    {\n    }\n\n    public function widget($args, $instance) \n    {\n    }\n\n    public function form($instance)\n    {\n    }\n\n    public function update($newInstance, $oldInstance)\n    {\n    }\n}<\/code><\/pre>\n
          Ale najpierw mo\u017cemy rozpozna\u0107, \u017ce ka\u017cda klasa implementuj\u0105ca API Widgets musi u\u017cywa\u0107 dziedziczenia po prostu ze wzgl\u0119du na s\u0142owo kluczowe extends<\/strong>.<\/p>\n
          Oznacza to, \u017ce istnieje poziom funkcjonalno\u015bci, kt\u00f3ry zamierzamy odziedziczy\u0107 (lub otrzyma\u0107 za darmo) i jest poziom funkcjonalno\u015bci, kt\u00f3ry musimy wdro\u017cy\u0107 samodzielnie.<\/p>\n
          Z podr\u0119cznika PHP<\/a><\/strong> :<\/p>\n
          \n
          Na przyk\u0142ad, gdy rozszerzasz klas\u0119, podklasa dziedziczy wszystkie publiczne i chronione metody z klasy nadrz\u0119dnej. O ile klasa nie zast\u0105pi tych metod, zachowaj\u0105 one swoj\u0105 pierwotn\u0105 funkcjonalno\u015b\u0107.<\/p>\n<\/blockquote>\n
          Kiedy jednak dziedziczysz funkcjonalno\u015b\u0107 z klasy, mo\u017ce si\u0119 okaza\u0107, \u017ce wa\u017cne jest \u015bcis\u0142e wywo\u0142anie konstruktora rodzica (w naszej funkcji __construct<\/strong> ).<\/p>\n
          Ale to rodzi to, co uwa\u017cam za jeden z najwa\u017cniejszych problem\u00f3w z dziedziczeniem w PHP (i ca\u0142y pow\u00f3d, dla kt\u00f3rego chcia\u0142em zamie\u015bci\u0107 t\u0119 sekcj\u0119): Czy musimy jawnie wywo\u0142ywa\u0107 konstruktor rodzica?<\/p>\n
          R\u00f3wnie\u017c zgodnie z instrukcj\u0105:<\/a><\/strong><\/p>\n
          \n
          Konstruktory nadrz\u0119dne nie s\u0105 wywo\u0142ywane niejawnie, je\u015bli klasa podrz\u0119dna definiuje konstruktor. Aby uruchomi\u0107 konstruktor nadrz\u0119dny, wymagane jest wywo\u0142anie metody parent::__construct()<\/strong> w konstruktorze potomnym. Je\u015bli dziecko nie definiuje konstruktora, to mo\u017ce by\u0107 dziedziczone z klasy nadrz\u0119dnej, tak jak zwyk\u0142a metoda klasy (je\u015bli nie zosta\u0142a zadeklarowana jako prywatna).<\/p>\n<\/blockquote>\n
          Ale mo\u017cemy to upro\u015bci\u0107. By\u0107 mo\u017ce \u0142atwiej to zapami\u0119ta\u0107:<\/p>\n
            \n
          1. Je\u015bli nasza klasa u\u017cywa dziedziczenia, ale nie definiuje konstruktora, wywo\u0142ywany jest konstruktor nadrz\u0119dny.<\/li>\n
          2. Je\u015bli nasza klasa u\u017cywa dziedziczenia, ale definiuje konstruktor, nale\u017cy jawnie wywo\u0142a\u0107 konstrukcj\u0119 nadrz\u0119dn\u0105.<\/li>\n<\/ol>\n
            A mo\u017ce jeszcze pro\u015bciej:<\/p>\n