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

<p style="text-indent: 21pt;">今天和同事在讨论接口的设计原则的时候，总结了一个原则点。虽然简单，也拿出来和大家一起分享。</p>
<h3>问题</h3>
<p style="text-indent: 21pt;">对象在实现接口的同时，由于需要提供访问子接口的服务。最正常的设计可能是下面的。</p>
<p style="text-indent: 21pt;"><img alt="" src="https://p-blog.youkuaiyun.com/images/p_blog_youkuaiyun.com/xiammy/267259/o_SubObj.png"></p>
<p style="text-indent: 21pt;">但是，如果是另外一个情况呢？看看下面的组合方式吧：</p>
<p style="text-indent: 21pt;"><img alt="" src="https://p-blog.youkuaiyun.com/images/p_blog_youkuaiyun.com/xiammy/267259/o_SubIntf.png"></p>
<h3>小析</h3>
<p style="text-indent: 21pt;">事情变得有点有趣了。往往就是这样，只有一个的时候，没有人会怀疑。只有出现多个的时候，争吵才开始了。所谓一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。要我看来，一个和尚是多么的孤独？三个和尚虽然没水喝，可是有得吵闹，岂不是正得设计的乐趣？</p>
<p style="text-indent: 21pt;">初步看起来，这两种设计中，第二种有着明显的不合理。因为这样，层次就变得混乱。而且父对象若是要越过子接口，访问一些实现上的细节，那么就更加麻烦了！</p>
<p style="text-indent: 21pt;">前一段时间，我花很大时间去寻找方法，来通过接口指针返回对象指针(Delphi)，现在想来，这个技术刚好是第二种设计的技术补充啊。反过来，我却忽略了设计上的原则。第二种方式既然存在，那么它是不是也有存在的理由。</p>
<p style="text-indent: 21pt;">那么，什么时候适合第一种方式，什么时候适合第二种方式呢？</p>
<p style="text-indent: 21pt;">我们讨论的时候，总结了一个简单的原则：</p>
<p style="text-indent: 21pt;">如果子对象是父对象聚合的，且这个子对象公布的接口服务中，不存在更新服务。说白了，就是说这个接口的属性是只读的。那么建议使用第一种方式设计。</p>
<p style="text-indent: 21pt;">反过来，如果这个接口属性，存在“写方法”，那么父对象一定不能引用对象，因为父对象并不知道子接口到底是由哪个类来实现的。跨越接口去访问接口，那是必然有问题的。所以这个时候应该采用第二种方式。当然了，这个时候，往往就需要对接口的设计提出很高的要求。</p>
<p style="text-indent: 21pt;">说到最后，就是接口本身的设计了，那一定是一个非常艰难的过程了。一定不是简单原则所能解决的了。</p>