好代码的标准各不相同,根据不同的应用场景也有所区别,但总有一些共性,下文是Robert Martin提出的SOLID类设计原则,推荐一下。

附评几条,我认为最易于实行的,也比较容易出效果的:

l  单一责任原则:只有一个理由去修改一个类。想做到这点,直接的方式是,每个方法只做一件事情(能用一句话描述清楚的事情),一个类中的所有方法只做一种类型的事情(检验修改理由是否只有一种)。

l  不要自我重复:想cp+修改代码前,思考能否将公共部分重构为类或者方法。

l  接口分离原则:一个类对另一个类的依赖应该限制在最小化的接口上。

l  你不需要它:不要添加你“认为以后可能有用”的代码。只在“事到临头”时才添加代码。 我们做架构时经常考虑扩展性,怎样把握扩展和过度设计,这个还真是得在屡败屡战中积累经验了。不过当结合到单一责任原则,使模块、类间耦合较小,我们先写简单的代码,当需要扩展时,也可以保证修改范围可控。

l  简单化,傻瓜化(KISS):让它能工作的最简单的方法是什么?和“你不需要它”其实说的一回事,当只有10w pv时,我们去考虑1亿pv时的问题,就叫自讨苦吃。但是也得平衡的是,怎样做到风险预估,在危险真正来临前解决它。

 

设计是一门艺术,不是简单的背熟设计模式,而是在实践中不停摸索、调整的过程,期待与大家共进步。

 

 

S.O.L.I.D.类设计原则

本文是由敏捷宣言签署人之一、《 Clean Code(代码整洁之道)》一书的作者Robert C. Martin为他的《Applying Principles and Patterns》这本书搜集整理而来。

单一责任原则(SRP)

只有一个理由去修改一个类。例如,如果一个业务规则的改变会导致这个类的修改,那么,数据库、界面、报表格式或系统任何其它的部分的改变都不该迫使这个类做修改。

开发/关闭原则(OCP)

软件构成(类,模块,方法等)向扩展行为开放,向修改行为关闭。

Liskov替换原则(LSP)

子类必须能够用来当作基类使用。如果类A继承类B,任何能使用A的地方,B也同样可以使用。例如,是否还记得,正方形可以看作是矩形!当进行扩展时:前提条件不许绕过,后置条件不能放宽限制,可见常量不能被修改(?)。常量:在扩展之前或之后,用户都需要依靠这个常量来传递信息。正确的使用set形式的继承关系。不遵守set语义是非常危险的。归纳:使用超类的引用的任何上下文中也可以使用其子类的引用替代。这个原则极大的限制了在纯扩展(继承)机制里可以做的事情。不遵守会带来风险。

接口分离原则(ISP)

一个类对另一个类的依赖应该限制在最小化的接口上。

反向依赖原则(DIP)

依赖抽象层(接口),而不是具体类。

其它重要原则

Demeter定律

也被称做封锁信息原则:只跟朋友交流

一个对象O的任何一个方法M只能调用下列类型的对象的方法:

  • 它自己
  • 它的参量
  • 它创建/实例化的对象
  • 它的直接组件对象

参考

好莱坞原则

不要调用我,我会调用你的。

不要自我重复(DRY)

去掉重复代码。

对接口编程,而不是对实现

反向依赖的另外一种说法。

你不需要它(YAGNI)

不要添加你“认为以后可能有用”的代码。只在“事到临头”时才添加代码。

简单化,傻瓜化(KISS)

让它能工作的最简单的方法是什么?

 

zz from: http://www.aqee.net/s-o-l-i-d-class-design-principles/

Leave a Reply