1、设计一个成功的抽象
经验与迭代对于好的抽象非常重要。真正好的设计的接口来自于经年的编写与使用其他的抽象。你也可以通过重要既存的、以标准设计模式形式存在的设计好的抽象来利用其他人的经年的编写与使用抽象。当你碰到其他的抽象,尝试记住什么起作用什么不起作用。在上周使用的Windows文件系统API有发现什么缺陷吗?如果你不使用同事的而要自己写网络包装器,会有什么不同吗?最好的接口鲜有一蹴而就,所以要保持迭代。把你的设计让你的同事看,寻求反馈。如果你的公司使用代码互查,在开始实现前做一个接口规范的检查。一旦开始编码也不要害怕改变抽象,即使这意味着需要其他程序员去适应。理想情况下,长期来看,他们会意识到好的抽象对每一个人都有好处。
有时候当与其他程序员沟通设计时要传递一点儿福音。也有可能团队的其他成员对于先前的设计看不到问题,或者感觉你的方法需要他们太多的投入。在这种情况下,既要准备好保护好你的工作,也要适当地加入他们的想法。
好的抽象意味着输出接口只有公共成员函数是稳定的不需要修改。要完成这项工作的一个特殊技巧就是叫做私有实现习语。这个我们以后再讨论。
记住单类抽象。如果你要写的代码有很大的深度,考虑一下其他相伴的类伴随这个主接口。例如,如果你要暴露一个数据处理的接口,也要考虑写一个结果类来查看解析这些结果。
也要把属性放到成员函数中,换句话说,不要让外部代码直接操作类中的数据。你肯定不想让一些不细心或者恶毒的程序员给兔女郎的高度赋一个负值。正常应该是有一个“设置高度”的成员函数来做边界检查。
迭代值得不断提及,因为这个观点很重要。在你的设计中不断地尝试,然后获得反馈,必要时进行修改,在错误中不断学习。
2、SOLID原则
最近的博文讨论了一些面向对象设计的基本原则。总结一下这些原则,用一个简单易记的标识就是:SOLID。以下对这五个原则进行总结:
- S:单责任原则(SRP),单责任原则是指应该有一个,定义好的责任,而不应该整合无关的功能。
- O:打开/关闭原则(OCP),类应该对扩展是开放的,对修改是关闭的。继承是完成该任务的一个方法。其他方法就是模板,函数重载,等等。一般来讲,在这里我们讲客户化的观点。
- L:利斯科夫替代原则(LSP),可以用一个对象的子类型的实例来代替该对象的实例。我们以前讨论过在AssociativeArray与MultiAssociativeArray之间是组合关系还是继承关系。
- I:接口隔离原则(ISP):保持接口干净简单。有许多小的,定义好的单责任接口要比宽广的,通用的接口要好得多。
- D:反向依赖原则(DIP):使用接口将依赖关系颠倒。支持反向依赖原则的一个方法就是依赖注入。以前的博文讨论过,以后还会讨论。