Об’єктно-орієнтоване програмування в WordPress: аналіз, частина 1
Коли я вперше збирався запропонувати членство на цьому сайті, я знав, що перше, за що хочу взятися, це вступ до об’єктно-орієнтованого програмування.
Це те, що здається цікавим для більшості людей, які працюють у WordPress, але є проблема, яка або відвертає багатьох людей, або створює погані результати:
Об’єктно-орієнтоване програмування може швидко ускладнюватися. І це демотивує.
Я маю на увазі ось що: припустімо, ви розробник WordPress, який починає досліджувати об’єктно-орієнтоване програмування. Він починається з розмови про класи, конструктори та функції, і все здається добре.
Але потім це швидко потрапляє в:
- приватні та захищені методи,
- спадок,
- поліморфізм,
- шаблони дизайну,
- ін’єкція залежності,
- сховища,
- і так далі.
Це сніжки, чи не так? І це зовсім не так, як це повинно бути, але важко знайти правильний вступ, за винятком кількох доступних ресурсів.
З огляду на все це (і слугуючи фоном для того, куди я збираюся), я хотів створити серію вмісту для тих, хто:
- щиро цікавляться об’єктно-орієнтованим програмуванням,
- не знаю, з чого почати,
- хочуть розвивати свої навички,
- хочу почати з нуля, не переходячи занадто швидко до більш складного матеріалу.
І це те, що я починаю сьогодні, і в першому серйозному плані для членів. З усім цим сказаним, давайте почнемо.
Зокрема, давайте почнемо говорити про об’єктно-орієнтоване програмування, аналіз, дизайн і чому вона повинна почати з цього.
Об’єктно-орієнтоване програмування: аналіз
Що стосується написання коду, наразі є три популярні способи:
Щоразу, коли ми працюємо з кодом WordPress і читаємо його, ви читатимете комбінацію процедурного та об’єктно-орієнтованого коду.
На це є деякі причини, але це виходить за межі нашого обговорення.
Це пояснюється тим, що WordPress створено з використанням обох і тому, що певні аспекти розробки WordPress можна написати за допомогою процедурного коду, як-от плагіни та теми, а інші вимагають об’єктно-орієнтованої розробки, як-от віджети.
Аналіз і дизайн
Дуже часто перше, що ми хочемо зробити, як розробники (початківці чи ні), це негайно почати писати код. Я також розумію. Це весело. У нас є ідея, ми хочемо втілити її в життя, ми хочемо почати її використовувати та ми хочемо показати її іншим людям.
Але проблема з цим полягає в тому, що ми часто переходимо безпосередньо до написання коду, щоб спробувати змусити проект робити те, що ми хочемо.
Якщо це простий (і я маю на увазі дуже простий) проект, то це не така вже й велика проблема. Чесно кажучи, я це зробив (і GitHub тому підтвердження). Але коли справа доходить до роботи, яку ми виконуємо в Pressware ; це зовсім інша історія.
Коли справа доходить до таких проектів, ми хочемо зробити трохи аналізу та дизайну, перш ніж писати код.
Це викликає питання, що таке об’єктно-орієнтований аналіз і дизайн?
Аналіз
Коротше кажучи, подумайте про це так:
Аналіз — це процес взяття ідеї, яка є у клієнта чи вас, і пошуку того, що дійсно потрібно створити.
Це може допомогти вам визначити, що є корисним для програми, а що непотрібно для першої версії програми. Мені подобається називати їх «необхідними» і «приємними».
Гарне емпіричне правило таке:
- must-have — це те, що є ядром додатка і має входити в першу ітерацію проекту,
- приємно мати – це те, що ми можемо врешті-решт вбудувати в нього
Зрештою, це допомагає нам працювати над надійною першою версією для клієнта. Можливо, один приклад для WordPress:
- Чи потрібен був API плагіна для першої версії WordPress чи просто потрібна була можливість для людей писати дописи та публікувати їх у мережі?
Якщо ви створюєте платформу для блогів, чи потрібно її розширювати з першої версії? Це не більше ніж приклад, але ви зрозуміли.
Що робить аналіз таким важким?
Я думаю, що це часто пов’язано з персонами.
Наприклад, ми, програмісти, вважаємо, що проект завжди повинен робити те, що хоче замовник. Правда в тому, що це не завжди так.
Я маю на увазі, що зрештою це може бути, але перша версія проекту не обов’язково має бути такою.
Крім того, один із принципів об’єктно-орієнтованого програмування полягає в тому, що ми не пишемо багато повторюваного коду. Але це може бути дуже важко зробити, якщо не було зроблено належний аналіз.
Нарешті, ті, хто має більший досвід, скажуть, що хороше програмне забезпечення використовуватиме перевірені та вірні принципи – будь то шаблони проектування чи ні – але його можна легко змінити з часом. Це, у певному сенсі, росте органічно.
Отже, що нам робити?
У наступній статті я розповім про три речі, які ми можемо зробити, як розробники, щоб переконатися, що програмне забезпечення, яке ми створюємо для себе чи інших, веде нас у правильному напрямку.
Я не скажу, що це срібна куля, тому що я не вірю, що воно існує, але я скажу, що це досить сильний підхід, яким я знайшов, щоб його використовували інші, а також я сам, і він веде в досить хорошому напрямку з точки зору об’єктно-орієнтованого аналізу.
Це зрештою приведе нас до проектування. Але ми ще не там.