Объяснение концепции АТД
Доброго времени суток, форумчане! P.S - если я запостил не туда (неверный топик, ветка или еще что), то, пожалйста, переместите
Итак, желание написать этот пост возникло после углубления в концепцию абстрактных типов данных. Я не особо хорошо понимал чем же отличаються АТД от классов. Все же, после долгих размышлений я пришел к неким выводам и объяснениям, которыми, собственно, и хочу поделиться.
Начнем с определения АТД. Наверное лучшее определение АТД дано на википедии).
И все же я дам определение собственными словами: АТД - это тип данных, предоставляющий согласовынный набор функций-членов для работы с данным АТД и взаимодействия с другими АТД. «Абстрактный» потому, что позволяет моделировать абстрагированную от низкоуровневой реализации сущность. Конечно, работа сущности включает низкоуровневость, но позже, мы на это обращать внимания не будешь.
Вопрос: Почему в названии фигурирует именно «тип данных», а не «структура данных»? Ответ: Потому, что тип данных как таковой определяет именно набор операций и множнство значений, применямых относительно типа данных.
АТД позволяет нам работать на высоком уровне абстрации (а не на низком). Это достигается абстракцией реализации - т.е нам не важно из чего состоит объект, нам важны операции, относительно него. (или так: неважно какой у объекта цвет кожи, важно то какие функции он выполняет). В книге Стива МакКоннела «Совершенный код» очень хорошо обсуждаются АТД и какую роль они играют при создании класса. «Совершенный код»: При написании очередного класса очень важно подумать о нем как о АТД: Мое объяснение этого утверждения: нам нужно сосредоточиться над логической группировкой и созданием операций, предоставляемых классом (т.е контракт), вне зависимости от того, какими данными этот класс будет оперировать в будущем (при дальнейшем, детальном проектировании)
Пример из реальной жизни: Есть строительная компания «OOO как-то там»... создатели этой компании изначально (еще раз: изначально!) определили контракт, который они будут выполнять отосительно своих клиентов. Т.е в этот контракт входят пункты: - осуществить постройку - закупка материалов для постройки - предоставление материалов - еще что-то - и что-то еще Заметьте, что они не думали о персонале или о процессе строительста или о строительных материалов (т.е о том, как будет выполнен контракт), они от этого абстрагировались. В последствии, создатели компании наймут персонал или уволят кого-то, перестроят структуру управления компанией или создадут филиалы в других странах... но одно останется неизменным: КОНТРАКТ! Конечно, филиалы - это наследники, и они могут дополнять контракт (но не изменять/замещать его! - это уже из области LSP).
Т.е важен контракт, а не низкоуровневая реализация при работе с АТД или его создании.
Так в чем же отличие АТД от класса, зачем понадобилось вводить понятие «АТД», если можно было ограничиться и понятием «класс»?
Во-первых понятие «АТД» возникло задолго до появления понятия «класс». Я считаю, что класс лишь дополнил концепцию АТД. Дело в том, что при создании класса мы уже по-сути должны были выделить данные, с которыми он будет оперировать и которые ббудут его составлять. В случае с АТД мы концентрировались только на операциях, но не на данных с которыми можно было бы эти операции соотнести. В случае с классом мы уже будем концентироваться и данных и дальнейшем их поддержании, структуризации, построении иерархии классов, определять как будут себя вести объекты отдельного класса из иерархии (полиморфизм). Осталось неизменным и определнным в начале проектирования класса одно: АТД.
Изначально созданный АТД, в последствии, может быть применен для создания классов во множествах отдельных разрабатываемых систем.
Класс = АТД + полиморфизм + наследование. - из книги Стива МакКоннела «Совершенный код».
Выводы: - Классы дополняют АТД. - АТД позволяет сосредоточиться на интерфейсе, а не на реализации АТД. Ведь мы думаем об операциях, в первую очередь. - АТД позволяет работать с высокоуровневыми абстракциями и не задумываться как они реализованы на низком уровне. - В центре внимания АТД - интерфейс.
P.S - может это и довольно глупо с моей стороны писать пост, посвященный АТД, но здесь я смог выразить свои мысли и премеры относительно этого понятия (не пинайте сильно :-)). Если у Вас есть какие-нибудь размышления/дополнения/замечания к статье, то пожалуйста, оставьте комментарий.
ГЛАВНЫЙ ВОПРОС?: Правильно ли я понимаю следующее?: Класс - один из способов воплощения концепции АТД, и кроме того, класс дополняет эту концепцию путем введения иных концепций, таких как полиморфизм и наследование?
Спасибо, что прочли.
Дополнительные материалы и использованные источники: - http://www.cs.iastate.edu/~hridesh/teaching/362/07/01/papers/p50-liskov.pdf - Стив МакКоннел - «Совершенный код»