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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Принцип Абстракции в UML

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

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

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

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

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

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

      Карточки CRC хороши только для прототипирования