Базовые понятия ООП и паттерны проектирования
Предисловие
В книжке "Приёмы ООП. Паттерны проектирования (Гамма, Хелм, ..., 2011)" на предисловии сказано
"У вас не должно возникать необходимость лезть в словарь за разъяснением терминов тип и полиморфизм"
И всё таки я решил посмотреть в "словаре" ради любопытсва. До этого где-то в 2006 году в университете узнал, что
"тип есть множество объектов с операциями над ними" (определение алогично определению алгебры)
"полиморфизм" - дословно переводится как "много форм". В контексте ООП означает работа с объектами разных форм одинаковым методом. Смотря на определение базовых понятий ООП из разных русскоязычных источников сложилось впечатление, что эти изначальные понятия не вводятся, и не потяно кто эти термины придумал.
Далее будут приведены базовые понятия ООП на основе лекций по С++, Тассова К.Л., читаемых в МГТУ им. Н.Э. Баумана на ИУ-7
Откуда появилось ООП
ООП родилось из недостатков структурное программирования.
Достатки / Недостатки структурного программирования.
Базовые понятия ООП
В 1966 г. Чарльз Хоар провёл лекции по совместному использованию записей и предложил (эти лекции в интернете не нашёл)
1) Выделить действия над данными и для модификации данных использовать надстройку.
Это было названо инкапсуляцией
2) Для модификации программных сущностей использовать при возможности надстройку над существуюшими сущностями. Это было названо наследованием
3) Хоар предложил взаимодействие в программе объектов делать таким же как и в реальном мире и выделили
акцессорное взаимодействие - как считывание характеристик объекта. Такой тип взаимодействия иногда называют статическим.
событийное взаимодействие - взаимодействие связанное с изменением состояния объекта. Такой тип взаимодействия называют динамическим.
Объект - конкретная реализация абстрактного типа, обладающая характеристиками состояния, поведения и индивидуальностью
Поведение - описание объекта в терминах изменения его состояния и передача сообщений в процессе воздействия или под воздействие других объектов
Индивидуальность - сущность объекта, отличающего его от других объектов
Отношения между объектами
Отношение использования (объект может выполнять роль воздействия, исполнения, посредничество)
Включение. Объект может состоять из других объектов. (агрегация по ссылке, агрегация по значению(композиция))
Категории объектов:
Реальные объекты - абстракция фактического существования объектов в физическом мире (стол)
Роли - абстракция цели, назначения (студент, человек)
Инциденты - абстракция чего-то случившегося или произошедшего (скачок напряжения)
Взаимодействие - объекты получаемые из взаимодействия между объектами
Спецификации - используется как представление правил или критерий качества
Класс - это такая абстракция предметов реального мира, что:
Все предметы в этом множестве имеют одни и те же характеристики
Все объекты подчинены и согласованы с одним и тем же набором правил и линий поведения
Отношения между классами
1) Наследование. Какой-то класс строится на основе другого
2) Использование. Объект одного класса вызывает методы по работе с объектом другого класса
3) Наполнения. Класс включает в себя другие классы.
4) Мета-Классы. Класс, объекты которого есть классы.
Домен - отдельный реальный гипотетический мир, населенный отчётливым набором объектов которые ведут себя с характерными для домена правилами или линиями поведения. Класс определяется в одном домене. Класс в домене может требовать только существования других классов в этом домене.
Приёмы ООП. Паттерны проектирования (Гамма, Хелм, ..., 2011). Интересное из книги.
Нужны ли они или нет, но в курсе быть про них не плохо. Основные тезисы:
Программируйте в соответствии с интерфейсами, а не в соответствии с реализацией
Предпочитайте композицию наследованию класса. С использованием делегирования композицию становится столь же мощной концепцией как и наследование.
Делегирование - это "использование" в терминах предыдущего раздела
Композиция - это "включение" в терминах предыдущего раздела
Параметризация типов - это третий способ после наследования и композиции решения задачи в ООП стиле
Паттерны могут пригодится при реорганизации повторно используемого ПО
Список паттернов о которых рассказывается в книге:
Abstract Factory
Factory
Builder
Factory Method (virtual constructor)
Prototype
Singleton
Adapter(Wrapper)
Bridge
Composite
Decorator
Facade
FlyWeight
Proxy
Chain of Responsibility
Comand
Iterator
Mediator
Memento
Observer (depends, publish-subscribe)
State
Strategy(Policy)
Template Method
Visitor
Создание семейства взаимосвязных объектов.
Определяет интерфейс для создания коллекции объектов.
Интерфейсные методы по сути являются Factory Method - ми.
И содержат create* методы
Конструирование сложного объекта. Распорядитель (director) конфигурируется нужным строителем (builder). Затем director говорит builder что нужно построить часть. builder строит часть и добавляет к продукту. Клиент забирает продукт у строителя.
Определяет метод который в подклассах требуется реализовать по созданию объекта. Например CreateInstance. Но оставляет права за наследниками решать что именно инстанцировать. Но дергать придётся CreateInstance не у класса, т.к. он неизвестен, а у другого класса.
Объекты наследуют интерфейс Prototype, в котором имеется метод Clone по клонированию самого себя с возвращением Prototype.
Гарантирует, что у класса есть один экземпляр.
Преобразует интерфейс одного класса в другой.
Реализации:
Р1) Открыто наследоваться от Target интерфейса. и закрыто от Adaptee. Таким образом доступ в Adaptee будет только внутри адаптера. Эксплуатировать это знание для реализации Target
Р2) Открыто наследоваться от Target интерфейса. Указатель на Adaptee принимать в конструкторе. При реализации Target интерфейса эксплуатировать методы Adaptee объекта.
Отделить реализация от интерфейса чтобы и то и то можно было развивать параллельно.
Реализация аналогична Р2 для адаптера. Отличается только способом применения.
Так же интерфейс паттерна может быть более полным и предоставлять более высокие примитивы работы (нарисовать квадрат)
В то время как реализация предоставляет более низкоуровневые примитивы (нарисовать линию)
Древовидная структура объектов. Perent-Child
Добавляет новые обязанности. Реализация аналогична P2.
Суть - перед дёргом метода (пусть будет Draw) мы рисуем декорированную оснастку и затем дёргаем у декорируемого объекта Draw.
Унифицированный интерфейс к подсистеме. Простой и понятный интерфейс для работы с системой.
Разделение для эффективной поддержки множества мелких объектов.
Проксирует доступ к объекту. Например с помощью этого похода может быть реализовано создания тяжелой части объекта только по требованию. А так же кеширование вычислений.
Связывает объекты - получатели запроса в цепочку, и передаёт запрос вдоль цепочки по очереди, пока его не обработают. Цепочку можно организовать имея указатель в объекте на след. объект-получатель.
С помощью паттерна можно реализовать Help в системе
Обернуть команду в объект. Можно таким образом ставить запросы в очередь, протоколировать их, поддерживает отмену операций.
Итератор
Посредник. Объекты системы не ссылаются друг на друга, а работают через посредника. Паттерн позволяет уменьшить связность объектов в системе.
Фиксирует внутренне представления объекта, чтобы потом можно было восстановить состояние.
При изменении состояния объекта все зависящие от него оповещаются. Регистрироваться могут Observer-ы сами в их конструкторах/деструкторах.
На основе передаваемого Subject субъекта или события. Которые в определенный момент дергает notify в котором происходит дёрг всех observer-ов
Варьирование поведения объекта в зависимости от внутреннего состояния. Моделирует поведение в зависимости от состояния. Табличный метод для конечным автомата акцентирует внимание на определении переходов между стейтами. А здесь смыс в том, что тот кто хостит объект state его динамически меняет, и делигирует действия этому объекту
Позволяет реализовывать взаимозаменяемый алгоритмы.
Статический полиморфизм можно реализовать через параметр шаблона - инстанс стратегии является просто мембером объекта-алгоритма. Тип этой мембера получается из параметра шаблона.
Динамический полиморфизм реализуется через виртуальные методы.
Есть алгоритм и он состоит из шагов "примитивных операций". Идея позволить подклассам переопределить часть этих "примитивных операций", на которые полагается алгоритм зашитый в шаблонном методе. В контексте этого подхода можно вспомнить принцип Голиивуда - "Не звоните нам, мы сами вам позвоним".
Нууу, обычно бывают они таких видов, судя по книге:
- конкретные операции
- примитивные операции
- фабричные методы
- операции зацепки (хуки)
Операция выполняемая с каждым объектом коллекции. У vistor как правило есть типизированные visit методы при обходе контейнера у элемента дёргается Accept с аргументов visitor-ом. Затем этот метод дёргает у визитора нужный метод visitSmb, передавая ссылку на *this.
Проблемы в ООП
brittle base class problem - чем должен обладать базовый класс, чтобы служить всем мыслимым проиводным классам так, чтобы не обладать какими-либо dummy данными и методами.
Другие паттерны, подходы, более близкие к жизни с моей точки зрения
Аллокатор
Прокси к реальному хранилищу. Как правило ничего не хранит внутри.
"Functions placed at the lower levels may be redundant or of a little value when compared to providing them at the higher level." Saltzer, 1984