Введение

Роберт Л. Гласс утверждал, что практика важнее теории. Особенно в разработке программного обеспечения практика является приоритетной областью, и разработчики получают максимальную отдачу от погружения в конкретный код, работая с ним. Поэтому мы оставим в стороне теорию и концепции и рассмотрим простую программу.

Реализация приложения для продажи билетов

• Мы хотим организовать небольшое мероприятие для продвижения камерного театра.
  • Содержание мероприятия: отправка приглашений на бесплатное посещение концерта случайным образом выбранным зрителям.
• Необходимо разделить зрителей, выигравших в мероприятии, и тех, кто не выиграл.
  • Зрители, выигравшие в мероприятии: обмен приглашения на билет.
  • Зрители, проигравшие в мероприятии: покупка билета за деньги.

Код практикума: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

В чем проблема?

Роберт Мартин описывает три функции, которые должен выполнять программный модуль (независимо от размера, такой как класс, пакет, библиотека и т. д., представляющий собой любой элемент, составляющий программу).

• Работает должным образом во время выполнения.
• Существует для изменений.
  • Изменения должны быть возможны за счет простых действий.
• Общение с человеком, читающим код.
  • Разработчик должен легко читать и понимать код.

Предыдущее приложение для продажи билетов удовлетворяет первому ограничению по правильному выполнению, но не удовлетворяет цели изменения и связи.

Код, выходящий за рамки ожиданий

Рассмотрим причину, по которой цель связи не достигнута.

• Что делает метод enter() класса Theater
  • Камерный театр проверяет сумку зрителя на наличие приглашения.
  • Если в сумке есть приглашение, театр приказывает продавцу переместить билет из кассы в сумку зрителя.
  • Если в сумке нет приглашения, театр забирает из сумки зрителя сумму, эквивалентную стоимости билета, покупает билет и кладет его в сумку.
• Зритель вынужден наблюдать, как посторонний человек, камерный театр, без его ведома роется в его сумке, берет деньги и кладет билет.
• Продавец вынужден наблюдать, как посторонний человек, камерный театр, без его разрешения манипулирует билетами и деньгами в кассе.
• Понятный код — это код, действия которого не сильно отличаются от наших ожиданий, но камерный театр выходит за рамки наших ожиданий.
  • Зритель должен сам вытащить деньги из своей сумки, заплатить продавцу и получить билет.
  • Продавец должен сам взять билет из кассы, передать его зрителю и получить от него деньги, которые нужно хранить в кассе.
• Кроме того, для понимания метода enter() необходимо запомнить множество дополнительных деталей.
  • Audience имеет Bag.
  • В Bag находятся деньги и билет.
  • TiketSellet продает билеты в TicketOffice, и в TicketOffice хранятся деньги и билеты.

Код, уязвимый для изменений

Метод enter() предполагает два условия.

• Зрители всегда носят с собой сумку для хранения денег и приглашений.
• Продавец продает билеты только в кассе.

А как насчет следующих ситуаций?

• Зритель может не иметь сумки.
• Зритель может использовать кредитную карту, а не наличные.
• Продавец может продавать билеты за пределами кассы.

Например, для удовлетворения первого требования необходимо удалить объект Bag класса Audience и изменить связанный с ним метод enter() класса Theater. Это связано с тем, что класс Theater слишком сильно зависит от детализированной информации о том, что зрители носят с собой сумку, а продавец продает билеты только в кассе. При изменении хотя бы одного из этих деталей необходимо изменять как этот класс, так и зависимые от него классы (например, Theater).

Это проблема, связанная с зависимостями между объектами, и зависимость предполагает влияние на изменения. Но объектно-ориентированный дизайн направлен на создание сообщества объектов, которые работают вместе, будучи взаимозависимыми, поэтому мы не должны просто удалять зависимости, а сохранять минимум зависимостей, необходимые для реализации функций приложения, и удалять ненужные зависимости.

Если между объектами слишком много зависимостей, это называется высокой степенью связности. Чем выше степень связности между двумя объектами, тем выше вероятность того, что они будут изменены вместе. Поэтому цель проектирования заключается в снижении степени связности между объектами для создания конструкции, которую легко изменить.

Улучшение конструкции

Theater не нужно знать, что зритель носит с собой сумку, а продавец продает билеты в кассе. Theater просто хочет, чтобы зритель вошел в театр. Поэтому зритель должен самостоятельно управлять деньгами и приглашениями в своей сумке, а продавец — билетами и ценой продажи в кассе, чтобы они были автономными сущностями.

Повышение автономии

Объект, который выполняет только те задачи, которые тесно связаны с ним, и делегирует не связанные задачи другим объектам, считается объектом с высокой степенью сплоченности. Создание автономных объектов, которые сами управляют своими данными, позволяет снизить степень связности и повысить степень сплоченности.

Процедурное и объектно-ориентированное программирование

• Процедурное
  • Метод enter() класса Theater — это процесс, а Audience, TicketSeller, Bag, TicketOffice — данные.
  • Способ размещения процессов и данных в отдельных модулях называется процедурным программированием.
  • Часто встречается код, противоречащий нашей интуиции. (Например, зритель сам управляет деньгами и приглашениями.)
  • Трудно сузить влияние изменений данных.
  • Ответственность централизована. (Theater управляет всем)
• Объектно-ориентированное
  • Способ размещения данных и процессов в одном модуле называется объектно-ориентированным программированием.
  • Можно писать код, соответствующий нашей интуиции.
  • Влияние изменений данных можно эффективно сузить за счет инкапсуляции.
  • Каждый объект сам отвечает за себя.
  • 
    

Код практикума: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Можно улучшить еще больше.

• Класс Bag класса Audience все еще является пассивной сущностью, управляемой классом Audience, поэтому класс Bag должен быть сделан автономным объектом.
• Класс TicketOffice класса TicketSeller также управляется TicketSeller по своему усмотрению. TicketOffice должен быть сделан автономным объектом.
  • Однако после изменения появилась дополнительная связь между TicketOffice и Audience.
  • Проектирование требует тщательного взвешивания всех за и против. В этом случае, чтобы снизить степень связности с Audience, можно договориться о создании TicketOffice в качестве более или менее пассивного объекта.

Код практикума: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Да, это ложь!

• Несмотря на то, что в реальности объекты могут быть пассивными, в мире объектно-ориентированного программирования все становится активным и автономным.
• Полезно использовать персонификацию, чтобы представить пассивные объекты как что-то, что улыбается, разговаривает и сердится.

Объектно-ориентированное проектирование

Почему необходимо проектирование?

• Проектирование — это расположение кода.
• Хороший дизайн — это дизайн, который сегодня полностью выполняет требования к функциональности и при этом легко адаптируется к изменениям завтра.

Объектно-ориентированное проектирование

• Изменяемый код — это понятный код.
• Объектно-ориентированная парадигма помогает нам писать код так же, как мы видим мир.
• Объект — это автономная сущность, которая сама отвечает за свои данные.
• Отличный объектно-ориентированный дизайн — это дизайн, который правильно управляет зависимостями между взаимодействующими объектами.

Источники

• Объекты