Об’єктно-орієнтоване програмування в WordPress: аналіз, частина 2
У першому дописі цієї серії я розповів про те, як я хотів розглянути вступ до об’єктно-орієнтованого програмування в контексті WordPress.
Є кілька чудових ресурсів для об’єктно-орієнтованого програмування, але вони можуть використовувати надумані приклади, або вони можуть рухатися надто швидко для тих, хто тільки хоче почати.
Щоб цього не сталося, я думаю, що розмова про ООП у WordPress закріплює нас на міцному фундаменті, і використання практичних прикладів завжди буде кращим, ніж використання загальних прикладів, які важко перекласти в область, у якій ми працюємо.
Для тих, хто ще не приєднався або хто ще не наздогнав, перша публікація стосується таких тем:
- об’єктно-орієнтований аналіз,
- Визначення того, що потрібно мати, проти того, що потрібно мати,
- І чому це важко?
І ось де ця публікація збирається підняти.
Об’єктно-орієнтоване програмування: більше аналізу
Я знаю: коли справа доходить до написання коду, перше, що ми хочемо зробити, це сісти й почати писати код. Що може бути краще, ніж змусити щось статися на екрані?
І коли ви робите це для себе, це не така вже й велика справа, але коли ви пишете код, який буде:
- підтримується командою людей,
- на продаж,
- або для всього перерахованого вище
Це має значення. Тому що хороший аналіз може привести до хорошої організації, яка може призвести до хорошої ремонтопридатності.
Інакше ви збираєте щось разом, щоб відправити, і це не буде належним чином масштабуватись у майбутніх версіях. І це те, про що ми будемо детально говорити протягом серії.
Але який хороший спосіб підсумувати виконання якісного аналізу за три простих кроки? Це не обов’язково куленепробивна відповідь, але це те, що ми намагаємося робити щоразу, коли працюємо над проектами:
- Переконайтеся, що код виконує те, що хоче клієнт,
- Застосовувати хороші об’єктно-орієнтовані практики,
- Прагніть до зручного дизайну.
Все це звучить добре в теорії, але, не занурюючись у кожну з них глибше, як ми дізнаємося, чи ми робимо це правильно? Іншими словами, саме тут ми часто знаходимо книги, ресурси та інші утиліти, які ускладнюють стати кращим об’єктно-орієнтованим програмістом.
Це саме те, чого я хочу уникнути, тому я збираюся копати кожен пункт трохи глибше.
1 Що хоче клієнт
Часто це може бути одним із найскладніших аспектів усього проекту, оскільки ми, як розробники, розмовляємо іншою мовою, ніж клієнт.
Вони не тільки часто використовують термінологію, яку ми б не використовували, вони часто думають, що те, що вони хочуть на екрані, є найкращим способом це зробити. Через це звучить справді поблажливо й неправильно намагатися їх виправити, чи не так?
Я маю на увазі, уявіть собі, що ви намагаєтесь сказати комусь, кого знаєте, чого хочете, і вони вас виправляють. Обережне поводження з цим – це те, що може отримати велику реляційну справедливість, але потрібен певний час, щоб «розкопати» те, чого вони насправді хочуть, а не те, що вони кажуть, що хочуть.
І ми збираємося зануритися в це докладніше в наступній публікації.
2 Об’єктно-орієнтовані практики
Очевидно, це відбувається завдяки знанням хороших об’єктно-орієнтованих практик, і це те, що я планую охопити.
Багато людей скажуть речі, використовуючи такі речі, як:
- принципи SOLID,
- спадок,
- СУХИЙ код,
- ін’єкція залежності,
- і так далі
Усі вони важливі для дотримання належної об’єктно-орієнтованої практики.
І, можливо, це не популярне твердження, але я вважаю, що намагатися використовувати всі речі постійно – не завжди гарна ідея. Тобто ви точно не хочете, щоб код повторювався у вашій кодовій базі, але чи обов’язково у вашій кодовій базі є успадкування?
Ні.
Бувають моменти, коли принципи слід застосовувати, а коли ними можна ігнорувати. Але знати їх, коли їх найкраще використовувати та коли їх використовувати, є ключовим для правильного використання цих практик.
3 Ремонтопридатний дизайн
Простіше кажучи, застосування шаблонів і принципів до вашого програмного забезпечення під час його написання — це те, що значно полегшить його використання та підтримку в майбутньому.
Але, знову ж таки, це залежить від:
- повне розуміння того, чого хоче клієнт,
- знати, які практики існують, коли їх застосовувати, а коли уникати.
І щоб зробити все вищесказане, нам потрібно поглянути на кожну точку в її контексті, перш ніж зробити крок назад, щоб поглянути на ширшу картину.
Що хоче клієнт?
Очевидно, що є багато чого, щоб охопити, коли справа доходить до трьох вищевказаних пунктів. Але якщо ви хочете написати хороше, зручне програмне забезпечення в економіці WordPress, важливо зрозуміти, як усе це поєднується.
Тож замість того, щоб кидатися вперед до написання коду чи роботи над проектом, наступне, що ми розглянемо, це те, як взяти те, що хоче клієнт, а потім розшифрувати це в набір вимог, які дозволять нам створити технічне завдання.
Таким чином ми зрештою матимемо робочий документ про те, що хоче клієнт і що ми збираємося створити, і ми всі будемо на одній сторінці.