Question

我遇到了一些遗留代码，它引起了我作为面向对象程序员的所有麻烦。

以下是经常使用的模式： 一个接口有两个实现，一个实现调用另一个实现的方法。

现在，我认为它应该被重构，以便实现不了解彼此。这很简单如何做到这一点。我无法弄清楚的是什么 - ＆amp;希望优秀的SO人能帮助我 - 是为什么。

我可以看到理论上的原因 - 它是一种可怕的面向对象设计。但是我在这里扮演魔鬼的拥护者并且问 - 两个实现彼此知识的实际缺点是什么。为什么要时间＆amp;花钱来摆脱这种（在我看来）反模式？

任何关于此的信息或链接都将受到赞赏。

Answer 1

我可以看到理论上的原因 - 这是一种可怕的面向对象设计。

为什么呢？这听起来完全合理。

例如，假设我想装饰每次通话 - 例如添加调用频率的统计信息，或添加一些授权检查等。将该装饰与真实实现分开是有意义的，只需委托：

public class DecoratedFoo : IFoo
{
    private readonly IFoo original;

    public DecoratedFoo(IFoo original)
    {
        this.original = original;
    } 

    public string Bar() // Defined in IFoo
    {
        // Update statistics here, or whatever
        return original.Bar();
    }
}

为什么你认为关注点的分离是“非常面向对象的设计”？即使装饰类知道IFoo的特定实现并调用不属于IFoo本身的成员以便提高效率，它也不会对我来说似乎特别可怕。它只是一个知道另一个类的类，它们碰巧实现了相同的接口。它们比上面只知道IFoo的例子更紧密耦合，但它仍然不是“可怕”。

Answer 2

interface1的implementation1知道或者与interface1的implementation2交互没有任何问题。

我认为您刚刚发现了代理模式的预期或非预期实现 http://en.wikipedia.org/wiki/Proxy_pattern

希望这有帮助:)

Answer 3

第一个实现调用的“其他实现”的方法是我称之为库函数的方法。把它放在一个单独的模块/文件/项目/中（取决于你的语言/ dev env）并让两个实现都包含它并从那里使用它。

包含公共代码的某些接口的两个实现绝对没有任何问题，但当然公共代码应该与每个实现分开，以便您可以加载到程序中而无需加载另一个。

Answer 4

我对此的看法是

假设你在适当的时候退出一个实现并且你已经单独保存，那么另一个没有变化，你不需要测试它。如果没有分离，您需要花时间分离和测试其他实现。
单一责任总是更加清晰。

接口实现应该是独立的吗？

4 个答案: