Абстракции это: Абстракция. Что такое «Абстракция»? Понятие и определение термина «Абстракция» – Глоссарий

Кратко об абстракциях / Хабр

Бывает так что проект заходит в тупик, и дальнейшее его развитие становится невозможным. Не редко причиной такого провала становится неудачная архитектура, заложенная в начале разработки. Или приходится наблюдать споры о том какой из «двух стульев» лучше, а может даже участвовать и искренне не понимать, как оппонент может так думать!?

Тогда попробуем не много разобраться в абстракциях, откуда они берутся и что с ними делать.

Согласно Википедии Абстракция – это теоретическое обобщение как результат абстрагирования. В свою очередь абстрагирование – это отвлечение в процессе познания от несущественных сторон, свойств, связей объекта (предмета или явления) с целью выделения их существенных, закономерных признаков.

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

Абстракции формируют иерархии, и могут отождествляться как с частными сущностями, так и объединять схожие сущности в более высокоуровневые абстракции.

Абстракции в сознании

Кроме призмы восприятия, наши модели подвергаются ещё одному искажению: реальные сущности чрезвычайно сложны и имеют разные аспекты и параметры. При размышлении или разговоре о чём-то, всегда существует контекст, в котором существует модель. Причём иногда бывает так, что у собеседников этот контекст разный. И в довершение, наличие или отсутствие опыта (глобального) приводит к ещё большему изменению наших моделей в соответствие с этим опытом. В итоге у двух разных людей может быть очень разное восприятие одних и тех же сущностей реального мира.

Выходит, что каждый человек постоянно имеет дело с абстракциями, осталось научиться их явно видеть и управлять. Можно выдвинуть тезис, что программный код — это симуляция мышления, основанная на формализованных абстракциях. Поэтому, на мой взгляд, разработка ПО — это один из лучших тренажёров для прокачки абстрактного мышления.

Абстракции в разработке

Программные интерфейсы — это, пожалуй, самая явная формализованная абстракция. Отсекается все лишнее и остаётся только «что оно делает» без «как оно делает».
Реализуя интерфейс, мы создаём более реальную модель поведения или взаимодействия, которая уже может ответить на вопрос «как». Комбинируя интерфейсы между собой, мы можем создать общую архитектуру кода. При должном умении и сноровке архитектура, созданная таким образом, в будущем будет сохранять свою структуру. В то время как реализации составных интерфейсов могут изменяться до неузнаваемости.

Такая архитектура упрощает некоторые моменты в работе. Модульное тестирование сводится к написанию тестовых реализаций «соседних» абстракций и тестовых методов, сравнивающих вход и выход. Изоляция модулей позволяет безопасно проводить рефакторинг. Более того, если рефакторинг прошёл неудачно и всё сломалось, то откатывать придётся всего один модуль. Достаточно абстрагированный модуль может использоваться для схожих, но разных задач.

При этом одна плохая реализация не будет влиять на работу других – изоляция говнокода.

Пример

Есть модуль для обработки входных данных, есть несколько вариантов их получения: из базы данных; из файла; по http. Решить эту задачу можно, выделив общий интерфейс для получения данных и сделав по реализации для каждого канала и канал данных для тестирования. Теперь один обработчик с помощью параметра «канал данных» может решать несколько схожих задач. А если выяснится, что одна из реализаций кривая, то её можно будет переделать на затрагивая другие модули.

Абстракций больше не надо

Не бывает идеальных решений, так же и с абстракциями не всё так гладко. Во-первых, абстракции субъективны, они могут вызывать споры о том, где начинается одна и начинается другая. Также существует проблема чрезмерного абстрагирования, когда под каждый вид и тональность чиха создаётся своя абстракция. Во-вторых, это подход повышает сложность кода, добавляя новые сущности, и новые уровни иерархии.

Я уверен, что найдутся ещё недостатки этого подхода, часть из них будет субъективными, часть ситуационной, но будут и

Во всём должен быть баланс. Для себя я вывел следующую памятку.

