Объектно-ориентированное программирование в WordPress: анализ, часть 1
Когда я впервые решил предложить членство на этом сайте, я знал, что первым делом я хочу заняться введением в объектно-ориентированное программирование.
Это то, что кажется интересным большинству людей, работающих в WordPress, но есть проблема, которая либо отталкивает многих людей, либо приводит к плохим результатам:
Объектно-ориентированное программирование может быстро усложниться. И это демотивирует.
Вот что я имею в виду: скажем, вы разработчик WordPress, который начинает исследовать объектно-ориентированное программирование. Он начинается с разговоров о классах, конструкторах и функциях, и все выглядит хорошо.
Но потом быстро проникает в:
- частные и защищенные методы,
- наследование,
- полиморфизм,
- шаблоны проектирования,
- внедрение зависимости,
- репозитории,
- и так далее.
Это снежки, не так ли? И это совсем не так, как должно быть, но трудно найти подходящее введение, если не считать нескольких доступных ресурсов.
С учетом всего сказанного (и послужившего фоном для того, куда я направляюсь), я хотел создать серию контента для тех, кто:
- искренне интересуетесь объектно-ориентированным программированием,
- не уверены, с чего начать,
- хотят повысить свои навыки,
- хотите начать с нуля, не переходя слишком быстро к более сложному материалу.
И это то, что я начинаю сегодня и в первом серьезном запланированном членстве. С учетом всего сказанного, давайте начнем.
Конкретно давайте для начала поговорим об объектно-ориентированном программировании, анализе, дизайне и почему ей стоит начать именно с этого.
Объектно-ориентированное программирование: анализ
Когда дело доходит до написания кода, в настоящее время есть три популярных способа сделать это:
Всякий раз, когда мы работаем с кодом WordPress и читаем его, вы будете читать комбинацию процедурного кода и объектно-ориентированного кода.
Есть несколько причин, по которым это так, но это выходит за рамки нашего обсуждения.
Это связано с тем, что WordPress построен с использованием и того, и другого, а некоторые аспекты разработки WordPress могут быть написаны с помощью процедурного кода, например, плагины и темы, а другие требуют объектно-ориентированной разработки, например, виджеты.
Анализ и дизайн
Очень часто первое, что мы хотим сделать, как разработчики (начинающие или нет), — это немедленно приступить к написанию кода. Я тоже понимаю. Это весело. У нас есть идея, мы хотим воплотить ее в жизнь, мы хотим начать ее использовать, и мы хотим показать ее другим людям.
Однако при этом возникает проблема: мы часто сразу переходим к написанию кода, пытаясь заставить проект делать то, что нам нужно.
Если это простой (и я имею в виду действительно простой) проект, то это не такая уж большая проблема. Честно говоря, я так и сделал (и GitHub тому доказательство). Но когда дело доходит до работы, которую мы делаем в Pressware ; это другая история.
Когда дело доходит до таких проектов, мы хотим провести небольшой анализ и проектирование, прежде чем писать код.
В связи с чем возникает вопрос, что такое объектно-ориентированный анализ и проектирование?
Анализ
Короче говоря, подумайте об этом так:
Анализ — это процесс принятия идеи, которая есть у клиента или у вас, и выяснения того, что действительно нужно построить.
Это может помочь вам определить, что нужно приложению, а что не нужно для первой версии приложения. Мне нравится обозначать их как «обязательные» и «желательные».
Хорошее практическое правило таково:
- must-have — это то, что является ядром приложения и должно войти в первую итерацию проекта,
- приятно иметь вещи, которые мы можем в конечном итоге встроить в него
В конечном счете, это помогает нам работать над созданием сильной первой версии для клиента. Возможно, один пример для WordPress:
- Нужно ли было первой версии WordPress иметь плагин API или просто нужно было, чтобы люди могли писать сообщения и публиковать их в Интернете?
Если вы создаете платформу для ведения блога, должна ли она быть расширяемой с первой версии? Это не более чем пример, но вы поняли идею.
Что делает анализ таким трудным?
Я думаю, что это часто связано с персонажами.
Например, мы, как программисты, считаем, что проект всегда должен делать то, что хочет заказчик. Правда в том, что это не всегда так.
Я имею в виду, что в конечном итоге это может быть, но первая версия проекта не обязательно должна быть такой.
Более того, один из принципов объектно-ориентированного программирования заключается в том, что мы не пишем много повторяющегося кода. Но это может быть очень трудно сделать, если не был проведен должный анализ.
Наконец, более опытные скажут, что хорошее программное обеспечение будет использовать проверенные и верные принципы — будь то шаблоны проектирования или нет, — но со временем в него можно будет легко вносить поправки. Это, в некотором смысле, растет органически.
Итак, что нам делать?
В следующей статье я расскажу о трех вещах, которые мы, как разработчики, можем сделать, чтобы убедиться, что программное обеспечение, которое мы создаем для себя или других, ведет нас в правильном направлении.
Я не скажу, что это серебряная пуля, потому что я не верю, что она существует, но я скажу, что это довольно сильный подход, который, как я нашел, используют другие и я сам, и что он ведет в довольно хорошем направлении. с точки зрения объектно-ориентированного анализа.
Это в конечном итоге приведет нас к дизайну. Но мы еще не там.