В программировании баз данных есть метод под названием «нормализация», который вы делаете с данными, которые хотите сохранить.

Кто-нибудь пытался применить эту концепцию к объектному дизайну? Как ты? Как это получилось?

Редактировать: чтобы расширить / уточнить, нормализация базы данных - это больше, чем набор принципов для уменьшения избыточности. На самом деле есть этапы и этапы, которые вы проходите, и, по крайней мере, умеренно объективные измерения, которые говорят вам, на каком этапе вы находитесь. У дизайна объекта есть свои собственные принципы, и есть понятие обоняния, но есть ли способ сделать что-то подобное, что бы сказать вам что вы в XX-форме0,1,2 ... и т.д. ... и методы для перехода на следующий самый "нормализованный" уровень?

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

• Принцип единой ответственности
• Разделение проблем
• Один раз и только один раз , он же СУХОЙ

Другими словами, кто-нибудь пытался применить методы нормализации базы данных к ООП? Нет, потому что ООП уже имеет решения для общих проблем, которые нормализация решает для реляционных баз данных.

Да да у меня есть

Я долго молчал на эту тему; пришло время высказаться.

• Кто-нибудь пытался применить эту концепцию к объектному дизайну?

Да. Я работаю над формализацией объектной нормализации (и, следовательно, основополагающей объектно-ориентированной теории) более 20 лет.

• Как ты?

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

• Как это получилось?

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

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

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

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

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

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

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

Вот краткий обзор: нормализация - это процесс создания чего-то минимального и не лишнего. Следовательно, принцип «не повторяйся» (СУХОЙ) объектно-ориентированного программирования является четким проявлением целей нормализации. Я верю, что могу показать, что все известные принципы объектно-ориентированного проектирования / программирования / рефакторинга являются логическим следствием нормализации объекта. Я думаю, что я также могу показать, что есть более интересные вещи, которые можно сделать с системами в Object Normal Form (ONF), чем просто рефакторинг.

Это началось как комментарий к превосходному ответу Рейн Хенрикс , но получил слишком долго ...

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

Объектно-ориентированное программирование применяется к операциям с данными. Он предназначен для объединения способов манипулирования данными вместе. Вы можете применить аналогичные методы к классам, чтобы исключить дублирование методов, возможно, посмотрев, с какими данными эта операция манипулирует или зависит. Например, 1NF в перспективе OO не будет иметь никаких дублирующих операций внутри класса. 3NF может соответствовать хорошей структуре наследования, в которой обычно используемый код находится в суперклассе. Я уверен, что вы могли бы найти место для внедрения инъекций зависимости. Вы достигаете лучшего дизайна (хотя ничего подобного нормальным формам еще не обнаружено), обнаруживая нарушения принципов хорошего дизайна и рефакторинга.

На самом деле нет никаких алгоритмических методов для достижения хорошего дизайна ни в одном мире. Как указывает Рейн Хендрикс, существует много принципов, которые могут выявить потенциальные проблемы (иначе называемые запахами кода). Шаблоны проектирования и лучшие практики - вот несколько способов, которыми люди пытались их решить. Разработка, основанная на тестировании, пытается найти их на раннем этапе, используя код, как это будет внешне. Как и в разработке баз данных, лучшее решение найдено с опытом и анализом.

Очень хороший подход к проектированию объектов бизнес-модели, который похож на нормализацию, - UML Modeling in Color .

Питер Коад разработал стратегию проектирования, которая помогает абстрагировать объекты бизнес-модели.

К сожалению, книга « Цветовое моделирование Java с UML: корпоративные компоненты и процесс» распродана, и вы можете купить только использованные.

В интернете есть пара статей об этой технике.

Если вы знакомы с реляционным дизайном, вы найдете UML Modeling in Color полезным для вас:

• «Моделирование в цвете» Питера Коада - заметки Стивена Р. Палмера

Вы пытались использовать Java-аннотации ORM в своем коде при создании диаграммы классов? Hibernate сгенерирует базу данных после завершения этапа моделирования. Диаграмма в этом примере является только средством просмотра кода.

Ссылки на объекты или указатели похожи на внешние ключи. Это так глубоко, как я готов думать об этом. :)

На самом деле я буду думать глубже. Если вы смоделируете свои объекты с дублированием данных 0 и сможете «запросить» ваши объекты и выполнить для них обновления на основе набора, отсоединения не будет. Фактически, вы МОЖЕТЕ сделать это, создав библиотеку объектных потребителей. Microsoft уже думала об этом, но пошла в направлении включения синтаксиса LINQ на основе множеств в C # вместо «библиотеки запросов».