小谈子对象中接口的设计原则

今天和同事在讨论接口的设计原则的时候，总结了一个原则点。虽然简单，也拿出来和大家一起分享。

问题

对象在实现接口的同时，由于需要提供访问子接口的服务。最正常的设计可能是下面的。

但是，如果是另外一个情况呢？看看下面的组合方式吧：

小析

事情变得有点有趣了。往往就是这样，只有一个的时候，没有人会怀疑。只有出现多个的时候，争吵才开始了。所谓一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。要我看来，一个和尚是多么的孤独？三个和尚虽然没水喝，可是有得吵闹，岂不是正得设计的乐趣？

初步看起来，这两种设计中，第二种有着明显的不合理。因为这样，层次就变得混乱。而且父对象若是要越过子接口，访问一些实现上的细节，那么就更加麻烦了！

前一段时间，我花很大时间去寻找方法，来通过接口指针返回对象指针(Delphi)，现在想来，这个技术刚好是第二种设计的技术补充啊。反过来，我却忽略了设计上的原则。第二种方式既然存在，那么它是不是也有存在的理由。

那么，什么时候适合第一种方式，什么时候适合第二种方式呢？

我们讨论的时候，总结了一个简单的原则：

如果子对象是父对象聚合的，且这个子对象公布的接口服务中，不存在更新服务。说白了，就是说这个接口的属性是只读的。那么建议使用第一种方式设计。

反过来，如果这个接口属性，存在“写方法”，那么父对象一定不能引用对象，因为父对象并不知道子接口到底是由哪个类来实现的。跨越接口去访问接口，那是必然有问题的。所以这个时候应该采用第二种方式。当然了，这个时候，往往就需要对接口的设计提出很高的要求。

说到最后，就是接口本身的设计了，那一定是一个非常艰难的过程了。一定不是简单原则所能解决的了。