一些软件设计的原则
- 如无必要，勿增复杂性。
- 软件开发先是一场沟通博弈。
以前本站有一篇关于过度重构的文章，这个示例就是这个原则的反例。而，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
面向对象的S.O.L.I.D 原则
一般来说这是面向对象的五大设计原则，但是，我觉得这些原则可适用于所有的软件开发。
Single Responsibility Principle (SRP) – 职责单一原则
关于单一职责原则，其核心的思想是：一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因。
Open/Closed Principle (OCP) – 开闭原则
关于开发封闭原则，其核心的思想是：模块是可扩展的，而不可修改的。也就是说，对