不过这些原则看上去都不难,但是要用好却并不那么容易。要能把这些原则用得好用得精,而不教条,我的经验如下:(我以为这是一个理论到应用的过程)
- 你可以先粗浅或是表面地知道这些原则。
- 但不要急着马上就使用。
- 在工作学习中观察和总结别人或自己的设计。
- 再回过头来了回顾一下这些原则,相信你会有一些自己的心得。
- 有适度地去实践一下。
- Goto第 3步。
You Ain’t Gonna Need It (YAGNI)
这个原则简而言之为——只考虑和设计必须的功能,避免过度设计。只实现目前需要的功能,在以后您需要更多功能时,可以再进行添加。
- 如无必要,勿增复杂性。
- 软件开发先是一场沟通博弈。
以前本站有一篇关于过度重构的文章,这个示例就是这个原则的反例。而,WebSphere的设计者就表示过他过度设计了这个产品。我们的程序员或是架构师在设计系统的时候,会考虑很多扩展性的东西,导致在架构与设计方面使用了大量折衷,最后导致项目失败。这是个令人感到讽刺的教训,因为本来希望尽可能延长项目的生命周期,结果反而缩短了生命周期。
参考:http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It
Law of Demeter – 迪米特法则
迪米特法则(Law of Demeter),又称“最少知识原则”(Principle of Least Knowledge),其来源于1987年荷兰大学的一个叫做Demeter的项目。Craig Larman把Law of Demeter又称作“不要和陌生人说话”。在《程序员修炼之道》中讲LoD的那一章叫作“解耦合与迪米特法则”。关于迪米特法则有一些很形象的比喻:
- 如果你想让你的狗跑的话,你会对狗狗说还是对四条狗腿说?
- 如果你去店里买东西,你会把钱交给店员,还是会把钱包交给店员让他自己拿?
和狗的四肢说话?让店员自己从钱包里拿钱?这听起来有点荒唐,不过在我们的代码里这几乎是见怪不怪的事情了。
对于LoD,正式的表述如下:
对于对象 ‘O’ 中一个方法’M',M应该只能够访问以下对象中的方法:
- 对象O;
- 与O直接相关的Component Object;
- 由方法M创建或者实例化的对象;
- 作为方法M的参数的对象。
在《Clean Code》一书中,有一段Apache framework中的一段违反了LoD的代码:
final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
这么长的一串对其它对象的细节,以及细节的细节,细节的细节的细节……的调用,增加了耦合,使得代码结构复杂、僵化,难以扩展和维护。
在《重构》一书中的代码的环味道中有一种叫做“Feature Envy”(依恋情结),形象的描述了一种违反了LoC的情况。Feature Envy就是说一个对象对其它对象的内容更有兴趣,也就是说老是羡慕别的对象的成员、结构或者功能,大老远的调用人家的东西。这样的结构显然是不合理的。 我们的程序应该写得比较“害羞”。不能像前面例子中的那个不把自己当外人的店员一样,拿过客人的钱包自己把钱拿出来。“害羞”的程序只和自己最近的朋友交 谈。这种情况下应该调整程序的结构,让那个对象自己拥有它羡慕的feature,或者使用合理的设计模式(例如Facade和Mediator)。
参考:http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge