寻找有关使用适配器模式的反馈答案

【问题标题】：Looking for feedback on a use of the Adapter pattern寻找有关使用适配器模式的反馈
【发布时间】：2009-06-28 02:35:15
【问题描述】：

在一个工作项目中，我们的领域模型中有一个特定的值类型类，其中包含大量的属性...

public class BigValueType {
    private Foo foo;
    private Bar bar;
    private Baz baz;

    //...
}

我们已经意识到，我们希望将其“集中”到许多不同的、更专业的类中，这些类仅具有此类属性的某些子集。我认为我们希望对这些数据有不同的“视图”。

public class SpecializationA {
    private Foo foo;
    private Baz baz;
    //...
}

public class SpecializationB {
    private Bar bar;
    private Baz baz;
    //...
}

private class SpecializationC {
    private Foo foo;
    private Bar bar;
    //...
}

但是，此域模型旨在比较通用，而不是特定于该项目。在未来的项目中，它将添加特定于项目的扩展，但公共域模型将与这些扩展分开。如果我们现在简单地定义一堆类，很可能其他使用领域模型的项目以后只需要编写自己的稍微不同的类。（我们无法轻易预测这些数据的哪些视图会有用。）

我认为我们应该做的是为这个大类编写特定于项目的适配器，以呈现数据的不同视图。这样，该域的未来用户不必接触“通用”域模型中的任何内容来定义此信息的新视图。

public class AdapterA {
    private BigValueType wrapped;
    //...

    public ViewA(BigValueType wrapped) {
        //...
    }

    public Foo getFoo() {
        return wrapped.getFoo();
    }

    //...
}

这对我来说比普通继承更有意义，因为我们的顶级类/接口中几乎没有任何内容。

对此方法有何反馈？

【问题讨论】：

标签： java design-patterns inheritance domain-driven-design adapter

【解决方案1】：

首先，了解您想要解决的问题很重要。拥有一个具有大量属性的类并不一定是坏事，如果您只想进行重构以符合“好的”设计原则，我会重新考虑这个决定。

话虽如此，这是 SOA 世界中相当普遍的设计。您有一个大型服务，它接受具有相当多属性的复杂消息作为请求。然后，该服务被“调整”以迎合具有不同需求的客户。所以，你的设计应该运作良好。当然，前提是您已经知道所有可能的“视图”，否则您将不得不为新客户端编写新的适配器。

这种“适应”可以在两个级别执行 - 用户界面级别（本质上是您的设计 - 调整类）或较低级别，例如在数据库级别，这反过来会修改您的主课也是。这取决于您的应用程序、框架的用户等等。

另一种需要考虑的方法也可以是 REST 方法 - 公开数据（Foo、Baz 等），尽管来自主类，并让客户端使用主类自行处理数据本质上为这些数据提供 CRUD 功能。那么你的类就更像一个没有真正业务逻辑的结构。

这三种方法中的任何一种都可以，恕我直言。

【讨论】：

【解决方案2】：

嗯.. 对我来说似乎很好。我认为您使用组合的解决方案比使用继承要好得多，它会在很大程度上影响您的模型并生成大量低内聚类。

【讨论】：

【解决方案3】：

我发现跨多个项目共享代码的目标比听起来更难。至少，很难做到正确！这正是您讨论的原因，不知道您在某些新项目中可能需要哪些功能。问题是适配器问题不会为您解决这个问题（如果底层对象不支持所需的功能集，即）。

我建议您将interfaces 用于您的单独项目，但您单独编写实现代码。如果您发现自己完全编写了 3 次相同的代码，那么将其拉出到一个公共库中。尽量让你的库保持轻量级。

当您发现需要添加功能（可能冲突）并且影响大量应用程序的复杂性时，以后管理多个依赖项可能会很昂贵。

【讨论】：