Нормализация объектов

Question

В той же строке, что и нормализация базы данных - есть ли подход к нормализации объекта, не шаблон проектирования, а такой же математический подход к нормализации создания объекта. Например: первая нормальная форма: нет повторяющихся полей .... Вот несколько ссылок на нормализацию БД:

http://en.wikipedia.org/wiki/Database_normalization http://databases.about.com/od/specificproducts/a/normalization.htm

Это улучшит создание объектов и самодокументирование?

Вот ссылка на книгу о нормализации классов (думаю, мы действительно говорим о классах) http://www.agiledata.org/essays/classNormalization.html

Answer 1

Нормализация имеет математическую основу в логике предикатов и ясную и конкретную цель, чтобы один и тот же фрагмент информации никогда не был представлен дважды в одной модели; цель этой цели состоит в том, чтобы устранить возможность противоречивой информации в модели данных. С помощью математического доказательства можно показать, что, если модель данных обладает определенными специфическими свойствами (то, что она проходит тесты для 1-й нормальной формы (1NF), 2NF, 3NF и т. Д.), Что она свободна от избыточного представления данных, т.е. она нормализована.

У объектной ориентации нет такой базовой математической основы и, действительно, нет ясной и конкретной цели. Это просто дизайнерская идея для введения большего количества абстракции. Принцип DRY, разделение команд-запросов, принцип подстановки Лискова, принцип открытого-закрытого типа, принцип «говорите, не спрашивайте», принцип инверсии зависимостей и другие эвристики для улучшения качества кода (многие из которых применяются к коду в целом, а не только к нему). объектно-ориентированные программы) не являются абсолютными по своей природе; это рекомендации, которые программисты сочли полезными для улучшения понятности, удобства сопровождения и тестируемости своего кода.

С помощью реляционной модели данных вы можете с абсолютной уверенностью сказать, «нормализована» она или нет, потому что она должна пройти ВСЕ тесты на нормальную форму, и они достаточно специфичны. С другой стороны, в случае объектной модели, поскольку цель «понятного, поддерживаемого, проверяемого и т. Д.» Довольно расплывчата, вы не можете с уверенностью сказать, достигли ли вы этой цели. Со многими из эвристики дизайна вы даже не можете точно сказать, следовали ли вы им. Следовали ли вы принципу СУХОЙ, если применяете шаблоны к своему дизайну? Неужели повторное использование шаблона не СУХО? Кроме того, некоторые из этих эвристик или принципов не всегда даже всегда являются хорошим советом. Я стараюсь следовать разделению команд и запросов, но такие полезные вещи, как стек или очередь, нарушают эту концепцию, чтобы дать нам довольно элегантный и полезный результат.

Answer 2

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

(Возможно, я говорю мусор. Я очень устал.)

Answer 3

Интересно.

Вам также может быть интересно посмотреть на Закон Деметры .

Другая вещь, которая может вас заинтересовать - это c2's FearOfAddingClasses , поскольку, возможно, те же рассуждения, которые приводят программистов к денормализации баз данных, также приводят к божественным классам и другим запахам кода. И для нормализации OO, и для DB мы хотим разложить все. Для баз данных это означает больше таблиц, для ОО - больше классов.

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

Объектно-реляционные модели или «персистентные слои», как правило, имеют соотношения 1: 1 между атрибутами объекта и полями базы данных. Итак, мы можем нормализовать? Скажем, у нас есть объект отдела с атрибутами employee1, employee2 ... и т. Д. Очевидно, что это должно быть заменено списком сотрудников. Таким образом, мы можем сказать, что 1NF работает.

Имея это в виду, давайте перейдем прямо к уничтожению и рассмотрим проект базы данных 6NF, хороший пример - Anchor Modeling, (игнорируем соглашение об именах) . Anchor Modeling / 6NF предоставляет сильно разложенные и гибкие схемы базы данных ; как это переводится в ОО «нормализация»?

Якорное моделирование имеет следующие виды отношений:

