Первые два столпа ООП
Когда речь заходит об объектно-ориентированном программировании (или ООП), вы, вероятно, услышите о «Трех столпах объектно-ориентированного программирования» или «Четырех столпах объектно-ориентированного программирования».
В зависимости от вашего опыта вы, возможно, уже слышали о них, знаете, что они из себя представляют, и вам не нужно слишком углубляться в это. Но если вы этого не сделали, я считаю, что их понимание является основой объектно-ориентированного программирования.
Мы рассмотрели всю фазу анализа объектно-ориентированного программирования:
С учетом сказанного давайте перейдем к обсуждению дизайна и реализации. В конце концов, это то, к чему многие люди в любом случае хотят перейти, не так ли?
Прежде чем писать какой-либо код, я хотел бы сделать два поста о четырех пунктах объектно-ориентированного программирования (потому что я один из тех, кто согласен с идеей, что их четыре).
Два столпа ООП
Опять же, их понимание является ключом к пониманию основ объектно-ориентированного программирования. Без них будет сложно ориентироваться в остальной части того, что будет обсуждаться в следующих постах.
При этом давайте поговорим о каждом из них. О первых двух мы расскажем в этом посте, а о двух последних — в следующем.
1 Абстракция
Вообще говоря, это ключ к написанию объектно-ориентированного кода. Под этим я подразумеваю все, что содержится в классе. Мы абстрагируем идею чего-либо в класс. Во многих книгах мы увидим такие вещи, как животные или автомобили, представленные в виде классов.
Теоретически это работает, но на практике мы не программируем животных и не программируем машины (хотя, я думаю, на данном этапе истории вы могли бы утверждать, что мы программируем, но я отвлекся, потому что вы понимаете, что я имею в виду).
Вместо этого мы собираемся абстрагировать идеи в их классы. И здесь есть ключевая мысль:
Класс должен представлять существительное.
То есть у вас не должно быть класса, представляющего что-то вроде «Бег». Вместо этого у вас может быть что-то, что работает, и, таким образом, запуски будут методом. И это общая разбивка того, как работает абстракция:
- То, что должно быть представлено, это класс,
- То, что делает вещь, это ее методы,
- И то, как вы описываете вещь, обычно можно сделать через ее атрибуты или свойства.
Это не означает, что у нас нет функций или методов, которые изменяют его свойства, но три приведенных выше пункта являются хорошим практическим правилом. Итак, когда вы разрабатываете класс, вы можете задать такие вопросы, как:
- Я что-то пишу?
- Я пишу, что делать?
- Или я пишу что-то, что описывает что-то?
Потому что, если вы пишете действие, оно, скорее всего, выполняется чем-то (потому что вещи совершают действие — они что-то делают). И если вы что-то описываете, то это, скорее всего, относится к чему-то (когда в последний раз вы ничего не описывали?)
Есть смысл?
2 Инкапсуляция
Итак, если мы пишем классы — хорошие классы — то нам нужно писать их таким образом, чтобы правильно инкапсулировать их данные. И инкапсуляция — это просто «большое» слово, которое относится к идее управления своими обязанностями (или отслеживания своих данных).
Так, например, если бы мы писали класс для представления сообщения WordPress, то у нас был бы класс с именем Post со свойствами, такими как публикация, обновление, удаление, postData, publishDate, lastUpdatedData, deleteDate и так далее.
Тогда у нас были бы функции, специально разработанные для выполнения действий над экземпляром класса Post.
Дело в том, что мы можем…
- публиковать,
- Обновить,
- или удалить пост
Эти методы, скорее всего, будут представлены таким образом, что другие классы смогут воспользоваться ими. Кроме того, эти методы, скорее всего, также будут использовать преимущества других свойств, таких как publishDate илиDeletedDate.
И здесь в игру вступает понятие видимости. В объектно-ориентированном программировании инкапсуляция относится не только к идее информации, которую содержит класс, но и к тому, как он предоставляет данные.
Это делается тремя способами, каждый из которых определен ниже:
- общедоступные свойства и функции доступны для использования любым пользователем; однако общедоступные свойства обычно не раскрываются. Вместо этого мы гарантируем, что они могут быть изменены общедоступным методом.
- защищенные свойства и функции доступны для использования классом и любым другим классом, который наследует от него информацию. Подробнее об этом будет рассказано в следующем посте.
- частные свойства и функции предназначены исключительно для использования в контексте данного класса. Это могут быть свойства, используемые для отслеживания внутренних статусов, или методы, используемые в качестве вспомогательных функций для общедоступных функций для выполнения их работы.
По мере продолжения этой серии мы увидим, какую роль каждый из них играет при написании четких, простых в использовании, хорошо структурированных классов.
Однако сейчас важно понимать, что эти слова, public, protected и private, называются модификаторами видимости, потому что они, как вы можете убедиться, управляют видимостью метода или свойства по отношению к его классу и классы, которые наследуются от него и взаимодействуют с ним.
Говоря о наследовании, я буду говорить об этом в следующей части этой серии.
Абстракция, инкапсуляция и WordPress
Плохая новость: классы в WordPress
Вот в чем дело: в WordPress мы часто видим очень, очень большие классы. Это не хорошая вещь. На самом деле это антипаттерны, называемые бого-классами (идея в том, что у вас есть единственный класс, который знает все).
А когда у вас есть бог-класс, это кажется удобным, потому что вы можете собрать весь функционал в одном месте. Но
- трудно проверить,
- он не масштабируется,
- он плохо работает с другим классом (не говоря уже о классах или сторонних библиотеках),
- он плохо приспосабливается к изменениям.
В конечном счете, когда вы делаете это, вы не занимаетесь объектно-ориентированным программированием. Вы берете функции и добавляете их в класс. И мы хотим уйти от этого.
Хорошие новости: написание классов на WordPress
Однако возникает вопрос: зачем пытаться изучать объектно-ориентированное программирование с помощью WordPress, если это не хороший пример объектно-ориентированного программирования?
Это потому, что вы все еще можете писать хороший объектно-ориентированный код на WordPress. Он по-прежнему может хорошо взаимодействовать с WordPress и прекрасно сочетаться со многими другими аспектами WordPress.
Я знаю, это звучит нелогично, но по мере того, как мы углубляемся в написание объектно-ориентированного кода на WordPress, это должно стать ясным.