n層體系結構是否破壞OO概念封裝

Question

我有一個n層應用程序，包括表示層，業務層，DAL和業務對象層。分離對象和寫在對象上的操作破壞了面向對象的封裝概念。

Answer 1

否。考慮「封裝」意味着什麼：類的實現細節隱藏在類的接口（消息或方法）之後。實際上，你可以直接從OO原則和Parnas定律推導出n層體系結構：一個模塊應該封裝可能改變的內容。表示層封裝了創建「可見」界面的細節;中間層次是業務本身的模型;以及後端訪問持久數據存儲的細節。

Answer 2

兩者不一樣。體系結構更多地指代模塊（類的組）。封裝是指隱藏類的內部運作。如果您設計的系統足夠好，您可以擁有兩者。

你可能需要小心的是明確界定責任分離。只要你清楚每個模塊/層的用途，以及每個類所做的具體內容（以及每個類的每種方法的作用），那麼你應該能夠有一個好的設計。

我只是在這裏猜測，但您在設計模塊接口時可能對facade design pattern感興趣。

關於您的評論如下，邏輯肯定應該在員工類本身。我會質疑爲業務對象設置單獨的層的邏輯。定義像「員工」這樣的類往往是一種誘惑，因爲他們模擬真實世界的對象或概念。然而，你定義一個類的動機不應該是「模擬真實世界的對象」。

您應該定義模塊的用途（爲什麼您有一個業務邏輯層？要包含所有的業務邏輯），然後將所需的內容放在那裏。如果「Employee」類是需要計算業務邏輯的類，那麼它應該放在業務邏輯類中。如果沒有，那麼它應該在你的業務對象類（無論是爲了什麼）。如果它需要做兩件不同的事情，因此可能適合兩層，那麼考慮將它分成兩類 - 記住你的對象不需要模擬真實世界的事物。羅伯特C馬丁建議定義你的階級，使得階級的界限是目的的界限。

Answer 3

這真是一個非常棒的AP！

在某些情況下，我同意將單個操作分解爲多個對象的確會對封裝產生不利影響。事實上，我認爲這是我在許多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（第二版，第6.2節，良好封裝）將會爭論封裝被破壞，因爲會員數據被暴露。

在你的情況下，如果你的數據對象和操縱它們的對象是分開的但沒有公共字段，那麼根據第一個定義破壞封裝，但不一定在第二種情況。所以我們有兩種截然不同的觀點。一個人說數據隱藏不是封裝的一部分，另一個來源說數據隱藏是封裝的重要組成部分。

數據隱藏可以被看作是信息隱藏的一部分，這是隱藏複雜設計決策和變化源的原則。普遍的共識似乎是封裝被看作是信息隱藏的一種表現，包括數據隱藏。

或者，如Wikipedia所言：

術語封裝經常被用來 互換信息 隱藏。儘管並非所有人都同意 之間的區別; 人們可能會認爲隱藏信息是 是原理，封裝 是技術。軟件模塊 通過將信息封裝到提供接口的模塊或其他 結構中來隱藏信息。

但是......本段後面的參考文獻是我從第一個例子中得到的同一篇文章，所以即使是維基百科在這裏混合了一些東西。另外，在這裏使用「區分」這個詞似乎是錯誤的。

最後不得不說這個有點蹩腳，但封裝和信息隱藏的術語是超負荷的，所以這一切都取決於源。在你的情況下，我會堅持封裝的定義爲「隱藏實現細節的抽象背後」。因此，你不一定要打破封裝。