• Anchors - уникальные идентификаторы объектов.
• Атрибуты, которые переводятся в атрибуты объекта: (Якорь, значение, метаданные).
• Связи - отношения между двумя или более объектами (самими якорями): (Якорь, Якорь ..., метаданные)
• Узлы, приписанные галстукам.

Метаданные атрибута могут быть любыми: кто изменил атрибут, когда, почему и т. Д.

OO перевод выглядит очень гибко:

• Якоря предлагают заполнители без атрибутов, например, прокси, который знает, как работать с композицией атрибутов.
• Атрибуты предлагают классы, представляющие атрибуты и то, к чему они принадлежат. Это предлагает применить повторное использование к тому, как атрибуты ищутся и обрабатываются, например, автоматическая проверка ограничений и т. Д. Из этого у нас есть основа для общей реализации структурных шаблонов в стиле GOF.
• Связи и узлы предлагают классы, представляющие отношения между объектами. Основа для общей реализации шаблонов поведенческого дизайна?

Интересные и желательные свойства Anchor Modeling, которые также пересекаются:

• Все это требует замены наследования композицией (хорошо) в выставленных объектах.
• Атрибуты имеют владельцев, а не владельцев, имеющих атрибуты. Несмотря на то, что это делает поиск атрибутов более сложным, он аккуратно решает некоторые проблемы с наложением имен, так как может быть только один владелец.
• Нет необходимости в NULL. Это приводит к более ясной обработке NULL. Классы атрибутов с пустым регистром могут предоставлять методы для обработки отсутствия определенного атрибута вместо выполнения NULL-проверки везде.
• Метаданные атрибута. Полная историзация и обвинения на уровне атрибутов: «воспроизвести» объекты во времени, посмотреть, что изменилось, когда и почему и т. Д. (При необходимости - метаданные совершенно необязательны)

Вероятно, будет много очень простых классов (что хорошо) и очень декларативный стиль программирования (также хорошо).

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

Answer 4

Возможно, вы берете это с реляционной точки зрения, но я бы сказал, что принципы интерфейсов и наследования соответствуют нормализации в мире ООП.

Например, абстрактный класс Person, содержащий FirstName, LastName, Gender и BirthDate, может использоваться такими классами, как Employee, User, Member и т. Д. допустимый базовый класс, без необходимости повторять определения этих атрибутов в таких подклассах.

Принцип СУХОГО (основной принцип книги Энди Ханта и Дейва Томаса Прагматический программист ) и постоянный акцент объектно-ориентированного программирования на повторное использование также соответствуют предлагаемой эффективности Нормализацией в реляционных базах данных.

Answer 5

Моделирование ролей объектов (не путать с Относительное сопоставление объектов ) - наиболее близкая вещь, которую я знаю к нормализации объектов. Он не имеет такого математического обоснования, как нормализация, но это начало.

Answer 6

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

Обновление: я чуть раньше не писал, что «нам нужно, чтобы Джон Скит включил это». Я отправил свой ответ, а кто меня избил? Вы догадались ...

Answer 7

хороший вопрос, извините, я не могу ответить подробно

Я работаю над нормализацией объектов более 20 лет. Это глубоко, сложно и красиво, и это тема моей второй запланированной книги, Object Mechanics II. ONF = Нормальная форма объекта, вы сначала услышали это здесь! ; -)

так как потенциально скрываемая технология скрывается внутри, я не могу сказать больше, за исключением того, что нормализация данных является действительно легкой частью; -)

ADDENDUM: смена планов - см. https://softwareengineering.stackexchange.com/questions/84598/object-oriented-normalization

Answer 8

Я второй SRP. Открытый закрытый принцип применим также и к «нормализации», хотя я мог бы расширить значение этого слова, так как должна быть возможность расширять систему, добавляя новые реализации, не изменяя существующий код. объект или об OCP

Answer 9

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

Является ли это сильной или слабой стороной объектно-ориентированного дизайна - вопрос интерпретации.

Answer 10

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

(Мои объекты обычно заканчиваются в 3NF или в некотором приближении к нему. Я все больше отношусь к этому как к руководству и, как я уже сказал, "не обучен".)

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

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