面向对象的基本原则：
- 单一职责原则（对象职责明确原则）
要求：一个对象只做好一件事情，必须专注，职责过多容易引起变化的原因就多，程序就不稳定。（高内聚，低耦合的延伸）
下面基于单一职责明确原则做简介：
职责明确原则就像是上学期间学习课程一样，语文老师只需要教学生语文，数学老师只需要教学生数学，但是语文老师也可以教我们数学，那为什么只教语文，不教数学呢？这就像面向对象的职责明确原则一样，一个老师只教一门课，一个对象只做好一件事，一个老师就相当于一个对象。
那么这个时候我们就可以思考一下，那一个老师也可以教多门课啊，比如说有些地方一个老师就是要教多门课。就像程序中一样，前后端代码（前端界面操作代码、后端数据访问代码 都属于对象的一种形式）也可以放在一个地方，运行项目也不会报错。但是这样的话就属于违背了面向对象的单一职责明确原则
这里描述一下不按照职责明确原则编写代码的问题点：
简而言之：
前端只写前端代码，后端只写数据访问数据库的代码，前端不需要了解后端是如何连接到数据库并操作数据的，后端也不需要知道前端调用后端方法去做什么。就像语文老师不需要知道数学老师教哪些东西一样，反之一样。
下面通过代码来分析一下：
前后端没有分离的情况下是这样的：
那么这个时候我们思考一下，前后端在一起的情况下是不符合单一职责明确原则的。因为这是前端，那么我们就要把后端代码从这里面分离出去。其实这就是我们的三层架构的雏形，用过三层架构的同学应该知道接下来要做什么了。其实就是把后端数据访问代码放到另外一个类里面，我们可以吧这个数据访问层单独建造一个文件夹，与前端分离开来，起名DAL层
下面是更改后的前端代码：
更改后的后端代码：
职责明确原则总结：
*原则：
----分离"界面代码"和“数据访问代码”
*好处：
----不管是什么类型的应用程序（b/s,c/s）当界面发生变化的时候，数据访问部分一般不需要任何变化
----同时前端设计人员和后台编写人员可以很好的分离
*注意：
----当我们写程序的时候，界面中不能出现任何SQL语句，数据访问后台代码中也不应该有其他业务逻辑代码。
*扩展：
----对象职责明确原则对后续“三层架构”学习打下基础
总结：
如此看起来好像比没有分离之前复杂了，这么做真的值得吗（这个问题是我刚接触三层架构的时候有过的疑问）
其实这个这样分离的好处很多，在只有一处这样的代码的时候可能感觉不出来太明显的区别，但是当项目中有上百上千个这样的文件类，难道我们还要这样写吗？那我们项目后期的维护扩展成本要有多大？所以说我们项目架构中的这些原则（职责明确原则）和特性（高内聚，低耦合）我们不仅需要懂得他们的原意，还要懂得这样设计背后用意。
ok，收工！