Тимур Машнин - Введение в объектно-ориентированный дизайн с Java

И класс пиццы может обобщен.

Это кажется разумным, но давайте посмотрим, почему это является неправильным использованием наследования.

Несмотря на то, что пицца pepperoni – более специфическая пицца, она не очень отличается от суперкласса.

Вы можете видеть, что конструктор pepperoni использует конструктор пиццы и добавляет начинки, используя метод суперкласса.

В этом случае нет причин для использования наследования, потому что вы можете просто использовать только класс пиццы для создания пиццы с пепперони в качестве верхней части.

Второй признак ненадлежащего использования обобщения – если вы нарушаете Принцип Замещения Лискова.

Принцип гласит, что подкласс может заменить суперкласс, тогда и только тогда, когда подкласс не изменяет функциональность суперкласса.

Как этот принцип может быть нарушен через наследование?

Давайте посмотрим на этот пример.

Это наш обобщенный класс животных, и он знает, как есть, гулять и бегать.

Теперь, как мы можем ввести подкласс, который нарушит принцип замещения Лискова?

Что, если у нас есть этот тип животных?

Кит не знает, как гулять и бегать.

Гулять и бегать – это поведение наземных животных.

И принцип замещения Лискова здесь нарушен, потому что класс китов переопределяет класс животных, и ходячие функции заменяет на плавательные функции.

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

Вы когда-нибудь использовали класс стека в Java?

Стек имеет небольшое количество четко определенных поведений, таких как peak, pop и push.

Но класс стека наследуется от класса вектора.

Это означает, что класс стека может возвращать элемент по указанному индексу, извлекать индекс элемента и даже вставлять элемент по определенному индексу.

И это не является поведением стека, но из-за плохого использования наследования это поведение разрешено.

Если наследование не соответствует вашим потребностям, подумайте, подходит ли декомпозиция.

Смартфон – это хороший пример того, где декомпозиция работает лучше, чем наследование.

Смартфон имеет характеристики телефона и камеры.

И для нас не имеет смысла наследовать от телефона, а затем добавлять методы камеры в подкласс смартфон.

Здесь мы должны использовать декомпозицию для извлечения ответственностей камеры и размещения их в классе смартфона.

Тогда смартфон будет косвенно обеспечивать функциональность камеры в телефоне.

Наследование может быть сложным принципом разработки, но это очень мощный метод.

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

И наследование – это просто один из способов помочь вам достичь этой цели.

И важно понимать, что этот метод полезен только при правильном использовании.

При проектировании здания архитекторы создают эскизы, чтобы визуализировать и экспериментировать с различными проектами.

Эскизы быстро создаются и интуитивно понятны для представления дизайна клиенту, но эти эскизы недостаточно подробны для строителей.

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

Эти дополнительные детали позволяют строителям точно построить то, что предлагает архитектор.

Для программного обеспечения, разработчики используют технические диаграммы, называемые UML диаграммами, для выражения своих проектов.

Напомним, что для концептуального дизайна мы использовали CRC-карточки, которые аналогичны эскизам архитекторов для визуализации и экспериментов с различными проектами.

Карточки CRC хороши только для прототипирования и моделирования проектов на более высоком уровне абстракции.

Однако, для реализации, нужна техника, которая больше похожа на план.

Диаграммы классов UML позволяют представить дизайн более подробно, чем карточки CRC, но это представление будет все еще визуальным.

Диаграммы классов намного ближе к реализации и могут быть легко преобразованы в классы в коде.

Принцип абстракции дизайна представляет собой идею упрощения концепции в области задачи до ее сути в каком-то контексте.

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

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

Итак, как например, класс продуктов питания выглядел бы в диаграмме классов?

Это представление диаграммы класса продуктов питания.

Каждый класс в диаграмме классов представлен полем.

И каждая диаграмма разделена на три секции, как в CRC-карточке.

Верхняя часть – это имя класса.

Средняя часть – это раздел свойств.

И это эквивалентно переменным-членам в классе Java, и эта часть определяет атрибуты абстракции.

И, наконец, нижняя часть – это раздел операций, который эквивалентен методам в классе Java и определяет поведение абстракции.

Свойства, которые эквивалентны переменным-членам Java, состоят из имени переменной и типа переменной.

Типы переменной, как и в Java, могут быть классами или примитивными типами.

Операции, эквивалентные методам Java, состоят из имени операции, списка параметров и типа возвращаемого значения.

Теперь, если мы сравним карточку CRC с нашей диаграммой классов, вы можете заметить, как некоторые из обязанностей карточки превратились в свойства в диаграмме классов.

Некоторые из них стали операцией.

Конечно, вы можете использовать CRC-карточки для абстрагирования объекта, но тут возникают двусмысленности, которые препятствуют программисту перевести CRC-карточку в код.

Одна из двусмысленностей заключается в том, что CRC-карточка не показывает разделения между свойствами и операциями.

Все они перечислены вместе.

Теперь, когда у нас есть представление диаграммы классов, давайте реализуем его в код Java.