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

Хтось намагався застосувати цю концепцію до дизайну об'єктів? Як ви? Як це вийшло?

Редагування: Щоб розширити / уточнити, нормалізація бази даних - це більше, ніж набір принципів для зменшення надмірності. Насправді є етапи та етапи, якими ви проходите, і, принаймні, помірно об'єктивні заходи, які говорять вам, на якому етапі ви перебуваєте. Дизайн об’єкта має свої принципи, і є концепція запаху, але чи є спосіб зробити щось подібне, яке б вам сказало що ви знаходитесь у XX-form0,1,2 ... і т. д ... і методи переходу до наступного найбільш "нормалізованого" рівня?

Хоча деякі основні напруги, які зумовлюють нормалізацію бази даних, відсутні в системі ОО, деякі з них є. Вони породили схеми та принципи проектування ОО, які певним чином аналогічні нормалізації, принаймні тому, що системи OO є аналогами реляційних баз даних. Наприклад:

• Принцип єдиної відповідальності
• Розмежування проблем
• Раз і тільки один раз , він же СУХИЙ

Іншими словами, хтось намагався застосувати методи нормалізації бази даних до ООП? Ні, оскільки OOP вже має рішення для спільних проблем, які нормалізація вирішує для реляційних баз даних.

Так, так, маю

Я довго мовчав на цю тему; пора говорити.

• Хтось намагався застосувати цю концепцію до дизайну об'єктів?

Так. Я працюю над формалізацією нормалізації об'єктів (і, отже, основної об'єктно-орієнтованої теорії) більше 20 років.

• Як ви?

Зрозумівши, що дані та код є взаємозамінними, принаймні теоретично. Це означає, що принципи нормалізації та відносних операцій можуть застосовуватися як до коду, так і до даних.

• Як це вийшло?

Поки що це спрацювало досить добре - я вважаю, що отримані відомості були "таємною зброєю" моїх здібностей проектування, аналізу та реконструкції.

Я до цього нічого публічно не казав, тому що вважав, що врешті-решт я встигну закінчити дослідження - і виготовити інструменти, що маються на увазі - сам.

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

Я поцікавився в місцевому університеті щодо спонсорування кандидата або двох кандидатів наук, чи хочуть вони взятися за справу, але, на жаль, наш місцевий університет не викладає належної основи в семантиці мови програмування.

У цій галузі було проведено декілька цікавих досліджень, але все це - про що я знаю - не вийшло. Або неправильно передбачається, що оскільки нормалізація виходить із реляційного фону, вона не застосовується до об'єктно-орієнтованих моделей, або передбачається, що нормалізація стосується лише даних, визначених об'єктами. Однак є декілька дуже цікавих проектів, які є майже міс ...

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

Тож зараз я думаю, що найкраще зробити - це зрозуміти слово, можливо, попросивши виступити на DevDays 2011 в DC і дізнатись, чи є така громада, яка хвилюється цим матеріалом, як і я.

Ось підлий погляд: Нормалізація - це процес створення чогось мінімального та непотрібного. Тому принцип повторення себе (DRY) об'єктно-орієнтованого програмування є чітким проявом цілей нормалізації. Я вважаю, що можу показати, що всі відомі об'єктно-орієнтовані принципи проектування / програмування / рефакторингу є логічним наслідком нормалізації об'єкта. Я думаю, що я можу також показати, що є більш цікаві речі, які можна зробити із системами в Object Normal Form (ONF), ніж просто рефакторинг.

Це почалося як коментар до відмінної відповіді Рейна Генріха , але отримав занадто довго ...

Нормалізація застосовується до реляційних даних. Він використовується для уникнення дублювання, що полегшує забезпечення цілісності даних, оскільки кожна дата зберігається лише в одному місці. Ви нормалізуєте базу даних, виявляючи порушення нормалізованої форми та виправляючи їх.

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

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

Дуже хороший підхід до проектування об'єктів бізнес-моделі, подібний до нормалізації, - це UML-моделювання в кольорі .

Це стратегія дизайну, знайдена Пітером Коадом, яка допомагає абстрагувати об'єкти бізнес-моделі.

На жаль, книга - моделювання Java в кольорі за допомогою UML: Enterprise Components and Process - розпродана, і ви можете придбати лише використані.

В Інтернеті є кілька статей про цю техніку.

Якщо ви знайомі з реляційним дизайном, ви знайдете UML-моделювання в кольорі корисним для наведення:

• Пітер Куд «Моделювання кольором» - замітки Стівена Р. Палмера

Ви досліджували використання анотацій Java ORM у своєму коді під час створення діаграми класів? Hibernate створить базу даних після завершення етапу моделювання. Діаграма є в цьому прикладі лише переглядачем коду.

Посилання на об'єкти або вказівники схожі на зовнішні ключі. Це так глибоко, як я готовий подумати над цим. :)

Насправді я подумаю глибше. Якщо ви змоделюєте свої об'єкти з дублюванням даних 0 і зможете "запитувати" ваші об'єкти та виконувати встановлені на них оновлення, відключення не буде. Насправді ви МОЖЕТЕ це зробити, створивши об’єктову бібліотеку споживачів. Майкрософт вже не зважав на це, але пішов у напрямку, щоб зробити синтаксис LINQ на основі набору частиною C # над "бібліотекою запитів".