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

Ответ 1

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

Ориентация объекта не имеет такой базовой математической основы и, действительно, не имеет четкой и конкретной цели. Это просто дизайнерская идея для введения большей абстракции. Принцип DRY, разделение Command-Query, принцип замещения Liskov, принцип открытого закрывания, Tell-Don't-Ask, принцип инверсии зависимостей и другие эвристики для улучшения качества кода (многие из которых применимы к коду вообще, а не только к объектно-ориентированные программы) не являются абсолютными по своей природе; они являются рекомендациями, которые программисты нашли полезными в улучшении понятности, ремонтопригодности и проверки их кода.

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

Ответ 2

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

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

Ответ 3

Интересно.

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

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

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

Объектные реляционные модели или "уровни устойчивости" обычно имеют сопоставления 1 к 1 между атрибутами объекта и полями базы данных. Итак, можем ли мы нормализовать? Скажем, у нас есть объект отдела с атрибутами employee1, employee2... и т.д. Очевидно, что его следует заменить на список сотрудников. Таким образом, мы можем сказать, что работает 1NF.

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

Anchor Modeling имеет такие отношения:

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

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

Перевод OO выглядит чрезвычайно гибким:

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

Интересные и желательные свойства Anchor Modeling, которые также транслируются, заключаются в следующем:

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

Object Role Modeling (не следует путать с Object Relational Отображение) - это самая близкая вещь, которую я знаю о нормализации объектов. У него нет математического фундамента, как нормализация, но это начало.

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

Я второй SRP. Принцип открытого закрытия применяется также к "нормализации", хотя я могу растянуть смысл слова, поскольку его можно расширить, добавив новые реализации без изменения существующего кода. objectmentor об OCP

Ответ 10

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

Я работаю над нормализацией объектов в течение более 20 лет. Это глубокое, сложное и красивое, и это предмет моей второй запланированной книги "Механика объектов". ONF = Object Normal Form, вы сначала это услышали!; -)

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

ДОБАВЛЕНИЕ: смена планов - см. https://softwareengineering.stackexchange.com/info/84598/object-oriented-normalization