I code it

Code and Life

几条软件设计的原则

其实,这里列举的大部分原则都是我读《Head First设计模式》的笔记,不过实际编码中也会常常用到,就总结一下:

封装变化

将易变的代码控制在一个类中,可以降低维护成本,同时也提高了封装性,这一点应该属于OO的基本原则,也是开发高质量代码的基本原则(只不过过程式语言是将变化封装到一个函数,或者一组函数中)。这样做的好处显而易见:代码可以更好的复用,如果有需求变更,也可以快速的定位并修改。另外一个好处是,将那些不那么易变的模块更好的独立出来,从而提供另一个层次的复用。

针对接口编程

面向接口编程,可以使得模块间更好的解耦合,解耦合的好处是让开发人员过得舒服一点,尽量避免“牵一发而动全身”的情况发生。相对于实现,接口是很不容易修改的抽象层,应尽可能的简化接口。如果接口变得庞大,尝试分解为多个接口,类可以实现多个接口(在Java中,不能继承多个类,但是可以实现多个接口)。有了多个接口,各个类就可以尝试自己决定实现那些接口,从而提供不同的职能。

使用接口的另一个好处是可以很好的利用OO语言的多态性,减少代码中的if-else数量,多态机制会如你所预期的那样将请求分发到实际的实现者上。

多用组合,少用继承

组合,是让对象“拥有”另一个对象,这样可以将实际需要做的事情分离到另一个类中,各个对象各司其职,通过方法调用(传递消息)而协作完成一个大的任务。通过组合及面向接口,可以很容易的在运行时改变对象的行为,如策略模式/状态模式,都依赖于此原则。

加入额外的层次

如果两个模块间太过于耦合,可以考虑加入一个额外的层来分离。事实上,软件开发中,我们总能找到一个额外的层次来解决紧密耦合模块。事实上,层次的划分从来都不是一件容易的事情(当然,糟糕的划分很容易见到),如果额外的层次引入的复杂度超过了可理解的范围,那你应该毫不犹豫的拿掉它,而相反,修改一个模块常常会引发另一个模块很大的变化,那么就是时候来考虑加入额外的层次了。

当然,基本的原则并不是要求开发人员生搬硬套的,使用这些模式会带来好处,但是也可能引入额外的复杂性。一个总体的原则是:当有新的变化时,最好的形式是,对已有的结构进行扩展,而不修改既有代码,如果很难做到这一点,或者做到这一点时会花费更大的精力和时间,就尽量控制涉及修改的类的数量。毕竟,我们从实际中得来的经验是为了让我们自己过得舒服一些,微笑

Comments