设计模式（一）--单一职责模式（衡量接口或类设计）

 
     作为一只入坑了两年多的java程序猿，最近才真正接触到公司的项目，面对公司所使用的框架技术，真是两眼一抹黑啊，如何快速看懂现有项目的关键技术，这直接决定你是否能快速胜任手里的工作！这段时间也思考了很多；现有的后端技术真的很多，springBoot、springcloud。。。什么的，我们固然要学习了，但是如果你的思维还停留在以前学生时代写的代码，做的软件。。那你也许会很不适应公司的开发工作，学生时代做的软件大多数都是自己的一些想法，然后付诸在代码上，框架架构什么的、需求什么的。。。我好像真的没怎么思考过，就连写的代码都是一时兴起！！！现在趁着还有时间就得深入了解一下编程的思维，提升一下自己编码姿势！
      看到公司现有项目的代码，我就常常在神游，为什么要继承这个接口？为什么实现类可以这样写？为什么别人写的代码会如此简洁而且条理清晰？。。。就在我快要迷糊，甚至在怀疑是否适合走编程这条路的时候！我看到了设计模式，什么是设计模式？简单来说就是历代优秀程序员总结出来的代码经验；这相当于一本对于程序员的绝世秘籍啊！如果你是刚接触程序，目前还在学基础语法的，也就是说你还没有写过几个软件、网站的，没有自主实现过软件开发从0到1的过程的，建议你不用急着了解这些设计模式。因为乱花渐入迷人眼啊！设计模式一共有多少种呢？最经典的有23种，我现在写的就是其中一种--单一职责模式；
     单一职责模式（SRP）提出了一个程序员编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良；通俗来说在实际开发工作中应该保持一个接口只做一件事，也就是一个职责一个接口；只要做过项目，肯定要接触到用户、机构、角色管理这些模块，通常解决这些模块间的权限分配、处理事件等实际开发问题都是基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使用户与权限分离。用户作为角色管理的主体，它可以是管理员，也可以是用户，管理员有多少权限呢？他可以分配权限给用户，把用户拉进黑名单（删除用户）等等，用户可以修改自己的个人信息，在管理员赋予他的权限里完成数据的查看、搜索、增加、删除等等；你也许在想这不简单，用户就是用户，管理员就是管理员，我写两个接口分开就行了嘛，用户该干嘛就干嘛，管理员，我们暂时不聊；我们说说用户这个接口该怎么写？他可以查看修改自己的用户名、密码、头像，修改数据的增删改查，那么用户类的类图是这个样子：

    认真看看，发现问题了吗？把用户相关功能都发在接口了，实现类只需调用接口就可以独立完成需要的功能了，但是用户这个接口明显有问题啊，用户的属性跟行为写在一个接口里，那就意味着这个接口要管理属性，也要管理行为。这明显是两件事啊，所以违背了单一职责模式,那么就应该分拆成两个接口，修改一下类图如下：

     是不是很简单啊？设计模式不涉及高深的代码实现，它只是让你的编程思维有一点点改变；单一职责模式的好处是降低类的复杂性，实现什么职责都有明确的定义；提高程序的可读性；单一职责模式普遍适用于接口的设计，一个接口完成一个职责，也适用方法的设计，一个方法尽量做一件事情，例如一个方法是修改用户密码的，你就不应该把这个方法放到"修改用户信息"方法中；

总结：
     接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。