• Если пишется большой и важный модуль – лучше расцеплять его.
• Если модуль используется много и/или в разных местах – лучше скрыть его за абстракцией.
• Если модуль должен распространяться как отдельная библиотека – лучше использовать абстракции.
• Если возможно изменение алгоритмов или путей взаимодействия – лучше реализовывать взаимодействие абстракций.
• Если класс используется в другом классе и нигде больше – можно подумать об их объединении или оставить как есть.
• Если это маленькая «одноразовая» задача – лучше не заморачиваться с её усложнением.
• Если это модуль, который скорее всего никогда не будет меняться – можно вывести его интерфейс и лучше оставить внутри всё как есть.

Итого

Абстракции — это инструмент, встроенный в наше сознание, как и любой другой они имеют свои плюсы и минусы, но знание альтернатив только помогает находить лучший путь.

Уровни абстракций — ключ к пониманию архитектурных изысков ПО

Эта статья будет в большей степени полезна новичкам, только начинающим работать с абстракциями и построением архитектур ПО. Однако искренне надеюсь, что и более опытные специалисты смогут найти для себя что-то интересное в этом материале.

Абстракция — один из набивших оскомину столпов ООП. В любом курсе по программированию с вероятностью 99% можно найти урок-другой, посвященный теме абстракции. И практически всегда упускается более широкое, всеобъемлющее понятие «уровней абстракции» — на мой взгляд, критически важное, ключевое для понимания всех остальных принципов проектирования.

Модель объекта и ступень приближения

Абстракция — это модель некоего объекта или явления реального мира, откидывающая незначительные детали, не играющие существенной роли в данном приближении. И 

уровень абстракции — это и есть наша ступень приближения. Каждый человек способен строить абстракции — это отличительная способность homo sapiens. Но не каждый способен делать это достаточно качественно.

Чтобы не вдаваться в многоэтажную теорию, приведу наглядный пример. Итак, раскладываем по полочкам. Представьте себе, что вы решили испечь яблочный пирог. Вы берете толстую кулинарную книгу с полки (для любителей, все остальные — в сеть), открываете нужный вам рецепт и читаете нечто следующее:

«Чтобы испечь яблочный пирог, нам понадобится два килограмма непременно свежих яблок, румяных, как девичьи щёки на крещенском морозе. Помнится, видал я такие щёчки у моей ненаглядной Лизоньки, когда мы впервые с ней встретились, и она угощала меня яблочными пирогами, состряпанными на последние деньги, которые она выручила от продажи дедовских коллекционных монет 1819 года, выпущенных при императоре таком-то…» И т.д, и т.п.

Если вы осилили текст курсивом, то вы очевидно заметили, что он имеет весьма посредственное отношение к тому, что нам нужно. Собственно, к тому, как же печь эти чертовы пироги из яблок, не правда ли?

А теперь вспомните, как часто в коде нам приходится встречать логические конструкции типа if-if-if-else-if-else-if, содержащие тонны вложенных рассуждений. Приходится читать все эти адские нагромождения и держать в голове всю цепочку событий, для того, чтобы понять, что тут вообще происходит и какое отношение «вот это всё» имеет к заявленному содержанию (название класса/функции по аналогии с названием рецепта «яблочный пирог»).

А ведь что на самом деле нас интересовало в рецепте? Нам нужно было знать, сколько и каких продуктов нам понадобится и что затем с ними делать. Нас абсолютно не интересует в этом приближении (на данном уровне абстракции), каким образом эти продукты к нам попали (более низкие уровни абстракции) и что мы будем делать с этим пирогом потом (более высокие уровни абстракции). Это очевидно. Но тысячи программистов продолжают игнорировать эти принципы и пишут мозговыносные структуры if-if-else-if…

А бывает так, что в рецепте встречаются умные словечки типа «бланшировать» или «сделать бизе». В хороших кулинарных руководствах описание подобных практик выносят в отдельные главы, а в самих рецептах лишь ссылаются на страницы с подробным описанием техники (привет, Инкапсуляция).

