小谈子对象中接口的设计原则
2007-05-09 00:01
148 查看
今天和同事在讨论接口的设计原则的时候,总结了一个原则点。虽然简单,也拿出来和大家一起分享。
但是,如果是另外一个情况呢?看看下面的组合方式吧:
初步看起来,这两种设计中,第二种有着明显的不合理。因为这样,层次就变得混乱。而且父对象若是要越过子接口,访问一些实现上的细节,那么就更加麻烦了!
前一段时间,我花很大时间去寻找方法,来通过接口指针返回对象指针(Delphi),现在想来,这个技术刚好是第二种设计的技术补充啊。反过来,我却忽略了设计上的原则。第二种方式既然存在,那么它是不是也有存在的理由。
那么,什么时候适合第一种方式,什么时候适合第二种方式呢?
我们讨论的时候,总结了一个简单的原则:
如果子对象是父对象聚合的,且这个子对象公布的接口服务中,不存在更新服务。说白了,就是说这个接口的属性是只读的。那么建议使用第一种方式设计。
反过来,如果这个接口属性,存在“写方法”,那么父对象一定不能引用对象,因为父对象并不知道子接口到底是由哪个类来实现的。跨越接口去访问接口,那是必然有问题的。所以这个时候应该采用第二种方式。当然了,这个时候,往往就需要对接口的设计提出很高的要求。
说到最后,就是接口本身的设计了,那一定是一个非常艰难的过程了。一定不是简单原则所能解决的了。
问题
对象在实现接口的同时,由于需要提供访问子接口的服务。最正常的设计可能是下面的。但是,如果是另外一个情况呢?看看下面的组合方式吧:
小析
事情变得有点有趣了。往往就是这样,只有一个的时候,没有人会怀疑。只有出现多个的时候,争吵才开始了。所谓一个和尚挑水喝,两个和尚抬水喝,三个和尚没水喝。要我看来,一个和尚是多么的孤独?三个和尚虽然没水喝,可是有得吵闹,岂不是正得设计的乐趣?初步看起来,这两种设计中,第二种有着明显的不合理。因为这样,层次就变得混乱。而且父对象若是要越过子接口,访问一些实现上的细节,那么就更加麻烦了!
前一段时间,我花很大时间去寻找方法,来通过接口指针返回对象指针(Delphi),现在想来,这个技术刚好是第二种设计的技术补充啊。反过来,我却忽略了设计上的原则。第二种方式既然存在,那么它是不是也有存在的理由。
那么,什么时候适合第一种方式,什么时候适合第二种方式呢?
我们讨论的时候,总结了一个简单的原则:
如果子对象是父对象聚合的,且这个子对象公布的接口服务中,不存在更新服务。说白了,就是说这个接口的属性是只读的。那么建议使用第一种方式设计。
反过来,如果这个接口属性,存在“写方法”,那么父对象一定不能引用对象,因为父对象并不知道子接口到底是由哪个类来实现的。跨越接口去访问接口,那是必然有问题的。所以这个时候应该采用第二种方式。当然了,这个时候,往往就需要对接口的设计提出很高的要求。
说到最后,就是接口本身的设计了,那一定是一个非常艰难的过程了。一定不是简单原则所能解决的了。
相关文章推荐
- 小谈子对象中接口的设计原则
- 小谈子对象中接口的设计原则
- 小谈子对象中接口的设计原则
- 小谈子对象中接口的设计原则
- 设计模式六大原则(4):接口隔离原则
- IOS设计模式的六大设计原则之接口隔离原则(ISP,Interface Segregation Principle)
- 设计模式六大原则(4):接口隔离原则
- 设计模式六大原则(4):接口隔离原则
- 面向对象设计原则之接口隔离原则
- 设计模式六大原则(4):接口隔离原则
- 设计模式六大原则(4):接口隔离原则
- 分布式架构学习之:020--服务接口设计原则
- 面向对象设计原则六 - 针对接口编程,而不是针对实现编程
- Java设计原则:面向接口的设计
- 设计模式六大原则(4):接口隔离原则
- 六大设计原则之接口隔离原则
- 设计模式:接口隔离原则
- 设计模式六大原则(4):接口隔离原则 .
- 模块间接口设计的原则
- 设计模式六大原则(4):接口隔离原则