Объектно-ориентированное программирование в WordPress: анализ, часть 2
В первом посте этой серии я рассказал все о том, как я хотел заняться введением в объектно-ориентированное программирование в контексте WordPress.
Есть отличные ресурсы по объектно-ориентированному программированию, но они могут использовать надуманные примеры, или они могут двигаться слишком быстро для тех, кто только хочет начать.
Чтобы этого не произошло, я думаю, что разговор об ООП в WordPress привязывает нас к прочной основе, и использование практических примеров всегда будет лучше, чем использование общих примеров, которые трудно перевести в область, в которой мы работаем.
Для тех, кто еще не присоединился или еще не догнал, первый пост касается следующих тем:
- объектно-ориентированный анализ,
- Определение обязательных требований и желательного,
- И почему это сложно?
И вот где этот пост собирается подобрать.
Объектно-ориентированное программирование: дополнительный анализ
Я знаю: когда дело доходит до написания кода, первое, что мы хотим сделать, это сесть и начать писать код. Что может быть лучше, чем заставить что-то происходить на экране?
И когда вы делаете это для себя, это не так уж важно, но когда вы пишете код, это будет:
- поддерживается командой людей,
- продается,
- или для всего вышеперечисленного
Это имеет значение. Потому что хороший анализ может привести к хорошей организации, которая может привести к хорошей ремонтопригодности.
В противном случае вы собираете что-то вместе для отправки, и это не будет хорошо масштабироваться в будущих версиях. И это то, о чем мы будем подробно говорить на протяжении всей серии.
Но как можно подытожить хороший анализ тремя простыми шагами? Это не обязательно пуленепробиваемый ответ, но это то, что мы пытаемся делать всякий раз, когда работаем над проектами:
- Убедитесь, что код делает то, что хочет клиент,
- Применять передовые методы объектно-ориентированного программирования,
- Стремитесь к ремонтопригодной конструкции.
Все это звучит хорошо в теории, но, не углубляясь в каждую из них, как мы узнаем, правильно ли мы поступаем? Другими словами, именно здесь мы часто находим книги, ресурсы и другие утилиты, мешающие стать лучшим объектно-ориентированным программистом.
Это именно то, чего я хочу избежать, поэтому я собираюсь углубиться в каждый пункт.
1 Чего хочет клиент
Это может быть одним из самых сложных аспектов всего проекта, часто потому, что мы, как разработчики, говорим с заказчиком на другом языке.
Мало того, что они часто используют терминологию, которую мы бы не использовали, они часто думают, что то, что они хотят на экране, — это лучший способ сделать это. Это звучит очень снисходительно и неправильно пытаться исправить их, не так ли?
Я имею в виду, представьте, что вы пытаетесь сказать кому-то, что вы знаете, чего вы хотите, и они поправляют вас. Аккуратное обращение с этим — это то, что может принести большую реляционную справедливость, но требуется определенное количество времени, чтобы «раскопать» то, что они действительно хотят, а не то, что они говорят, что хотят.
И мы собираемся погрузиться в это больше в следующем посте.
2 объектно-ориентированных практики
Очевидно, это исходит из знания хороших методов объектно-ориентированного программирования, и это то, что я планирую осветить.
Многие люди будут говорить вещи, используя такие вещи, как:
- принципы SOLID,
- наследование,
- СУХОЙ код,
- внедрение зависимости,
- и так далее
Все они важны для соблюдения хороших объектно-ориентированных практик.
И, может быть, это непопулярно говорить, но я считаю, что пытаться использовать все вещи все время — не всегда хорошая идея. То есть вы определенно не хотите, чтобы код повторялся в вашей кодовой базе, но обязательно ли вам иметь наследование в вашей кодовой базе?
Нет.
Бывают случаи, когда принципы следует применять, а когда ими можно пренебречь. Но знание их, когда их лучше всего использовать и когда их использовать, является ключом к правильному применению этих практик.
3 Поддерживаемый дизайн
Проще говоря, применение шаблонов и принципов к вашему программному обеспечению при его написании значительно облегчит его использование и поддержку в будущем.
Но, опять же, это зависит от:
- полное понимание того, что хочет клиент,
- зная, какие практики существуют, когда их применять, а когда их избегать.
И чтобы сделать все вышеперечисленное, нам нужно рассмотреть каждую точку в ее контексте, прежде чем сделать шаг назад, чтобы взглянуть на более широкую картину.
Чего хочет клиент?
Очевидно, что есть много вопросов, которые нужно охватить, когда речь идет о трех вышеперечисленных пунктах. Но если вы хотите писать хорошее, поддерживаемое программное обеспечение в рамках экономики WordPress, важно понимать, как все это сочетается друг с другом.
Таким образом, вместо того, чтобы забегать вперед к написанию кода или к работе над проектом, следующее, что мы собираемся изучить, это то, как взять то, что хочет клиент, а затем расшифровать это в набор требований, которые позволят нам создать техническое задание.
Таким образом, у нас в конечном итоге будет рабочий документ о том, что хочет клиент и что мы собираемся построить, и мы все будем на одной волне.