Построение структуры

Конечно, бывают и обратные ситуации, когда за тоннами слоёв абстракций невозможно уловить нить повествования. Но в этом-то и состоит мастерство архитектора ПО — спроектировать достаточно простую для сопровождения, то есть понимания, структуру. «Не нужно быть умным — нужно быть понятным» ©.

В то же время, не терять в эффективности решения бизнес-задач. В некоторой мере, это искусство. Каждый конкретный архитектор (программист) будет рисовать эту картину, то есть создавать модель мира по-своему: «Я художник — я так вижу». Вот вам пища в топку холиваров на счет единых стандартов программирования в рамках команды и необходимости наличия исполнителя роли архитектора.

Абстракция и Реализация

Есть ещё один момент, о котором я хочу упомянуть: путешествие между слоями логик. Красиво изолированный уровень абстракции достаточно прост для понимания: у нас есть ряд объектов, очевидным образом взаимодействующих между собой, уровни вложенности маленькие (если они вообще есть — как в рецепте пирога).

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

Чтобы упростить этот процесс, стоит разобраться в природе дуальности понятий Абстракции и Реализации. В этом моменте обычно и фокусируются на различных курсах по программированию, перед этим упуская понятие уровня абстракции. Из-за чего у студентов формируется заблуждение, что ООП — это что-то запредельно сложное.

Возьмем для примера такую цепочку слоёв абстракций: нам нужен пирог для Дня рождения друга. Спускаемся ниже: пирог может быть фруктовый или мясной. А может, рыбный? В момент рассуждений о том, что нам нужен какой-то пирог в качестве подарка, он (пирог) выступает конечным элементом данного уровня абстракции. В этот момент пирог — это реализация подарка (но он может быть любой: бритва, деньги, конструктор лего — это всё варианты подарка). Когда мы совершаем переход на более низкий уровень абстракции, наш объект (пирог) превращается из конечной реализации в 

абстракцию: уже нас не устраивает уровень детализации «какой-то пирог», мы начинаем искать его реализацию (привет, Полиморфизм).

Таким образом, считать объект абстрактным или реальным — зависит исключительно от степени детализации моделируемого «мира» и от бизнес-задач, поставленных перед архитектором. И, разумеется, от его чувства прекрасного.

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

P.S. Написать эту статью меня побудило энное предложение стать лектором на очередных курсах по программированию. И, хотя, у меня и есть желание испытать подобный опыт, в данный период моей жизни и в обозримом будущем это не представляется возможным. Я решила, что моё желание рассказывать о сложных вещах простым и понятным образом (надеюсь, это так) пусть лучше выльется в какое-то количество статей, нежели будет погребено под тоннами лет бездействия.

Если моя манера изъясняться была кому-то полезной в достижении состояния «дзен» и вообще «пишите, Шура», то в будущем, вероятно, напишу «о чём-то таком ещё».

Продолжение

Все про українське ІТ в телеграмі — підписуйтеся на канал редакції DOU

Теми: ООП, ООП — это просто, програмування

Вниз наверху. Абстракция — это вопрос меньшего… | Кевлин Хенни

5 минут чтения

·

17 июля 2018 г.

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

Многие вещи в программном обеспечении и его разработке кажутся задом наперед, наизнанку или наоборот. Возьмем, к примеру, случай обычного дерева. У нас есть иерархии для каталогов, для вызовов функций и для наследования классов. Мы называем эти структуры деревьями. И где корень? На открытом воздухе, хорошо видно и наверху. Листья разрастаются внизу, часто затемнены, свернуты и скрыты от непосредственного взгляда. Не говоря уже о цвете (красно-черный?), эта ориентация далека от древовидной.

Как и в классическом эксперименте, когда испытуемых просят надеть призматические очки, которые переворачивают их взгляд на мир, мы приспосабливаемся. То, что раньше казалось перевернутым, теперь кажется нормальным. Мы перестаем замечать разницу. В случае с деревьями это на самом деле не проблема: свойства абстракции более полезны для нас, чем абсолютная точность метафоры. Инверсия достаточно проста, чтобы не сбивать с толку, и она редко вводит в заблуждение.

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

