{"id":230610,"date":"2022-12-14T14:12:00","date_gmt":"2022-12-14T11:12:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=230610"},"modified":"2022-12-14T14:13:32","modified_gmt":"2022-12-14T11:13:32","slug":"wordpressi-vidinad-objektorienteeritud-programmeerimise-tuvastamine","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/et\/wordpressi-vidinad-objektorienteeritud-programmeerimise-tuvastamine\/","title":{"rendered":"WordPressi vidinad: objektorienteeritud programmeerimise tuvastamine"},"content":{"rendered":"\n

Kui te pole selle seeria esimest postitust lugenud, soovitan seda, sest me hakkame vidinate API<\/a><\/strong> abil WordPressi jaoks objektorienteeritud koodi kirjutama .<\/p>\n

Seerias on j\u00e4\u00e4dvustatud m\u00f5ned asjad:<\/p>\n

    \n
  1. n\u00e4idata teile vidina p\u00f5hilist luustikku ja seda, miks see on objektorienteeritud,<\/li>\n
  2. arutlege, mida peaksite suutma t\u00e4hele panna ja miks<\/li>\n
  3. v\u00e4rskendage esmalt Widget Boilerplate’i otse sellel saidil ja seej\u00e4rel l\u00fckake see GitHubisse,<\/li>\n
  4. looge vidin, kasutades API-d ja katlaplaati meie t\u00f6\u00f6 aluseks.<\/li>\n<\/ol>\n

    Kuid enne seda tahan veenduda, et k\u00f5ik, kes seda loevad, tunnevad objektorienteeritud programmeerimise p\u00f5hiprintsiipe ja neil on k\u00f5ik vajalik WordPressi objektorienteeritud lahenduse loomiseks.<\/p>\n

    Selleks soovitan j\u00e4rgmist:<\/p>\n

      \n
    1. Objektorienteeritud programmeerimise kaks sammast: 1. osa 2-st<\/a><\/strong><\/li>\n
    2. Objektorienteeritud programmeerimise kaks sammast: 2. osa 2-st<\/a><\/strong><\/li>\n
    3. Abstraktsed klassid, 1. osa \u2013 Abstraktne k\u00e4itumine<\/a><\/strong><\/li>\n
    4. Abstraktsed klassid, 2. osa \u2013 Abstraktsed klassid ja liidesed<\/a><\/strong><\/li>\n
    5. S\u00f5ltumatu WordPressi arendaja<\/a><\/strong><\/li>\n<\/ol>\n

      Kui olete kogu selle sisu lugenud, on suurep\u00e4rane. Olete selleks postituseks ja eelseisvateks postitusteks h\u00e4sti ette valmistatud. Kui ei, siis v\u00f5ib \u00fclej\u00e4\u00e4nud lugemises olla auke, kuid postituse sisu peaks olema piisavalt selge.<\/p>\n

      Mis leping t\u00e4pselt on?<\/h3>\n

      Asi on j\u00e4rgmine: eelmisel n\u00e4dalal<\/a><\/strong> jagasin natuke koodi ja teavet vidinate API<\/a><\/strong> kohta. Ma k\u00e4sitlen seda selles postituses veidi rohkem, enne kui j\u00f5uame kodeerimise intensiivsema osa juurde kahel p\u00f5hjusel:<\/p>\n

        \n
      1. Ma tahan, et k\u00f5ik, kes seda loevad, oleksid objektorienteeritud koodi kirjutamise osas samal lehel (v\u00e4hemalt selles kontekstis),<\/li>\n
      2. M\u00f5istan, et inimesed on erineva taustaga, ja tahan enne j\u00e4tkamist veenduda, et oleme k\u00f5ik v\u00f5imalikult \u00fchel lehel.<\/li>\n<\/ol>\n

        Kui teil on kogemusi objektorienteeritud koodi kirjutamisel, eriti edasij\u00f5udnutele, v\u00f5ib see tunduda teile lihtsam; muidu loodan, et see varustab teid k\u00f5ige vajalikuga objektorienteeritud tavade tuvastamiseks mitte ainult selle API kohta, vaid ka teiste koodi lugemisel.<\/p>\n

        Kuidas tuvastada objektorienteeritud programmeerimist<\/h2>\n

        V\u00f5ib-olla on loomulik esimene k\u00fcsimus, miks me peame suutma objektorienteeritud programmeerimist tuvastada, lugeda v\u00f5i m\u00f5ista enne selle kirjutamist?<\/p>\n

        S\u00f5na halva koodi kohta<\/h3>\n

        L\u00fchike vastus sellele on j\u00e4rgmine:<\/p>\n

        Sa ei pea seda tegema, aga mulle on sellest abi. Kui oskate objektorienteeritud programmeerimist lugeda, saate selle paradigmana pakutavate eeliste \u00e4rakasutamiseks edumaa, kuna kavatsete tugineda teiste projektide strateegiatele ja t\u00f6\u00f6le.<\/p>\n

        See ei t\u00e4henda, et me ei loeks halba koodi, kuid teeme k\u00f5ik endast oleneva, et tuvastada halb kood, tuvastada probleemsed piirkonnad ja seej\u00e4rel teha k\u00f5ik, et v\u00e4ltida selle kaasamist oma t\u00f6\u00f6sse.<\/p>\n

        Praegu aga vaatame vidinate API<\/a><\/strong> -t, et n\u00e4ha, mida saame objektorienteeritud programmeerimise tuvastamiseks teha.<\/p>\n

        Tagasi objektorienteeritud programmeerimise juurde<\/h3>\n

        Eelmises postituses t\u00f5in v\u00e4lja kaks asja, mis n\u00e4itavad, et API on objektorienteeritud (v\u00e4hemalt teatud m\u00e4\u00e4ral):<\/p>\n

          \n
        1. laiendab<\/strong> m\u00e4rks\u00f5na kasutamine ,<\/li>\n
        2. funktsioone, mida peame rakendama.<\/li>\n<\/ol>\n

          P\u00f5hjus, miks ma tahan seda teemat uuesti l\u00e4bi vaadata, on see, et see tuvastab kaks p\u00f5hiasja, mis on osa objektorienteeritud p\u00f5hiprintsiipidest: p\u00e4rimine<\/a><\/strong> ja funktsioonide rakendamine (mis on sageli osa abstraktsetest klassidest<\/a><\/strong> ).<\/p>\n

          M\u00e4rkus enne \u00fclaltoodu vaatamist:<\/p>\n

          Kui vaatate klassi WP_Widget allikat,<\/a><\/strong> m\u00e4rkate, et seal pole abstraktseid meetodeid. Kuid m\u00f5ned funktsioonid, mida me peame rakendama ja mida ma selles postituses hiljem mainin, on abstraktsete meetodite peamised kandidaadid. Ja ma arutan ka, miks.<\/p>\n

          Eraldame \u00fclaltoodud teemad kaheks eraldi jaotiseks: P\u00e4rimine ja Abstraktsioonid.<\/p>\n

          P\u00e4rand<\/h3>\n

          Eelmises postituses<\/a><\/strong> k\u00e4sitlesin p\u00e4rimise suhtelist s\u00fcgavust, nii et ma ei hakka seda siin k\u00e4sitlema. Ma \u00fctlen paar s\u00f5na, kuid ma olen palju rohkem huvitatud abstraktsiooni \u00fcle arutlemisest, mida ma teen hetke p\u00e4rast.<\/p>\n

          Enne kui l\u00e4hete sellesse liiga kaugele, vaadake palun j\u00e4rgmist koodi:<\/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
          Kuid k\u00f5igepealt saame aru, et iga klass, mis rakendab vidinate API-d, peab kasutama p\u00e4rimist lihtsalt laiendatud<\/strong> m\u00e4rks\u00f5na t\u00f5ttu.<\/p>\n
          See t\u00e4hendab, et teatud funktsionaalsuse tase me p\u00e4rime (v\u00f5i saame tasuta) ja funktsionaalsuse taseme, mille peame ise rakendama.<\/p>\n
          PHP juhendist<\/a><\/strong> :<\/p>\n
          \n
          N\u00e4iteks klassi laiendamisel p\u00e4rib alamklass \u00fclemklassilt k\u00f5ik avalikud ja kaitstud meetodid. Kui klass neid meetodeid ei alista, s\u00e4ilitavad need oma algsed funktsioonid.<\/p>\n<\/blockquote>\n
          Kui p\u00e4randate funktsionaalsuse klassist, v\u00f5ite avastada, et on oluline kutsuda rangelt vanemkonstruktor (meie funktsioonis __construct<\/strong> ).<\/p>\n
          Kuid see t\u00f5statab minu arvates PHP p\u00e4rimisega seotud \u00fche k\u00f5ige olulisema probleemi (ja kogu p\u00f5hjuse, miks ma tahtsin selle jaotise kaasata): kas peame emakonstruktorit selges\u00f5naliselt kutsuma?<\/p>\n
          Samuti vastavalt juhendile:<\/a><\/strong><\/p>\n
          \n
          Vanemkonstruktoreid ei kutsuta kaudselt v\u00e4lja, kui alamklass m\u00e4\u00e4ratleb konstruktori. \u00dclemkonstruktori k\u00e4ivitamiseks on vaja alamkonstruktoris k\u00f5net vanematele::__construct()<\/strong>. Kui laps konstruktorit ei defineeri, v\u00f5ib see p\u00e4rida p\u00f5hiklassist nagu tavaline klassimeetod (kui seda ei deklareeritud privaatseks).<\/p>\n<\/blockquote>\n
          Kuid me saame seda lihtsustada. V\u00f5ib-olla on seda lihtsam meeles pidada:<\/p>\n
            \n
          1. Kui meie klass kasutab p\u00e4rimist, kuid ei defineeri konstruktorit, kutsutakse v\u00e4lja emakonstruktor.<\/li>\n
          2. Kui meie klass kasutab p\u00e4rimist, kuid m\u00e4\u00e4ratleb konstruktori, tuleb emakonstruktsiooni selges\u00f5naliselt kutsuda.<\/li>\n<\/ol>\n
            V\u00f5i ehk veelgi lihtsamalt:<\/p>\n