データベースプログラミングには、保存するデータに対して行う「正規化」と呼ばれる手法があります。

誰もがこの概念をオブジェクト設計に適用しようとしましたか？どのようにしていた？どのようにうまくいきましたか？

編集：拡張/明確化するために、データベースの正規化は冗長性を減らすための一連の原則以上のものです。実際にあなたが通過するステップと段階があり、あなたがどの段階にいるかを示す少なくとも中程度に客観的な尺度があります。オブジェクト設計には独自の原則があり、匂いの概念がありますが、あなたに伝える同様の何かをする方法はありますかあなたはXX-form0,1,2 ...などにいて、次の「正規化された」レベルに移動する方法ですか？

データベースの正規化を推進する根本的な緊張のいくつかはオブジェクト指向システムには存在しませんが、それらのいくつかは存在します。これらにより、少なくともOOシステムがリレーショナルデータベースに類似している限り、OO設計パターンと原則がいくつかの点で正規化に類似しています。例えば：

• 単一責任の原則
• 関心事の分離
• 一度だけ、別名DRY

言い換えれば、データベース正規化手法をOOPに適用しようとした人はいますか？いいえ。OOPには、リレーショナルデータベースの正規化が解決する共通の問題に対するソリューションが既にあるためです。

はい、はい

私は長い間、このトピックについて黙っていました。話す時間です。

• 誰もがこの概念をオブジェクト設計に適用しようとしましたか？

はい。私は20年以上にわたってオブジェクトの正規化（およびそのための基礎となるオブジェクト指向理論）の形式化に取り組んできました。

• どのようにしていた？

少なくとも理論的には、データとコードは交換可能であることを認識することで。これは、正規化の原則と関係演算がコードだけでなくデータにも適用できることを意味します。

• どのようにうまくいきましたか？

これまでのところかなりうまくいきました。得られた洞察は、私の設計、分析、リファクタリング能力の「秘密兵器」であったと信じています。

私は最終的には自分で研究を終了し、暗黙のツールを作成する時間があると考えたため、これについては何も公表していません。

しかし、私の人生で他のすべてがより重要で、より楽しく、そして/またはより有益であるということで、私は自分で研究を完了する時間がないだろうという結論に達しました。今まで。また、単独で作業を完了するために必要なCSの理論的基礎がないという大きな可能性もあります。

私は地元の大学で、博士課程の候補者を1人か2人、彼らがその原因を取りたいかどうかを尋ねましたが、残念ながら地元の大学はプログラミング言語の意味論の適切な基礎を教えていません。

この分野でいくつかの興味深い研究がありましたが、そのすべて-私が知っている-それはマークを下回っています。正規化はリレーショナルバックグラウンドに由来するため、オブジェクト指向モデルには適用されないと誤って仮定するか、オブジェクトによって定義されたデータにのみ正規化が適用されると仮定します。しかし、いくつかの非常に興味深いニアミスプロジェクトがあります...

コードに正規化を適用すると、本当に興味深いことが起こります。これがすべてのリファクタリングの基礎であると私は主張します。

だから今、私は、DCでのDevDays 2011で講演するよう頼むことによって、言葉を広めることと、このようなものに興奮しているコミュニティがあるかどうかを調べることが最善だと考えています。

ここにご紹介します：正規化とは、何かを最小化して非冗長にするプロセスです。したがって、オブジェクト指向プログラミングの自分自身を繰り返さない（DRY）原則は、正規化の目標を明確に表しています。よく知られているオブジェクト指向の設計/プログラミング/リファクタリングの原則はすべて、オブジェクトの正規化の論理的な結果であることを示すことができると思います。リファクタリングだけでなく、Object Normal Form（ONF）のシステムで実行できる興味深いこともあると思います。

これは、Rein Henrichsの優れた答えに対するコメントとして始まりましたが、長すぎました...

正規化はリレーショナルデータに適用されます。重複を避けるために使用されます。各データは1か所にのみ保存されるため、データの整合性を確保しやすくなります。正規化された形式の違反を見つけて修正することにより、データベースを正規化します。

オブジェクト指向プログラミングは、データの操作に適用されます。データを操作する方法をグループ化することを目的としています。同様の手法をクラスに適用して、おそらく操作が操作または依存するデータを調べることにより、重複するメソッドを排除できます。たとえば、OOパースペクティブの1NFには、クラス内で重複する操作はありません。3NFは、一般的に使用されるコードがスーパークラスにある適切な継承構造に対応する場合があります。依存関係の注入を行う場所を見つけることができると確信しています。優れた設計原則とリファクタリングの違反を見つけることで、（通常のフォームのようなものはまだ発見されていませんが）より良い設計に到達します。

どちらの世界でも良いデザインに到達するためのアルゴリズム的な方法は実際にはありません。Rein Hendrichsが指摘しているように、潜在的な問題（別名コードの匂い）を特定できる多くの原則があります。デザインパターンとベストプラクティスは、人々がそれらに対処しようとした方法の一部です。テスト駆動開発では、外部にあるコードを実行することで、それらを早期に見つけようとします。データベース開発の場合と同じように、最良のソリューションは経験と分析によって見つかります。

正規化に似たビジネスモデルオブジェクトを設計する非常に優れたアプローチは、カラーのUMLモデリングです。

ビジネスモデルオブジェクトを抽象化するのに役立つのは、Peter Coadが発見した設計戦略です。

残念ながら、本-Java Modeling In Color With UML：Enterprise Components and Process-は完売しており、使用できるもののみを購入できます。

この手法については、インターネット上でいくつかの記事があります。

リレーショナルデザインに精通している場合は、ColorのUMLモデリングが役立ちます。

• ピーター・コードの「色のモデリング」-スティーブン・R・パーマーによるノート

クラス図の作成中にコードでORM java注釈を使用するように調査しましたか？モデリング段階が終了すると、Hibernateはデータベースを生成します。この例では、ダイアグラムはコードのビューアーのみです。

オブジェクト参照またはポインターは外部キーに似ています。これは、私がこれについて考えたいと思うほど深いです。:)

実際、私はもっと深く考えます。データの複製を0にしてオブジェクトをモデリングし、オブジェクトを「照会」し、それらに基づいてセットベースの更新を実行できる場合、切断は発生しません。実際、オブジェクトコンシューマライブラリを作成することでこれを行うことができます。マイクロソフトはすでにこれに取り組んでいますが、「クエリライブラリ」よりも、セットベースのLINQ構文をC＃の一部にする方向に進みました。