Рассмотрим прежде всего, что такое абстракция: действие или результат опущения или изъятия. Мы можем рассматривать проблемы, решения, модели проблем, модели решений и так далее, не теряясь в ненужных деталях — деталях, которые были абстрагированы. Разные абстракции принимают разные точки зрения, опуская одни детали, чтобы подчеркнуть другие.

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

— Ганс Хофманн

Хотя практика абстракции по своей сути не является ни хорошей, ни плохой, мы можем судить о результате в следующих терминах: хорошая абстракция — это упрощение, которое позволяет нам рассуждать о концепции или работать с дизайном. эффективно; плохая абстракция — это та, которая вводит нас в заблуждение, либо пропуская необходимые детали, либо добавляя ненужные детали, заглушая сигнал шумом. Часто именно несоответствие абстракции вводит нас в заблуждение: использование переполненной диаграммы классов с подробностями операций и атрибутов там, где схематическая диаграмма пакетов была бы более полезной; использование языка программирования, разработанного для науки и техники, для системного программирования; используя карту лондонского метро в качестве путеводителя по надземной географии Лондона.

Что же такого в абстракции такого перевернутого? При построении системы мы часто накладываем различные абстракции друг на друга по мере необходимости, что приводит к наслоению абстракций. Проблема возникает, когда мы переходим от разговора о слоях абстракции к уровням абстракции . Эти два выражения не являются синонимами и имеют совершенно разные значения. Хотя существует внешний порядок, первый не подразумевает и не требует внутреннего порядка. Последнее, однако, убедительно свидетельствует о том, что абстракциям присуща врожденная упорядоченность. Это не обязательно так, хотя иногда это может быть правдой: точка зрения, которая упускает больше деталей, чем другая точка зрения, может считаться более абстрактной. Возможно, было бы лучше сослаться на это свойство упорядочения как степень абстракции . Другим аспектом, который можно было бы упорядочить, является степень детализации. Иногда, когда люди говорят о уровнях абстракции , они имеют в виду степень детализации абстракции , которую можно считать более точным описанием.

Во многих случаях нет очевидного порядка, но люди, тем не менее, навязывают его, часто косвенно. Например, некоторые могут возразить, что FORTRAN 77 является языком более высокого уровня, чем C, потому что он организован вокруг массивов и операций с массивами, полезен для многих научных и инженерных приложений, и не имеет модели размещения памяти и управления ею. С другой стороны, некоторые могут утверждать, что C является языком более высокого уровня, чем FORTRAN 77, поскольку он поддерживает структурированный поток управления, пользовательские типы данных, абстракцию данных и динамическое управление памятью. Преимущества, предоставляемые выбором абстракции каждого языка, почти полностью дополняют друг друга по своей природе, что делает любое полное упорядочение между двумя языками в высшей степени контекстуальным и, во многих случаях, личным. Я знаю, в чем заключаются мои предпочтения, но здесь это не имеет значения: важен мой личный опыт, подтверждающий, что попытки использовать FORTRAN 77 для системного программирования — это утомительный и подверженный ошибкам опыт — болезненный и неуклюжий урок смещенных абстракций — когда по сравнению с работой в C.

Проблемы при обсуждении и рассуждениях о слоях абстракций усугубляются восприятием высоты, тенденцией говорить о выше и ниже с подразумеваемым суждением, что более высокий уровень приравнивается к лучше и ниже уровень приравнивается к хуже . Именно в этом смысле становится заметным перевернутый взгляд на мир. Предметно-ориентированные языки, модели анализа и предметно-ориентированное проектирование предлагаются нам как высокоуровневые, потому что их абстракции ближе к предметной области пользователя, чем, скажем, биты и байты, которые квалифицируются как абстракции более низкого уровня. Следовательно, эти подходы лучше подходят для тесной работы с пользователями и клиентами. Заявленная цель состоит в том, чтобы мы больше думали о проблемной области — высоком уровне, чем о области решения — низком уровне.

