设计模式漫谈系列之独孤九剑(转自sban blog)

最新推荐文章于 2025-08-09 17:15:54 发布

转载最新推荐文章于 2025-08-09 17:15:54 发布 · 891 阅读

文章标签：

#设计模式 #blog #编程 #interface #敏捷 #扩展

本文介绍了软件设计中的七大原则，包括剔重、开封、替换、倒置、隔离、合聚及内向原则，旨在帮助程序员创建高质量、易于维护的软件。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如果目前没有更好的解决方案，那么可行的方案便是最好的方案。
编程如同做人，唯心无所滞方能潇洒快活。

第一剑：剔重。变量，属性，方法，类(接口，结构，枚举)，模块，组件，但凡可以创建的成员(或称元素)，均忌重建。编译器保证了同一访问域中变量的不可重复性。其它成员则必由程序员保证。

不创建功能雷同的方法。不创建行为类似的类。不设计意图重合的接口，但注意不要违反隔离（ISP）原则。

第二剑：开封，即开放-封闭(Open-Closed Principle，简称OCP)原则，软件实体（函数，类，模块etc）应该是可以扩展的，但却不可修改。

有一成不变的工程吗？模块的行为功能应该在需求有变或有所添加时可以扩展。但其源码却不能提供修改，即使对原始开发者。频繁重构、过度设计反无益处。

符合OCP原则的程序只通过添加代码来变化而不是通过修改已有代码。

项目几乎都具有复杂的可变性。一种可变性不应该分散到程序的各个角落里。一种可变性也不应该与另一种混淆在一起。理想情况下，一个类应该只做一件事情；一个程序员应该集中负责一个模块，让两人同做一件事情，不若让二人分做二事。团队需要协作，也需要分离。

第三剑：替换，即里氏替换原则（Liskov Substitution Principle，简称LSP）。这个原则对于从直接从面对对象语言学起的程序员来说，可能有些迷茫。LSP原则的主要机制是抽象和多态，而抽象与多态主要用继承完成。对于时下的面向对象语言，几乎所有都支持这个特性，所以不免有些混淆。

LSP的定义（也是继承机制的实现定义）：若对于每一个类型S的对象S1，都存在一个类型T的对象T1，使得在所有针对T编写的程序P中，用S1替换T1之后，程序P的行为功能仍然不变，则称S是T的子类型（或称S继承了T）。

不要过度使用继承，虽然它使用起来很方便。

第四剑：倒置，即依赖倒置原则（Denpendence Inversion Principle，简称DIP）。

如果给程序添加新功能感到很为难，每一处改动都影响到其它，这便是缺乏灵活性。如果改动了其中一个模块，其它模块则出现了BUG，这便是程序的脆弱性。如果不个模块开发出来了，不能被重复利用，这便是不可复用性。造成这些的原因在于程序的藕合性太高。我们需要创建松藕合的架构。

如果两个类没有藕合关系，是为零藕合。零藕合固然最好，但往往也没有什么用途了。两个具体的类之间，经由一个类对另一个类直接引用造成了藕合，是为具体藕合。在具体藕合中，如果其中一者或两者抽象化了，便是抽象藕合。这三种藕合均是可取的。

DIP的定义：高级模块不应该依赖于底层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，二者都应该依赖于抽象。

应用DIP原则在于从具体类中分离出抽象，使用抽象藕合组合类关系。平常所说面向接口编程便在其中。翻翻.Net或Flex的类库，类的源头往往只是一个简单的接口。

应用DIP可能会产生大量的类和接口。但程序的精简玲珑又不在于文件数量多寡，多几个文件又有甚么干系，只要逻辑概念清淅便可。编程如同做人，唯心无所滞方能潇洒快活。

第五剑：隔离，即接口隔离原则（Interface Segregation Principle，简称ISP）。一个没有足够经验的系统分析架构师总是希望节省接口的数目，总是希望把一些功能相近或类似的接口合二为一，并视其为优化代码的一部分。我曾如此，对此深有深会。戒！

ISP定义：一个类对另一个类的依赖性应该建立在最小接口之上，使用多个单一的接口远胜于使用一个复杂的接口。

接口宜多不宜少。

第六剑：合聚，即合成/聚合复用原则(Composite/Aggregate Reuse Principle，简写CARP)。于新对象内部复用已有对象，纳其为一分子。CARP明显破坏继承，但实现较容易些。时下流行敏捷。但凡敏捷便离不了复用，复用的最简单方式莫过于CARP。