n階層アーキテクチャはカプセル化のOOの概念を破りますか

Question

私は、プレゼンテーション層、ビジネス層、DALおよびビジネスオブジェクト層を持つn層アプリケーションを持っています。オブジェクトとオブジェクトに書かれた操作とを分離することは、オブジェクト指向のカプセル化の概念を破る。

Answer 1

いいえ「カプセル化」とは、クラスの実装の詳細がクラスのインターフェイス（メッセージまたはメソッド）の背後に隠れていることを意味します。

実際には、OOの原則とParnasの法則から直接n層アーキテクチャを導き出すことができます。モジュールは、変更される可能性のあるものをカプセル化する必要があります。プレゼンテーション層は、「可視」インターフェースの作成の詳細をカプセル化します。中間層はビジネス自体のモデルです。永続データストアへのアクセスの詳細をバックエンドで処理します。

Answer 2

2つは同じではありません。アーキテクチャは、モジュール（クラスのグループ）を参照しています。カプセル化とは、クラスの内部動作を隠すことを指します。システムを十分に設計すれば、両方を持つことができます。

責任の分離を明確に定義することに注意が必要な場合があります。各モジュール/レイヤが何であるかについて明確で、各クラスが何をしているのか（そしてクラスの各メソッドが何をしているのか）について明確である限り、良いデザインを持つことができます。

私はちょうどここに推測していますが、あなたはモジュールへのインターフェイスを設計するときにfacade design patternに興味があるかもしれません。

以下のコメントに関しては、論理は明らかに従業員クラス自体にあるはずです。私はビジネスオブジェクトのための別の層を持つことに論理を疑問視します。実際のオブジェクトや概念をモデル化するため、「従業員」のようなクラスを定義することは、しばしば誘惑になります。しかし、クラスを定義する動機は、「実世界のオブジェクトをモデリングする」べきではありません。

モジュールの目的を定義する必要があります（なぜビジネスロジックレイヤーを持っていますか？すべてのビジネスロジックが含まれています）。 「従業員」クラスがビジネスロジックを計算する必要があるクラスである場合、ビジネスロジッククラスに入る必要があります。そうでなければ、それはあなたのビジネスオブジェクトクラスに入ります（それが何であれ）。 2つの異なることを行う必要があり、2つのレイヤーに収まる必要がある場合、2つのクラスに分けることを検討してください。オブジェクトは実際のものをモデル化する必要はありません。 Robert C Martinは、クラスの境界が目的の境界になるようにクラスを定義することを提案しています。

Answer 3

これは本当に素晴らしいポイントです！

場合によっては、1つの操作を複数のオブジェクトに分割するとカプセル化に悪影響を及ぼします。実際、これは私が多くのWebアーキテクチャで見た大きな問題だと思います。このようなデータベースにクエリを送信するためのオブジェクトのように一方、特定の物事が分解するのに有用である

、など

私が作られている引数は、多くの場合、そこにあると思い、より良いへWebページを「カプセル化」することで、より多くの機能が単一のオブジェクト以下のオブジェクトに含まれます。したがって、膨大な数のクラスに論理を分散するのではなく、より「ページ中心の」アプローチです。

これは、私たちが設計した各システム、つまりどのくらい抽象化しているのか、常に尋ねなければならない重要な問題だと思いますか？どのくらい具体的に保つか？どのようにに効果的をクラスに分解してください。

Answer 4

がthis articleから取られ、この例を見てみましょう：

public class Position 
{ 
    public double distance(Position position) 
    { 
    // calculate and return distance... 
    } 

    public double heading(Position position) 
    { 
    // calculate and return heading... 
    } 

    public double latitude; 
    public double longitude; 
} 

そのデータに対して実行データや操作が同梱されているので、これは、カプセル化の良い例である同記事によります。ここでのカプセル化はデータの隠蔽や保護を保証しないことに注意してください。

対照的に、Code Complete（第2版、第6.2節、Good Encapsulation）のSteve McConnellは、メンバーデータが公開されているため、カプセル化が壊れていると主張します。

データオブジェクトとそれらを操作するオブジェクトが分離されているがパブリックフィールドを持たない場合は、最初の定義に従ってカプセル化が破られますが、必ずしも後続のケースでは必要ありません。だから我々は2つの対照的な見解を持っている。もう1人は、データ隠蔽はカプセル化の一部ではなく、もう1人は、データ隠蔽はカプセル化の重要な部分であると述べています。

データの隠蔽は、情報の隠蔽の一部と見ることができます。これは、複雑な設計上の意思決定と変化の原因を隠すべきであるという原則です。一般的なコンセンサスは、カプセル化がデータ隠蔽を含む情報隠蔽の現れと見なされるように思われる。

あるいは、Wikipediaがそれを置くように：

用語のカプセル化は、しばしば互換情報 隠れて を使用しています。しかし、両方の間で の区別に同意するわけではありません。 を原則とする情報隠蔽とカプセル化 が技術と考えられます。ソフトウェアモジュール は、 の情報をモジュールにカプセル化することによって情報を隠すか、またはインタフェースを提示する他の構成要素に隠蔽する。

しかし...この段落を次の参照は、私が最初の例を取っ​​ているから、同じ記事で、そうでもウィキペディアはここに物事を混合することです。また、ここでは「区別」という言葉の使用が間違っているようです。

最後にこれを言わなければならないのは少し残念ですが、カプセル化と情報隠蔽の用語は過負荷です。すべてがソースに依存しています。あなたの場合、私はカプセル化の定義を「抽象化の背後にある実装の詳細を隠す」ことに固執します。したがって、カプセル化を必ずしも破っているとは限りません。