Подождите минутку. Если это цель, то это что-то вроде собственной цели терминологии. В то время как намерение хорошо обосновано, а практика звучит, слова звучат неправильно.

Если говорить о проблемной области как о высокоуровневой абстракции, а о машинной области — как о низкоуровневой, то это выдает укоренившееся предубеждение. Если абстракция — это акт упущения, то что упускается, когда мы говорим высокий уровень абстракции ? Что абстрагируется? Детали машинного уровня, биты и байты, типы языков программирования и т. д. Технические специалисты никогда не сомневаются в этом, но пользователи придерживаются совершенно иной точки зрения: мир, в котором они занимаются своим бизнесом, значительно более конкретен, чем мир, в котором они работают. абстрактная область программного обеспечения. Разговор о домене пользователя с точки зрения понятий, знакомых пользователям, предполагает, с точки зрения пользователя, небольшую абстракцию или ее полное отсутствие. Чем дальше вы углубляетесь в область программного обеспечения, тем менее реальными и более абстрактными становятся вещи. Это реальный мир и связанная с ним проблемная область, которые постепенно упускаются из виду.

Нам нужно быть более осторожными с предположениями, укоренившимися в общепринятой терминологии и визуализациях. Если вы рассматриваете мир машины как конкретную отправную точку, мир клиента более абстрактен. Если вы считаете мир клиента своей конкретной отправной точкой, мир машины более абстрактен. Итак, если вы пытаетесь произвести впечатление действительно ориентированного на клиента, ориентированного на пользователя и ориентированного на предметную область, вам нужно быть на низком, а не на высоком уровне. Абстракция — это не столько вопрос высоты, сколько вопрос вашей отправной точки и вашего расстояния от нее.

Сила абстракции в моделировании данных

Абстракция — это мощная тактика проектирования для создания гибких, надежных и масштабируемых моделей данных хранилища данных

Введение

Я помню, как блуждал по большим галереям музея современного искусства и остановился перед очень большим холстом, полностью выкрашенным в красный цвет с единственной белой точкой в ​​центре. Название было «City Skyline», и как бы я ни щурился и не крутил головой, я просто не мог видеть ничего, кроме большого красного полотна с белой точкой в ​​центре. Это была абстрактная картина с подробным изображением городского горизонта, но она была настолько общей и расплывчатой, что могла быть изображением тигра, сцены летнего пляжа или чего-либо еще в этом отношении. Абстракция — это инструмент, который позволяет художнику эффективно фиксировать и представлять сложные темы. Как специалисты по моделированию данных, все мы в определенной степени художники, и абстракция также является эффективным инструментом в нашем распоряжении.

Специалист по моделированию данных отвечает не только за правильное представление требований приложения, но и за предусмотрительность проектирования гибких структур в тех областях, где требования могут измениться в ближайшем будущем. Есть определенные конструкции, которые мы создаем, например, для хранилища данных, где гибкость может иметь значение между успехом или провалом всего проекта. Хранилище данных — это живая конструкция, от которой постоянно ожидают, что она легко приспосабливается к новым требованиям, но в то же время сводит к минимуму изменения конструкции, влияющие на существующие нижестоящие витрины данных. Очень хорошая тактика дизайна, которую я использовал на протяжении многих лет, чтобы удовлетворить эту потребность в гибкости, — это абстракция.

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

Дополнительную информацию об абстракции и других методах моделирования см. в моей книге «Рабочий стол разработчика моделей данных, инструменты и методы анализа и проектирования» . Кроме того, если вы готовы принять участие в моделировании данных, подпишитесь на мои конкурсы дизайна на моем веб-сайте (www.stevehoberman.com). Я периодически рассылаю сложные сценарии моделирования данных, за которыми следуют несколько возможных решений.

Что такое абстракция?

