Абстрактные типы данных

Коллега купил книгу Бертранда Мейера “объектно-ориентированное конструирование”

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

Что же это? Мы работаем с объектами в наших приложениях, это все знают, но как они зарождаются? Я обозначу ниже этапы эволюции объекта:

тип -> АТД -> класс -> объект


Вот теперь давай попробую создать объект например “дверь” (возможно не самый удачный пример ибо нет данных).

  • Тип : Первым делом я определяю тип этой сущности т.е. набор функционала. Дверь можно открыть и закрыть…в общем то все)))
  • АТД :

Я должен дать название этому типу — Door и дать названия функционалу который должен быть семантически максимально связан — Open, Close

Бертранд Мейер вносит понятие как спецификация АТД, это некая табличка где мы математически описываем элементы нашей будущей сущности.

Вот так она представлена на примере стека

Попробую и я

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

Функции: описываем в функциональном (математическом) стиле сигнатуры
“New :” это наименования операции. “->” это как бы тело метода что-то делающего. Слева от стрелки это аргументы, справа это результат. Если стрелка с черточкой это значит метод выполнится при определенных условиях. Почему некоторые методы возвращают дверь? Потому что в математике side-effect’ы (изменение целевого объекта) не допустимы, но мы это опускаем в реализации.

Предусловия: Тут мы определяем предусловия для того функционала который выполняется частично. В моем случае открытие двери невозможно если оно уже открыто. На этом этапе я обнаружил необходимость добавления IsOpen

Аксиомы : Это набор семантических правил которые должны четко дать понять что мы имеем дело именно с дверью (открывать и закрывать мы можем не только дверь), а не с крышкой какой нить. Но у меня кажется так сделать не получилось)) Например “not IsOpen(new())” значит что при создании двери она закрыта.

  • Класс:

Вроде бы определил АТД, теперь его нужно реализовать, он как и ТИП реалзуется с помощью класса.

реализация АТД

Класс не обязательно должен быть абстрактным, он может быть и конкретным. Главное — это название и интерфейс , который должен являться достаточно необходимым описанием абстракции двери. Данный интерфейс должен быть понятен всем. Ничего не должно быть лишнего, а лишнее — это другие публичные методы (например Sound)и они то собственно являются реализацией.

Кстати чем же будет являться это?

А это явное определение типа. И класс может реализовывать несколько типов. И чтобы их отделять друг от друга мы используем стереотип интерфейс. Он как бы говорит “я отношусь к такому то типу и предоставляю такой то функционал”.

  • Объект : Это уже то что создает наше приложение в памяти, просто куски памяти над которыми можно производить манипуляции.

В итоге мы получили некий тип (интерфейс) и абстракцию (некое понятия с достаточно необходимым и недвусмысленным функционалом ) представляющую абстрактный тип данных - дверь. Получившийся АТД отвечает на вопрос не как работает дверь, а что делает дверь. Теперь мы можем взять класс дверь за основу для создания деревянных дверей, сказочных дверей которые будут реализациями или же использовать данную абстракцию расширив другой абстракцией…

Так что же такое АТД — это концепция позволяющая создать хорошо обдуманную модель. АТД хорошо соотносится с концепцией сокрытия информации так как формирует контракт. Это направляющее для модульности.

Все существующие принципы (SOLID например), практики рефакторинга или советы по написанию чистого кода, по моему мнению, являются борьбой с последствиями неправильного понимания и реализации АТД или просто его пропуск. Т.е. мы обычно просто создаем некий класс и добавляем ему методы глубоко не задумываясь. И есть вероятность что такие классы в большом приложении будут влиять на основные функциональные качества приложения (например гибкость, расширяемость и т.д.)

PS: хорошая статья про АТД
Like what you read? Give Pavel Kolmakov a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.