Design patterns n层架构是否打破了封装的OO概念

我有一个具有表示层、业务层、DAL和业务对象层的n层应用程序。分离对象和写在对象上的操作打破了面向对象的封装概念。

这两者不一样。体系结构更多的是指模块（类组）。封装是指隐藏类的内部工作。如果你的系统设计得足够好，你可以同时拥有这两个

您可能需要注意的是明确定义责任分离。只要您清楚每个模块/层的用途，并且明确每个类的作用（以及类的每个方法的作用），那么您就应该能够进行良好的设计

我只是在这里推测一下，但您可能对设计模块接口时的操作感兴趣

关于您在下面的评论，逻辑肯定应该在employee类本身中。我会质疑为业务对象提供一个单独的层的逻辑。定义像“Employee”这样的类通常是一种诱惑，因为它们为真实世界的对象或概念建模。然而，您定义类的动机不应该是“为真实世界的对象建模”

---

您应该定义模块的用途（为什么有业务逻辑层？以包含所有业务逻辑），然后将您需要的内容放在其中。如果“Employee”类是需要计算业务逻辑的类，那么它应该放在业务逻辑类中。如果没有，那么它应该放在您的业务对象类中（不管是什么）。如果它需要做两个不同的事情，因此可以适应两个层次，那么考虑把它分成两个类——记住你的对象不需要对现实世界的事物建模。Robert C Martin建议定义你的类，使类的边界就是目的的边界。

这是一个非常好的观点

在某些情况下，我同意将单个操作分解为多个对象确实会对封装产生不利影响。事实上，我认为这是我在许多web架构中看到的一个大问题

另一方面，某些东西对分解很有用，例如向数据库发送查询的对象等

我认为，在许多情况下，有一个论点是为了更好地“封装”网页，以便更多的功能包含在单个对象或更少的对象中。因此，更“以页面为中心”的方法，而不是将逻辑分散在大量的类中

我认为这是一个至关重要的问题，对于我们设计的每个系统，我们总是要问自己——要抽象多少？具体多少钱？如何有效地将系统分解成类。

< P>不。考虑“封装”意味着：类的实现细节隐藏在类的接口（消息或方法）后面。

---

事实上，您可以直接从OO原则和Parnas定律推导出n层体系结构：模块应该封装可能发生的变化。表示层封装了创建“可见”界面的细节；中间层是业务本身的模型；后端显示访问持久数据存储的详细信息。

以以下示例为例：

根据同一篇文章，这是一个很好的封装示例，因为对该数据执行的数据和操作是捆绑的。注意，这里的封装不能保证数据隐藏或保护

相反，Steve McConnell在《代码完成》（第二版，第6.2节，良好的封装）中会争辩说封装被破坏了，因为成员数据是公开的

在您的情况下，如果您的数据对象和操作它们的对象是分离的，但没有公共字段，那么根据第一种定义，封装被破坏，但在第二种情况下不一定如此。因此，我们有两种截然不同的观点。一个说数据隐藏不是封装的一部分，另一个说数据隐藏是封装的重要部分

数据隐藏可以看作是信息隐藏的一部分，信息隐藏的原则是，您应该隐藏复杂的设计决策和变更源。普遍的共识似乎是，封装被视为信息隐藏（包括数据隐藏）的一种表现形式

或者，正如它所说：

通常使用术语封装 与信息交换 躲藏。并非所有人都同意这一点 二者之间的区别； 人们可能认为信息隐藏是 是原理和封装 是技术。软件模块 通过封装 将信息导入模块或其他模块 表示接口的构造

但是。。。这一段后面的引用与我第一个例子所引用的文章是同一篇文章，所以就连维基百科在这里也把事情搞混了。此外，这里使用“区别”一词似乎是错误的

---

最后不得不这么说有点站不住脚，但是封装和信息隐藏的术语太多了，所以这一切都取决于源代码。在您的例子中，我坚持将封装定义为“在抽象背后隐藏实现细节”。因此，您不一定要破坏封装。

如果在业务对象层中定义了employee类，并且处理employee的逻辑在业务层中，那么很明显，我在这里将数据和逻辑分为两个不同的类。但是封装说数据和逻辑在一个类中？封装在哪里说的？使用该理论，应用程序中的所有内容都需要封装在once类中，因为它们都以某种方式相关。

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;
}