Абстракция, которую мы подробно обсудим в следующих разделах, — это метод обеспечения гибкости ваших логических и физических моделей данных путем переопределения и объединения некоторых элементов данных, сущностей и отношений в модели в более общие условия. Абстракция — это удаление деталей таким образом, чтобы сделать что-то применимым к широкому классу ситуаций, сохраняя при этом важные свойства и существенную природу понятий или предметов. Удаляя эти детали, мы удаляем различия и, следовательно, меняем наше отношение к этим понятиям или предметам, в том числе видим сходство, которое раньше не было очевидным или даже не существовало. Например, вместо отдельных сущностей «Клиент» и «Сотрудник» могут быть ситуации, когда было бы полезно иметь общую сущность «Человек», объединяющую клиентов и сотрудников вместе.

Рассмотрим более подробный пример. Предположим, вы создаете модель данных для владельца магазина смокинга. Вы уже завершили полностью нормализованный дизайн для этого проекта. Одним из основных объектов вашего дизайна является Заказчик. Объект Customer в вашей модели данных включает ряд элементов данных, включая следующие:

• Размер талии клиента
• Длина ноги клиента
• Размер шеи заказчика
• Длина плеча клиента
• Ширина плеч покупателя

Владелец магазина смокинга очень доволен вашим дизайном, и его приложение разработано на основе этой модели. Через два месяца вам звонит владелец магазина и спрашивает, где он может хранить размер обуви покупателя. Вы объясняете ему, что нет места для указания размера обуви, так как это не входило в первоначальные требования. Наступает долгое молчание. Владелец магазина объясняет, что он расширяет свой бизнес, и многим из его клиентов, которые арендуют смокинги, потребуется обувь. Вы объясняете, сколько денег и времени потребуется, чтобы внести это изменение в его заявление. Снова наступает долгое молчание. Затем вы слышите несколько щелчков, когда владелец с отвращением вешает трубку.

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

• Номер измерения клиента
• Имя типа измерения клиента

Элемент данных Customer Measurement Number включает любое значение размера, например:

• 42
• 17 1/2
• 34

И каждое из этих значений имеет тип, зафиксированный в имени типа измерения клиента. Например:

• 42 = длина плеча
• 17 1/2 = Размер шейки
• 34 = длина ноги

Клиент может иметь одно или несколько из этих измерений. Затем, когда мы получаем телефонный звонок от владельца магазина смокинга с запросом, где должен храниться размер обуви, мы просто добавляем новую строку в таблицу «Тип измерения» под названием «Размер обуви», и теперь владелец может ввести значения своего размера обуви с этим размером обуви. тип. Эта гибкость в нашем дизайне привела к тому, что мы без труда выполнили это новое требование.

Преимущества абстракции

Абстракция предлагает следующие преимущества:

Обеспечивает большую гибкость. Гибкость — основное преимущество абстракции. Мы можем проектировать наши структуры, чтобы лучше справляться с неизвестным. Могут возникнуть новые ситуации, которых мы изначально не ожидали, и если мы используем абстракцию, эти ситуации могут потребовать незначительных изменений в нашей модели данных, и, следовательно, сохранить базу данных и код нетронутыми. В недавнем проекте я решил использовать абстракцию в той части модели, которая собирала информацию об организации продаж. Я абстрагировался от всех отношений между продавцами и их должностями. Несмотря на то, что нам не нужны были сразу все возможные комбинации отношений, моя абстрактная модель обработала бы их, если бы они возникли. Конечно же, вскоре после того, как предметная область организации продаж была запущена в производство, у нас возникла необходимость добавить новый тип отношений. Структура нашей организации продаж смогла справиться с этим новым требованием без каких-либо изменений в модели данных и, следовательно, сохранить структуру базы данных и код нетронутыми.

