Другі два стовпи ООП
Як я вже згадував у першій публікації цієї серії, ви часто чуєте про три стовпи об’єктно-орієнтованого програмування. Ви також можете почути про чотири стовпи об’єктно-орієнтованого програмування.
І справа не в тому, що їх загалом сім чи щось подібне. Натомість мова йде більше про те, що люди вважають основою ООП: чи є три чи чотири основні концепції?
Ви можете припустити з попередньої статті (не кажучи вже про назву), я вважаю, що їх чотири.
І в цій публікації я збираюся розглянути останні два:
- спадок,
- і поліморфізм
Якщо ви займалися будь-яким типом об’єктно-орієнтованого програмування до того, як прочитали цю статтю, ви, ймовірно, чули принаймні про один із них.
Незважаючи на це, давайте розглянемо кожен з них докладніше.
Ще два стовпи ООП
Перш ніж перейти до кожного з них, я хочу переконатися, що ви охопили те, що ми розглянули досі.
Кілька слів про аналіз
Я не буду розголошувати цю тему, але вся причина, чому я зараз говорю про об’єктно-орієнтовані основи, полягає в тому, що ми переходимо до іншої фази цього матеріалу. Ми почали з етапу аналізу, який включав:
Тепер до розвитку
А тепер ми переходимо до етапу розробки. Дехто може назвати це фундаментальними (але я переконаний, що ви не можете зробити хорошу розробку без основ, тож це (.
Якщо ви не читали попередню публікацію, я рекомендую зробити це, перш ніж продовжити, оскільки вона охоплює поняття абстракції, інкапсуляції та їхнього відношення до WordPress.
3 Спадщина
Концепцію спадкування досить легко зрозуміти. Тобто один клас може успадкувати атрибути іншого класу. За мить я наведу кілька прикладів цього, але дозвольте мені надати робоче визначення для цілей цієї публікації:
Спадкування відноситься до ідеї, що один клас, хоча він і має власну реалізацію, буквально успадковує властивості, функції та загальну реалізацію від батьківського класу.
Приклад 1: Документ
Дуже простою мовою, скажімо, у вас є клас під назвою Document, а документ має заголовок і вміст. Потім є підклас документа, який має атрибути для дати та часу. Ми могли б назвати це PostDocument або PageDocument.
Тобто PageDocument успадковує властивості та атрибути Document, а також додає до нього власну реалізацію. Мати сенс?
Якщо ні, не хвилюйтеся. Спочатку не завжди «клацає», тому розглянемо інший приклад.
Приклад 2: Повідомлення
Скажімо, у нас є клас Message. Повідомлення зазвичай має дві властивості:
- 1 Відправник,
- 2 Одержувач.
Справедливо сказати, що існують різні типи повідомлень, чи не так? Тобто, можливо, ми маємо повідомлення електронної пошти або текстове повідомлення.
Повідомлення електронної пошти все ще має відправника та одержувача, але воно має набагато більше, чи не так? У ньому є такі речі, як:
- рядок теми,
- додатковий додаток,
- інший набір відправників, яким його надіслано,
- підтримка публічного або приватного копіювання інших до повідомлення,
- і набагато більше.
З іншого боку, текстове повідомлення не обов’язково матиме все вищезазначене. Припустімо, що ми говоримо про звичайне SMS-повідомлення (а не про форматоване текстове повідомлення в Hangouts, Telegram, iMessage чи будь-якому іншому).
Цей клас:
- бути прив’язаним до номера телефону,
- може включати групу інших одержувачів, усі з яких є загальнодоступними,
- оператор (тобто стільниковий оператор),
- максимальну кількість символів, які він може містити
- можливість розділити одне повідомлення на кілька повідомлень, якщо максимальна кількість символів перевищує певну кількість символів.
Але це все ще викликає питання щодо властивостей і методів (або, загальніше, реалізації, правда?)
Кілька слів про реалізацію
Коли справа доходить до об’єктно-орієнтованого програмування, у нас є те, що ми називаємо модифікаторами доступу. Можливо, ви десь читали їх, скажімо, як модифікатори видимості чи щось подібне.
Все одно.
Коротше кажучи, ці модифікатори можна визначити як:
Ключові слова, які контролюють доступ інших класів до наявної інформації.
На щастя, цю частину легко зрозуміти:
- приватні властивості та функції доступні лише для класу, у якому вони визначені. Це означає, що PostDocument не може використовувати нічого в документі, позначене як приватне. Для всіх цілей PostDocument навіть не знає про існування цієї інформації.
- захищені властивості та функції доступні класу, в якому вони визначені, і будь-якому класу, який є нащадком. Тобто будь-який клас, який успадковує дані від базового класу або батьківського класу, має до них доступ. Таким чином, на відміну від приватних деталей реалізації, PostDocument може отримати доступ до інформації з документа, якщо він позначений як захищений.
- загальнодоступні властивості та функції доступні кожному. Насправді це не має нічого спільного з успадкуванням, а більше з інкапсуляцією. Замість цього все залежить від того, до чого ми хочемо отримати доступ іншим об’єктам.
Отже, як відбувається впровадження? Це залежить від мови до мови, але PHP не підтримує те, що називається «множинним успадкуванням». Простіше кажучи, даний клас у PHP може успадковувати (або розширювати) лише один інший клас. Немає кількох класів (деякі мови підтримують це).
Коли ви розширюєте клас, підклас успадковує всі загальнодоступні та захищені методи від батьківського класу. Якщо клас не замінить ці методи, вони збережуть свою оригінальну функціональність.
У нашому прикладі ми не можемо представити інший клас, такий як WrittenDocument, який успадковує PageDocument, а також PostDocument. Це або одне, або інше. І варто зазначити, що якщо він успадковує від PostDocument, він також успадковує інформацію від Document, оскільки це підклас підкласу класу.
4 Поліморфізм
Тепер, коли ми маємо базове визначення успадкування, ми можемо говорити про поліморфізм. Хороша новина полягає в тому, що це велике, дивне слово для дуже простого поняття.
Погана новина полягає в тому, що ми не говорили про інтерфейси чи абстрактні класи. Вони з’являться, але вони вважаються частиною чотирьох стовпів, тому не хвилюйтеся про них прямо зараз.
Натомість подумайте про це так:
Поліморфізм дозволяє посилатися на клас одного типу, коли він може бути оголошений як інший тип.
Це все ще може заплутати, але пам’ятаєте наш, скажімо, приклад повідомлення вище? Ми можемо створити екземпляр класу SMSMessage, який розширює клас Message, а потім викликати для нього певні методи.
SMSMessage може мати метод, який має клас Message. І якщо клас був створений як екземпляр класу SMSMessage, тоді він викличе цей метод. Подібним чином, якщо він не має методу, але його батьківський клас, Message, має його, тоді він викличе цей метод.
Іноді найлегше зрозуміти це в коді, тому давайте зробимо це.
Спочатку давайте визначимо наш клас Message :
<?php
class Message
{
public function send()
{
echo "This message is sent from the Message class.n";
}
public function receive()
{
echo "This message was received from the Message class.n";
}
}
Тоді давайте визначимо наш клас SMSMessage. Зверніть увагу, що він не має функції receive(). Це буде важливо на мить:
<?php
class SMSMessage extends Message
{
public function send()
{
echo "This message is sent from the SMSMessage class.n";
}
}Тепер давайте створимо екземпляр нашого класу Message і викличемо кілька методів:
<?php
$message = new Message();
$message->send();
$message->receive();І давайте зробимо те саме , використовуючи клас SMSMessage:
<?php
$message = new SMSMessage();
$message->send();
$message->receive();Якщо вам потрібен весь сценарій, ви можете переглянути його тут, завантажити та виконати локально.
Спадкування, поліморфізм і WordPress
Ось висновок (і ми досліджуватимемо це докладніше, коли ми перейдемо до інтерфейсів та абстрактних класів): коли клас розширює інший клас і не має деталей реалізації, які має його батьківський клас, буде використана реалізація цього батька.
Інший спосіб думати про це — «опрацювати ланцюжок командування». Він почнеться з класу, найнижчого за створений нами. У нашому прикладі вище це SMSповідомлення. Якщо він не знайде його там, він переміститься до класу, який розширює. (І якщо він не знайде його там і цей клас розширює клас, він спробує там.)
Вся поліморфія полягає в наступному: ми створили екземпляр класу одного типу, SMSMessage, але він використовує реалізацію класу іншого типу (який він успадковує, так, але це все ж інше).
Написання курсів на WordPress
Нарешті, я хотів би залишити вас із цим: я згадував щось подібне в попередній публікації, але я хочу повторити це тут.
Незалежно від того, скільки з цих концепцій використовує ядро WordPress, це не має значення, тому що ми можемо написати високоякісний об’єктно-орієнтований код на WordPress, який взаємодіє з WordPress і добре працює з WordPress (та іншим кодом сторонніх розробників – не завжди)., але багато разів).
Що буде далі?
Далі ми розглянемо інтерфейси та абстракції.
Вони все ще є фундаментальними для об’єктно-орієнтованого програмування, але якщо ви зрозуміли попередні два дописи, ви налаштовані на серйозний досвід роботи з майбутніми концепціями.
А якщо ні, не хвилюйтеся! Ви завжди можете поговорити про це в коментарях або ми можемо поговорити про це додатково електронною поштою.