面向-对象的三大原则

一、介绍
二、面向-对象
三、三大原则
- 1.单一职责原则：
- 2.开放-封闭原则
- 3.依赖倒转原则
总结：

一、介绍

最近看了一篇关于面向对-象的原则的文章，感觉有所收获，然后我把这几个原则总结一下，希望能提升自身的代码水平和设计代码的水平。

二、面向-对象

这里简单提一下，对于刚刚接触代码的人来说可能不太理解面向-对象，如果还不太明白抽象、继承、多态、封装的可以去看一下我之前的文章
简单工厂设计模式

这里还是要提一下，如果你是一个开发小白还是多去学习一下面向-对象和设计模式，把C#的编码规范化，能为你后期的维护和添加新需求更改需求节约不少时间。

三、三大原则

1.单一职责原则：

这里先直接将变成原理，因为刚开始开发的可能不能白我在说什么，这里举一个简单的例子模拟一下单一职责原则是什么意思：
大家应该都用过手机，手机的功能是不是很多，比如拍照、打电话、手电筒、视频等功能，单独拿出来拍照的功能我们去跟尼康的单反去做一下对比，大家应该心里很清楚到底哪一个拍出来的照片质量会更好吧。
但是不可排除的是手机确实方便，功能比较多，但是不会太专注于做某一块的品质。

例子说完了，针对编程思维这一块，单一职责原则：就一个类而言，应该仅有一个引起它变化的原因，我在开始编程的时候经常的会在一个类中添加各种各样的功能，比如之前公司需求我给公司开发了一个Window版的查字软件，开始的时候我把算法和数据库访问的代码都放在了一个类，这只是我所谓的方便，却没有考虑到后期维护不方便，而且耦合度高，所以后来在重构的时候我也是花了不少时间，重新读了一遍代码，把逻辑都拆分出来，道理来讲的编程应该是高内聚，低耦合。

现在让你开发一个WinForm的方块游戏，你会怎么开发？会怎么设计你的程序？
首先我们需要把代码划分一下类，首先我们按照业务逻辑划分分为两层，一个是界面显示层单独一个类，另一个是操作类单独一个类，然后在Form这个类中调用即可。

这里一个类承担的职责过多，就等于把这些职责耦合到了一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会造成意想不到的破坏。

这时候我们在看，如果按照刚才说的进行设计，我们在开发Android或者ios平台的方块游戏时，我们是不是可以直接将业务逻辑层直接拿过来用，因为方块游戏的逻辑都是样的，这时候只有显示层是不同的，这就让我们的代码进行了重复利用，而且单一职责原则还让我们的代码极大的降低了耦合度。

这里在把手机的例子拿过来，手机的发展是有它的特点的，毕竟他们要考虑的因素很多，体积大小，流畅度、功能扩展、系统的升级等问题，然而编程时，我们需要在类的职责分离上多思考，做到单一职责，这样你的代码才能容易维护，易扩展、易复用、灵活多样。

2.开放-封闭原则

讲这个原则之前呢，同样我也举个例子方便大家理解，例子只是用来方便理解编程，不太有攻击性，如有恶意我会删除本文。

大家历史应该都学过邓小平这位伟大的思想政治家，收回香港澳门的知识吧，它这一创造性的**“一国两制”**想法有什么独到之处呢？
换句话说如果当时不采取这个制度，而是直接再用国内的制度方式来处理香港澳门的话，那么是不是就不会成功的收回，这里只是个人的猜想。

然而他这个创造性的提议在编程里面也是有映射的，就是我要提到的开放-封闭原则：这种不能修改，但是可以扩展的思想就是这种原则。是说软件实体（类、模块、函数等等）应该是可以扩展的，但是不可修改。换句话说就是，对扩展开发，对修改封闭。

我们在做任何系统的时候都不要指望一开始时需求确定，就不在变化，这个是不显示的想法，而且需求这种事情我们无法去明确，所以我们需要采用一种方便修改的办法来进行设计，而不是当新需求来了我们要推到之前的逻辑重新去写，所以接下来我们应该思考一个问题，怎么的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？

就比如我们每天的工作时间大约在8小时是老板的需求，甚至8小时也不是目的只是一种约束，主要的目的是完成业绩和超额完成业绩，于是改变了方式，比如弹性工作，早到早下班，晚到晚下班。对于市场部门的也是这样他们的时间更是不固定，这其实就是对工作时间的封闭，而对时间制度的开放。

做开发时间久的人来说都明白，无论模块是多么的封闭，都会存在一些无法对之封闭的变化，设计人员必须对他设计的模块应该对哪种变化封闭做出选择。必须先猜测出最有可能的变化种类，然后构造抽象来隔离那些变化。在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象类来隔离以后发生的同类变化。面对需求，对程序的改动时通过新增代码进行的，而不是更改现有代码。这就是开放-封闭原则的精髓所在。
就比如我上完提到的工厂设计模式一文中的讲解，我们把运算 + - * / 都作为一个类，继承抽象类实现他的一个方法，在每一个具体的类中写算法。这样以后如果出现开平方的运算或者其他运算，只需要增加一个新的类即可。

3.依赖倒转原则

这里我们拿两个硬件来说一下依赖倒转原则，一个是PC电脑，一个是收音机。

玩过电脑组装的人可能都知道，PC电脑出现问题大部分可能是主板以外的硬件，比如内存条、显卡、硬盘灯的损坏，然而收音机一般坏了就是需要整体的检查，不能像电脑一样方便找出问题，所以这里其实也是用到了编程的原则，这里PC电脑我们通常说易插拔，面向-对象里就是高内聚，低耦合，方便维护和扩展。

这也就是为什么一般显卡制造家AMD和Intel的针脚都是一样的，而不是每家都采用不同的针脚连接电脑。这里仔细想想内存条插槽的扩充是不是用到了开放-封闭原则。

**依赖倒转原则：抽象不应该依赖细节，而细节应该依赖于抽象。说白了就是针对接口编程，而不是对实现编程。**无论是主板、CPU、内存、硬盘都是在针对接口设计，如果针对实现来设计，内存就要对应到具体的某个商家的主板，那么就会出现换内存需要把主板也换掉的尴尬局面。
A.高层模块不应该依赖底层模块。两个都应该依赖抽象。
B.抽象不应该依赖细节。细节应该依赖抽象。

这里可能有人对倒转这个概念不理解，我们在做项目的时候是不是会经常把一些通用的类封装起来，或者说我们调用数据库的时候如果不采用抽象类的方式去统一实现，我们只是封装了一个工具类，那么这个时候新需求来了，让我们换一个数据库，这就意味着我们方法也要重构，但是我们代码里调用了很多这个方法，你要一一去修改，然后需求又来了，让你登录的时候用这个数据库，初始化数据的时候用另一个数据库，你是不是要疯了？
所以说巧妙的运用抽象类，如果我们一开始的构架就是用抽象类写的，实现方式也是调用同一个抽象类方法，新需求来了调用两个数据库，那么是不是就不需要修改之前调用的方法了，只需要添加另一个调用数据库的类即可。所以这里我们需要倒转去针对接口去实现，而不是针对实现去实现。

所以这时候在去分析一下收音机，采用的不是针对接口的设计。