网站代码设计原则 第1篇
接口隔离原则(Interface Segregation Principle，ISP)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是
客户端不应该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)
该原则还有另外一个定义
一个类对另一个类的依赖应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责
而接口隔离原则注重的是对接口依赖的隔离
单一职责原则主要是约束类，它针对的是程序中的实现和细节
接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建
使用多个专门的接口，而不是使用单一的总接口
这个原则跟单一设计原则有些类似
比如我们为了在设置动物接口的时候
可以直接将动物的吃、飞、游的属性都定义到接口中
然后具体的鸟和狗都实现这个动物接口
类图如下图所示
但是这样会导致一个问题
就是小鸟一般不会游泳，但是它也会实现这个方法
狗不会飞，但是也会实现飞的方法
这样给代码的维护和使用都会造成一定的障碍
如果我们按照接口隔离原则设计
将游泳、吃、飞的方法分别用三个动物接口实现
狗和鸟分别实现其中对中的多个接口
则不仅代码结构清晰，维护起来也会非常方便
网站代码设计原则 第2篇
单一职责原则(Single Responsibility Principle，SRP)又称单一功能原则
由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发：原则、模式和实践》一书中提出的
这里的职责是指类变化的原因
单一职责原则规定一个类应该有且仅有一个引起它变化的原因
否则类应该被拆分
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
网站代码设计原则 第3篇
迪米特法则(Law of Demeter，LoD)又叫作最少知识原则(Least Knowledge Principle，LKP)
产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目
由伊恩·荷兰(Ian Holland)提出，被 UML 创始者之一的布奇(Booch)普及
后来又因为在经典著作《程序员修炼之道》(The Pragmatic Programmer)提及而广为人知
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)
其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用
可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性
使模块之间的通信效率降低
所以，在釆用迪米特法则时需要反复权衡
确保高内聚和低耦合的同时，保证系统的结构清晰
比如校园招聘工作
这里边应该包含学生、HR、用人部门三个角色
但是用人部门不会直接招聘
是通过向HR提交人才需求
通过HR作为中转与学生进行沟通
类图如图所示
具体用人的部门根本不需要直接跟学生接触
所有招聘工作都是通过HR完成
网站代码设计原则 第4篇
最少知识原则（Least Knowledge Principle，简称 LKP），也叫迪米特法则（LOD）：一个对象应该对其他对象有最少的了解，说白了就是，只关联自己需要的。
我们来看个 Demo，又是那个音乐播放器，原本应该是这样的：
可以看到，播放时，只需要一个path即可。但是直接把Song给他传过去不行吗？这样后面万一需要Song里面的其他变量，比如name啥的，也不用改函数了！
其实，播放器需要的只是一个播放的路径，至于其他的，它根本不关心。如果真的需要，你再提供，但也只需要提供它需要的，不要有任何附加内容。否则，一旦那些附加内容变化了，也间接导致播放器自身的变化，这是不应该的。
我们应该只关联自己直接用到的，而不关联那些不需要的，如此一来，那些发生在我们关联范围外的事，就不会引起我们的任何改变，这样就大大提升了代码的健壮性。
开放闭合原则（Open Close Principle，简称 OCP）：一个类应该对扩展开放，对修改关闭。换句话说就是：应该多扩展代码，少修改代码。
开闭原则是最理想的原则，是所有设计模式的最终目标，基本不可能实现。它要求我们的任何改动都不修改老代码，而只添加新代码，这样就不会对老逻辑有任何影响，从而使得代码更加安全。
有人说，我们的代码不是一次性的，肯定是要修改的，怎么可能不修改呢？没错，肯定是需要修改的，但是合理运用开闭原则可以做到少修改，改得越少风险越小。
举个例子，要手写一个计算器，只需要支持简单的加减法就行，如下：
代码简单粗暴，直接使用if判断就完事。但是，如果将来要支持其他运算呢？嗯，继续添加if分支？可以，但是不太好，谁能保证你下次添加别的运算符的时候，不会手残改了别的运算呢？那么，我们能不能将新的运算不放在这个类里面呢？可以！
我们可以将每个运算定义成一个单独的类型，后面新增其他运算，只需要新加一个类就可以了。我们知道，基本的数学运算都是需要两个操作数和一个运算符的，我们可以定义一个公有的父类，来保存操作数和运算符。
定义公共父类：
加法器：
减法器：
这里我们为不同的运算符提供了不同的实现类，每个类只负责自己的计算逻辑，如果将来有其他新运算加入，我们直接再添加一个新的类即可，完全不需要修改其他类的代码。
而且我们可以看到，开闭原则中用到了单一职责（每个类只做自己的运算），还用到了最少知识（每个类只关心自己的操作数和运算符），其实就是一句话：越单纯，越干净，越好！ 因为这样自己的责任就越少，就越不容易被牵连，也就越稳定，越安全。
我们从宏观层面讲解了六大设计原则，这是 23 种设计模式的祖宗，或者说：设计模式就是这六大设计原则的具体实现，六大设计原则就是设计模式的抽象。
对于设计模式，我认为正确的学习顺序是：
学习设计原则，这是对设计思想的宏观认识。
学习设计模式，这是对设计思想的具体认识。
再学习设计原则，这是对设计思想的自我抽象
网站代码设计原则 第5篇
依赖倒置原则（Dipendence Inversion Principle，简称 DIP）：面向接口编程或面向抽象编程。
依赖倒置的官方定义：高层不应该依赖底层，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。其实狭义的说就是：面向接口编程，广义的说就是：面向抽象编程。也就是说，我们在使用类的时候，优先考虑使用抽象类或接口。具体一点就是：成员变量、函数参数和返回值都尽量定义成接口。
为什么要这么干呢？这么干有什么好处呢？
我们知道，接口都是抽象的，抽象的就是不确定的，不确定的就是可变的。而我们的大部分代码都是“非一次性的”，也都是需要改变的，所以，接口正合适。
换句话说，接口就是具有某种功能的某种东西，是什么我不管，只要具有这种功能就行，而我们需要的，也就是具有这种功能的东西。
比如，我需要给手机充个电，我需要的是一个“能充电的东西”，而你却对外说：“我需要个充电宝！”如果有人没有充电宝，只有电源呢，他就不认你了。在这里，你把我需要的东西具象化了，也就是把范围缩小了，范围越小越精确，就越不容易改变，这明显是不对的。
再比如，现在我要提供一个音乐播放器，我直接使用移动端的 MediaPlayer，很容易就写出了如下代码：
三分钟就写完了，使用方直接调用：
完事之后某一天，主管又问：“咱们的播放器不好用，能用那个开源的吗？”
当然可以，于是就去改，但是发现，要改的地方太多了，我不但要改MedidPlayer这个类，甚至调用我播放器的人也需要改他的User类！
这时候就应该反思了，其实User这个类，不在乎你的播放器是怎么写的，它只关心能不能播放、停止、暂停、恢复，说白了，它要的是一个具有这种功能的某种东西，而不是具有这种功能的这种东西。
用接口！
User使用：
此时User只依赖于IPlayer，而不依赖具体的实现。不管你是啥，只要具有播放器的功能就行，后面不管你怎么改变IPlayer的实现，User都不需要改变。
所以，我们可以看到面向接口的好处：低耦合，易拓展。因为接口是抽象的，依赖接口就是依赖抽象，不依赖细节，所以实现的细节怎么改都对我无影响，所以耦合就低；又因为接口是顶层的，就更容易拓展下层的细节实现。
网站代码设计原则 第6篇
开闭原则(Open Closed Principle，OCP)由勃兰特·梅耶(Bertrand Meyer)在 1988 年的著作《面向对象软件构造》(Object Oriented Software Construction)中提出
软件实体应当对扩展开放，对修改关闭(Software entities should be open for extension，but closed for modification)
这里的软件实体包括以下几个部分：
项目中划分出的模块
类与接口
简单来说就是尽量实现在新增功能的时候不修改已经写好的代码
举个例子
实现一个商品的对象
可以先定义一个接口
其中实现一个商品的一些属性
编号、名称和价钱
具体的商品类则实现这个接口
比如实现一个食品的商品类
但是在食物商品有个问题，就是容易过期
在快过期的时候为了促销，会打折
为了能够让商品的价格发生打折
我们可以直接在修改FoodCommodity里边的代码
新增一个成员变量或者直接改返回价格的代码
但是这样其实是有风险的
有可能会导致已经写好的代码出问题
那个更好的办法就是下边这个
新实现一个DiscountFoodCommodity 打折食物的类
并继承FoodCommodity
类图是这样的
这样我们就可以在不更改FoodCommodity任何代码的情况下实现一个打折的商品
网站代码设计原则 第7篇
依赖倒置原则(Dependence Inversion Principle，DIP)是 Object Mentor 公司总裁罗伯特·马丁(Robert )于 1996 年在 C++ Report 上发表的文章
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
其核心思想是：要面向接口编程，不要面向实现编程
依赖倒置原则是实现开闭原则的重要途径之一
它降低了客户与实现模块之间的耦合
由于在软件设计中，细节具有多变性，而抽象层则相对稳定
因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多
这里的抽象指的是接口或者抽象类，而细节是指具体的实现类
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成
比如我们想实现一个售货员卖商品的功能
首先定义一个售货员类
然后写一个方法，他可以卖香皂
但是这么设计有一个问题
如果想让他可以卖香蕉
则需要再在上边的类中新加一个售卖香蕉的方法
如果要卖苹果，还要再加一个卖苹果的方法
这样修改代码容易造成意想不到的风险
如果采取依赖倒置的思想
将商品售卖的功能放到商品中
售货员只实现一个售卖东西(任何商品)的方法就可以了
首先定义一个商品接口
然后实现一个肥皂商品
这样在新增商品的时候
只需要将商品交给售货员就行
不需要修改任何底层代码
实际上这是一种大家非常熟悉的方式，叫依赖注入
通过方法传参的方式实现的
网站代码设计原则 第8篇
单一职责原则（Single Responsibility Principle，简称 SRP）： 一个类只干一件事。
可以看到，单一职责的核心就是：只做一件事。不过，关键点就是这个“事”的范围不好定义。
比如，写一个音乐播放器，一个类负责播放，一个类负责停止，这也满足单一职责。但是，这个职责太小了。那么，如果把播放、停止、甚至下载歌曲，都塞进一个类里面呢，那就太大了。所以，职责的范围很重要，只要确定好了这个范围，那这个原则就已经实现了 90%。
那么，这个范围怎么确定呢？我们可以这么理解：一些相关的、关联性比较强的，就把它们当作同一种职责，放到一个单独的类（文件）里。
那么，怎么确定是否相关呢？看需求！这个只能看需求，没有别的方法。如果需求没有明确，那么我们就要联系现实来决定，毕竟程序的本质就是模拟现实。
比如，我在 2015 年实习的时候，IBM 公司有个考勤系统，需要添加一个指纹打卡功能。需求是这样的：部门主管以下的员工可以用指纹来打卡。
那么，这个“打卡功能”是属于员工的，是属于打卡器的？换句话说，这个打卡的函数，是写在员工类里面呢，还是写在打卡器类里面呢？需求没说啊。
那么，我们就联系现实来决定。
在现实生活中，应该是一个打卡器放在门口，员工向打卡器录入指纹，来进行打卡，说白了就是：“员工使用打卡器来打卡”，也就是：“员工使用打卡器”“打卡器打卡”，所以，打卡功能是打卡器的，员工只是使用它的这个功能。所以，这个函数应该定义在打卡器里面，员工调用打卡器的这个函数来进行打卡。
单一职责不仅可以用在类（文件）里面，也可以用在函数里面。
比如，现在需要写一个校验函数，校验用户的性别和年龄，必须是 18 岁及以上的男性才有资格，很简单的我们可以这么写：
使用：
这里有人有意见了，说这样写不太好，因为每个校验的地方都要自己弹出提示，这样就是很多重复的代码，所以提示这个逻辑应该放在checkSexAndAge()这个函数里面去，也就是下面这样：
这样就好多了，任何时候只要直接调checkSexAndAge()就行，判断了还自带提示。这在目前当然是完美的，虽然方法名不太合适。
如果有一天，我们的需求变成了：年龄不满足就开启未成年人保护模式，不需要弹出提示。我们直接删除tips()这个调用吗？这样不太好，如果别的地方也调用了这个方法，并且需要提示，就完了。所以我们应该有两个方法：方法 A 只检测，方法 B 使用 A 的检测结果并弹出提示。代码如下所示：
这里我们只抽离了一个方法，但是却反映出了单一职责的好处：职责越单一，因为修改而引起的问题就越少。换句话说就是：需求的粒度跟单一职责的优势成正比，需求越详细，越能看出单一职责的好处。所以我们要尽量避免大方法、大类、大模块，因为一个类越大，涉及的东西就越多，用到它的地方就越多，那么这个类就不能轻易修改，因为一旦修改，涉及的地方就越多，就越危险，所以我们一定要尽量避免。其实 MVC 就是一个宏观的、大的单一职责思想。
单一职责不仅适用于类和文件，还适用于函数、模块等，这是一种思想，一定要掌握。