Сокращает время анализа и проектирования.   Когда мы познакомимся с абстракцией, мы сможем применить ее к областям нашей модели, прежде чем завершить тщательный анализ требований. В примере, упомянутом ранее, вместо того, чтобы тратить время на сбор всех дополнительных типов измерений для примерки смокинга, мы можем просто добавить номер измерения и элементы данных типа, и все возможные измерения будут автоматически включены в вашу модель. В течение двух недель я смог создать модель, показывающую всю обрабатывающую промышленность, используя значительное количество абстракций. Вместо того, чтобы тратить значительное количество времени на анализ каждого элемента данных, я абстрагировался, чтобы убедиться, что в модели учтены все возможные требования. Поймите, что здесь вы можете сэкономить время, но вы также можете утратить понимание бизнес-требований.

Стоимость абстракции

Абстракция может звучать как лекарство от всего, от простуды до мира во всем мире (небольшое преувеличение). Однако за его преимущества приходится платить:

Скрывает в модели бизнес-концепции.   Когда в нашей модели данных есть только номер измерения и название типа измерения, мы больше не можем видеть отдельные измерения, подходящие для смокинга. Длина руки клиента больше не элемент данных, который мы можем четко определить и объяснить, а значение в элементе данных «Число измерений». Когда мы абстрагируемся, мы теряем фактическое имя элемента бизнес-данных. Однако модель данных по-прежнему содержит ту же информацию. Эти измерения становятся значениями строк, а не отдельными элементами данных. Через шесть месяцев после того, как мы создали модель данных tuxedo с абстракцией, кто-то может спросить нас: «Привет, что означает тип измерения?» То, что казалось отличной идеей, когда мы создавали модель данных, через шесть месяцев может уже не иметь смысла. Так что есть задача, которую мы должны выполнить еще более строго, чем раньше. Нам нужно создать очень хорошие определения.

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

Приводит к снисходительности. Слишком много абстракции может дать нам дизайн, совершенно бессмысленный для понимания и невозможный для развития. Допустим, мы продолжаем абстрагировать модель данных tuxedo. В конце концов, мы получим единую сущность под названием «Вещь» с рекурсивной связью, как показано на рис. 1. Представьте себе мощь этой сущности! Мы можем представить что угодно с этой сущностью. Фактически, мы можем представить целое приложение для управления взаимоотношениями с клиентами (CRM), используя этот единственный объект! Однако представьте, что вы объясняете эту модель кому-то из нашей сферы деятельности. Представьте, что вы пытаетесь написать код, использующий эту сущность. Теперь понятие «Вещь» немного преувеличено, но я видел модель данных элемента, в которой абстракция была доведена до такой степени, что было трудно найти в модели что-либо, связанное с бизнесом. Также было очень сложно провести бизнес-пользователя через эту модель.

Увеличивает время разработки. Хотя мы можем сократить время анализа и проектирования с помощью абстракции, мы увеличиваем время разработки. Написание кода и логики для строковых значений занимает больше времени, чем для столбцов. Например, написание кода для заполнения или выбора информации из элементов данных «Номер измерения» и «Имя типа измерения» будет более сложным и займет больше времени, чем если бы в нашем распоряжении были конкретные элементы данных измерения. Нам потребуются более сложные операторы запроса. Без абстракции наши запросы были бы намного проще и легче создавать. Например, без абстракции возврат имени и длины ног всех клиентов с размером талии 42 будет выглядеть так:

ВЫБЕРИТЕ CUSTOMER_FIRST_NAME, CUSTOMER_LAST_NAME, CUSTOMER_LEG_LENGTH
FROM CUSTOMER
WHERE
CUSTOMER_WAIST_SIZE = ‘42’

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

SELECT CUSTOMER.CUSTOMER_FIRST_NAME,
CUSTOMER.CUSTOMER_LAST_NAME,
MEASUREMENT_TYPE.CUSTOMER_LEG_LENGTH
FROM CUSTOMER, MEASUREMENT_TYPE
ГДЕ
CUSTOMER.CUSTOMER_IDENTIFIER = MEASUREMENT_TYPE.CUSTOMER_IDENTIFIER
AND MEASUREMENT_TYPE.