Перші два стовпи ООП
Коли справа доходить до розмови про об’єктно-орієнтоване програмування (або ООП), ви, ймовірно, почуєте про «Три стовпи об’єктно-орієнтованого програмування» або «Чотири стовпи об’єктно-орієнтованого програмування».
Залежно від вашого походження, можливо, ви вже чули про них, знаєте, що вони собою представляють, і вам не потрібно занурюватися в це надто. Але якщо ви ні, я вважаю, що їх розуміння є основою об’єктно-орієнтованого програмування.
Ми розглянули весь етап аналізу об’єктно-орієнтованого програмування:
З огляду на це, давайте почнемо обговорення дизайну та впровадження. Зрештою, це те, до чого багато хто хоче перейти, чи не так?
Перш ніж писати будь-який код, я хотів би написати дві публікації про чотири моменти об’єктно-орієнтованого програмування (оскільки я один із тих, хто підтримує ідею, що їх чотири).
Два стовпи ООП
Знову ж таки, розуміння цього є ключовим для розуміння основи об’єктно-орієнтованого програмування. Без них буде важко орієнтуватися в решті того, що буде обговорюватися в наступних публікаціях.
Тому поговоримо про кожного з них. Ми розглянемо перші два в цій публікації та останні два в наступній публікації.
1 Абстракція
Взагалі кажучи, це ключ до написання об’єктно-орієнтованого коду. Під цим я маю на увазі все, що міститься в класі. Ми абстрагуємо ідею чогось у клас. У багатьох книгах ми побачимо такі речі, як Тварини чи Машини, представлені як класи.
Теоретично це працює, але на практиці ми не програмуємо ні тварин, ні автомобілі (хоча, мабуть, на цьому етапі історії ви можете сперечатися, що ми програмуємо, але я відволікаюся, бо ви розумієте, що я маю на увазі).
Замість цього ми будемо абстрагувати ідеї в їхніх класах. І тут є ключова ідея:
Клас повинен представляти іменник.
Тобто ви не повинні мати клас, який представляє щось на кшталт «Running». Натомість у вас може бути щось, що виконується, і, отже, виконання буде методом. І це загальна розбивка того, як працює абстракція:
- Те, що має бути представлено, це клас,
- Те, що ця річ робить, це її методи,
- І те, як ви описуєте річ, зазвичай можна зробити це через її атрибути або властивості.
Це не означає, що у нас немає функцій або методів, які змінюють його властивості, але три пункти вище є хорошими емпіричними правилами. Отже, коли ви розробляєте клас, ви можете запитати такі речі, як:
- Я щось пишу?
- Я пишу щось робити?
- Або я пишу те, що щось описує?
Тому що, якщо ви пишете дію, вона, швидше за все, виконується чимось (тому що речі виконують дії – вони роблять щось). І якщо ви щось описуєте, то це, швидше за все, стосується чогось (коли востаннє ви нічого не описували?)
Мати сенс?
2 Інкапсуляція
Отже, якщо ми пишемо класи – хороші класи – то ми повинні писати їх таким чином, щоб правильно інкапсулювати їхні дані. А інкапсуляція — це насправді просто «велике» слово, яке стосується ідеї управління його обов’язками (або відстеження його даних).
Отже, наприклад, якби ми писали клас для представлення публікації WordPress, тоді ми б мали клас під назвою Post із такими властивостями, як publish, update, delete, postData, publishDate, lastUpdatedData, deletedDate тощо.
Потім у нас будуть функції, спеціально розроблені для виконання дій над екземпляром класу Post.
У цьому випадку ми можемо…
- публікувати,
- оновлення,
- або видалити пост
Ці методи, ймовірно, будуть представлені таким чином, щоб інші класи могли ними скористатися. Крім того, ці методи, ймовірно, також використовуватимуть інші властивості, такі як publishDate або deletedDate.
І тут починає грати концепція видимості. В об’єктно-орієнтованому програмуванні інкапсуляція стосується не лише ідеї інформації, яку містить клас, але й того, як вона надає дані.
Це робиться трьома способами, кожен з яких визначено нижче:
- загальнодоступні властивості та функції доступні для будь-кого; однак загальнодоступні властивості зазвичай не розкриваються. Натомість ми гарантуємо, що їх можна змінювати загальнодоступним методом.
- захищені властивості та функції доступні для використання класом і будь-яким іншим класом, який успадковує інформацію від нього. Більш детально про це йтиметься в наступній публікації.
- приватні властивості та функції призначені виключно для використання в контексті певного класу. Це можуть бути властивості, що використовуються для відстеження внутрішніх статусів, або методи, які використовуються як допоміжні функції для загальнодоступних функцій для завершення їх роботи.
Продовжуючи цю серію, ми побачимо роль, яку кожен із них відіграє під час написання зрозумілих, простих у дотриманні, добре архітектурних класів.
Однак наразі важливо розуміти, що ці слова, public, protected і private, називаються модифікаторами видимості, оскільки вони, як ви можете переконатися, керують видимістю методу або властивості щодо його класу та класи, які успадковують його та взаємодіють з ним.
Говорячи про спадковість, я розповім про це в наступній частині цієї серії.
Абстракція, інкапсуляція та WordPress
Погані новини: заняття в WordPress
Ось у чому річ: у WordPress ми часто бачимо дуже, дуже великі класи. Це погано. Насправді це антишаблони, які називаються бог-класами (ідея полягає в тому, що у вас є єдиний клас, який знає все).
І коли у вас є божественний клас, це здається зручним, тому що ви можете розмістити всі функції в одному місці. але
- це важко перевірити,
- воно не масштабується,
- він погано працює з іншим класом (не кажучи вже про класи чи сторонні бібліотеки),
- він погано адаптується до змін.
Зрештою, коли ви це робите, ви не використовуєте об’єктно-орієнтоване програмування. Ви берете функції та додаєте їх до класу. І ми хочемо від цього піти.
Хороші новини: написання курсів на WordPress
Однак виникає запитання: навіщо намагатися вивчати об’єктно-орієнтоване програмування за допомогою WordPress, якщо це не надійний приклад об’єктно-орієнтованого програмування?
Це тому, що ви все ще можете писати хороший об’єктно-орієнтований код на WordPress. Він все ще може добре взаємодіяти з WordPress, і він все ще може добре працювати з багатьма іншими аспектами WordPress.
Я знаю, що це звучить неінтуїтивно, але коли ми глибше зануримося в написання об’єктно-орієнтованого коду на WordPress, це має стати зрозумілим.