“模式”

在谈这个题目之前，请你把大脑中关于模式原有概念全部忘掉。

我们先从造“轮子”开始。

软件里有个“轮子”潜原则，大体意思是如果存在别人造好的轮子，那么你最好是不要自己去造，如果发现它不适合你使用，那么你再去造。

这里有一个很深的哲理，我们来细细的把它找出来。

为什么我们要用别人造好的轮子呢？因为别人的轮子是既有的东西，存在的且合理的东西。那么它的存在是有价值的，它的价值就是你可以拿它作为你自己的轮子，即它的使用价值。

上节我们说过：互不联系的对象，就算是它自身很复杂，对于我们，它不是很有用。那么别人的轮子肯定是在和它周围的东西发生一定的关系，当你要建立这 种关系时，它的使用价值才体现出来。如果你不建立这种关系时，别人的轮子造的再好，对你也没有多少用处。看来我们之所以用别人的轮子，原因不在于轮子本 身，而是在于这种关系，而这种关系是既有的东西，存在的且是合理的东西。

既有的，存在的且合理的关系，在哲学里叫原理。在软件里我们叫它模式。

人类不仅是擅长于抽象和分类能力，还有分析、归纳、总结能力。当我们重复建立这种关系时，我们就会分析、归纳、总结关系的特点、特征，把一些有鲜明特征的关系我们会把起个一个名称记下来。这样就会有很多的原理（模式）。

我上节说“我们人类更是如此，所以我们才对研究事物和其之间的关系乐此不疲”，不是没有道理的。我们学习自然科学，社学科学等等学问，其实是在学习复杂现实世界的关系，而不是学问本身。

所有的原理（模式）是不是也有些共性的东西？答案是肯定的。

共性的东西，首先就是它们是在复杂的关系中提取出来的，在一定范围内规律性的东西。其次，它们所应用的范围不同，产生的效果、作用不同。第三，它们都有一个唯一标识它的名称。

还有一个共性的东西，这个才是我们今天要讲的题目的核心问题，那个“很深的哲理”：模式规律。

因为有前人总结过，我就把模式的共同规律列出来：
1。“开-闭”
2。里氏替换
3。合成复用
4。依赖倒转
5。接口隔离
6。迪米特法则

在我认为，这是软件内的一些模式规律，但在其它地方可能不是规律。下面我们就挨个细细说这些规律。

1。“开-闭”
这个规律很好理解。在现实世界的复杂的关系中，新的事物出现，对原来的事物会形成影响，但是原有的事物很大一部分是不变化 的，变化对于整个复杂关系来说，是可以忽略不计的。这也就是说模式有一个规律是它们会让新的东西加入到原有的关系之中，但把对原有的关系的影响降到最低， 以致于忽略不计。“开”，既对加入新的东西开放，“闭”是对原有的关系的影响关闭。

2。里氏替换

有人可能会问什么叫里氏？其实这个我可以不作回答，你也可以叫它为牛氏！因为它只是一个代号而已，用来标识模式的一种规律。

这个规律的特点很明鲜，明鲜的我们生活中每天都在用。我们不是说造“轮子”吗？那么“轮子”可能有很多种，可能由不同的人造出来的，但对于我们来说 它们都是“轮子”，安装到我们车子上都可以用。这个规律就叫里氏替换。所谓的替换，就是“轮子”坏了，我可以用其它的“轮子”代替它。

3．合成复用

用别人造好的“轮子”组装成自己的车子的过程就是合成复用的过程。这个规律过于简单，没有细说的必要。

4．依赖倒置

这个规律很有意思，因为和我写OOP系列文章的第一节“抽象与分类”很大关联，当然道理也很浅显，但不易懂。

我们将现实世界的东西进行抽象，然后把大脑中的这个抽象概念不断的丰富。然后我们会把这么多的东西进行分类。依赖倒置就藏在这个分类里。分类一般会 有一个层次问题，层次因你分析的对象的复杂程度不同而不同，有的层次很多，有的层次很少。当我们对这个层次分析其“协作”关系时发现，每个层次的东西它的 关系是不一样的。上层的关系一般比较有共性，较少的改变，下层的关系一般变化比较快，而且剧烈。如果让你去选择和这个层次上的东西建立关系时，你肯定会选 取和最上层的东西建立关系。因为这种关系相对比较稳定。那你依赖的这个关系是“倒立”的，也就是说“依赖倒置”。

（注：建议以后改个名字，这个名字不太好记）

5．接口隔离

这里也有一个让人费解的词“接口”，什么叫接口呢？你暂且可以把接口换成服务，那么这个模式规律就可以叫做“服务隔离”。

那什么叫服务隔离呢？

如果你是那个快餐店的老板，你安装服务生去招呼客人。刚一开始，你们店子小，只一个服务生就可以了。但之后大一些了。一个服务生做不了，而你又接了 那个自助订餐服务，还要有人去做这个活。那么你刚才始可能会让服务也去做这个事。之后，她生气辞职了。因为她觉得自己太累了。之后你怎么做？你会专门再招 聘一个做这个自助订餐的服务。而你把这工作分隔开来，让不同的人去做，这就叫服务隔离。

这时你再词换过来，就成了“接口”隔离。

6．迪米特法则

这里你可以又会问“什么是迪米特”？我还不作回答，因为它又是一个名称。你也可以叫它为牛氏。

这条规律有点像教导小孩子：不要和陌生人说话！你为什么不让你的孩子和陌生人说话呢？因为你不想你的孩子发生意外！
在软件里也是一样，不要让你的东西发生意外，那么就不要和乱七八糟的东西建立关系。

 下一节我们将会详细的谈一下这个“关系”。

谈一点依赖倒置原则，这个“倒置”是相对于结构化的思想而讲的。按照结构化的思路，系统最底层是数据和设备的操作，然后上层的过程不断封装这些操作，越往上层越抽象，直到最上层，就是完全抽象的业务操作。这就是结构化的抽象原理。按照这种原理，上层的业务依赖下层的数据，也就是抽象依赖实现。如果我改变了下层的实现（比如把一个函数的返回值规则改掉了），所有依赖他的抽象业务都需要修改。如果我需要一个抽象的业务功能，我也必须把整棵树都搬过来。

面向对象的方式完全改变了这种依赖关系，在面向对象的系统里，业务和操作谁也不依赖谁，而是都去依赖一个抽象的业务概念，把这个抽象的概念用代码表达出来，就是interface。数据和设备的操作都是接口的实现，业务过程是建立在接口基础上的领域语言。这就倒转了结构化思想的依赖关系。

有没有倒转抽象和实现的关系，这是结构化设计和面向对象设计的区别。如果一个设计的依赖关系是一个至上而下的金字塔，不管他表面上搞出了多少个class，其实都是面向过程的设计。

...这些原则"上身"以后,可以慢慢"淡忘"了.

不错
有些用处