设计模式----单一职责原则

这里主要就是文字叙述啦，对于设计模式的原则不太好举例hhh(主要我太菜)

所以大多都是文字叙述

/**
 *
 * @author : cby
 *
 * 这里主要就是文字描述啦
 *
 * 单一职责原则 ： 就一个类而言， 应该仅有一个引起它变化的原因，降低类内部功能的耦合性
 *
 * 比如我们在写一个应用程序都时候都会生成类，然后往一个类中添加各种乱七八糟的功能
 * 比如什么商业运算的算法，数据库访问的SQL语句啥的都往类里面写
 * 这就意味着无论什么需求来，我们都要更改这个类，非常的麻烦，维护麻烦，复用更不可能，缺乏灵活性
 *
 * 再举一个例子，如果我们要写一个俄罗斯方块游戏
 * 那么我们就要写它的窗口类，那如果我们把什么方块的操作，或者是方块的消除，方块的定义都写在这个类里面
 * 就是不合理的做法，既然我们要写这个窗口类，就只要实现窗口这个"单一功能"即可，不要写那么多其他的代码
 *
 * 如果一个类承担的职责过多，就相当于把这些职责耦合在一起，一个职责如果变化的话可能会削弱
 * 或者抑制这个类其他的职能，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏
 *
 * 那么视线再回到俄罗斯方块这个程序上来
 * 我们可以把俄罗斯方块的窗口看成一个二位数组，0表示这个位置为空，1表示这个位置有方块了，
 * 控制这个方块左移实际上就是让这个方块的横坐标减 1，消掉一行实际上就是把这行清 0 ，然后让上面那行的
 * 数据移动到下面来，这差不多就是逻辑层的思路
 * 那么基于这一点，对于俄罗斯方块这个游戏我们就至少可以设置两个类：
 *
 * (1)第一个类是逻辑层的类，逻辑层来控制方块如何变化，以及如何消去底层，又是怎么得分的
 *
 * (2)第二个类是视图层的类，视图层来控制用户所看到的，就是方块的形状，方块旋转的动画，方块消去的
 * 动画等
 *
 * 那么当有一天我们要修改界面的时候，这与逻辑层没关系，直接修改就可以了，达到了复用的目的
 *
 * 软件设计真正要做的许多内容就是发现职责，并且把这些职责相互分离
 * 那么如何分离呢？ 如果我们能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责
 *
 * 再举个例子，我喜欢的一个游戏 ： 守望先锋
 *
 * 这个游戏可以设计几个类呢？
 * 这是一个简答题，我来说一说我的答案：
 *
 * （1） 逻辑层 ： 守望先锋这个游戏主要有一个战斗中的类 ： 关于伤害的计算
 *  每个英雄都有他们的技能和大招 ， 每个英雄的大招和技能的伤害都是固定的
 *  （这里对于爆头的计算和距离衰减我就省略了），那么我们就可以设置一个计算伤害的类
 *  这个类里面有计算各个英雄伤害的方法，比如麦克雷六连打满是360伤害，铁拳右键蓄满打击敌人并且
 *  撞击到墙上造成300点伤害，安娜一枪奶人 75滴血，打人70滴血等等
 *
 *  那么在不战斗的时候比如玩家在主界面的时候，玩家有自己的好友，有自己的货币，还有自己的
 *  皮肤等等，我们也可以设计一个类，这个类是玩家自己账号的类，比如计算玩家的货币加成，
 *  添加好友ID，购买英雄皮肤，或者是触犯了一些游戏的规则，造成的一些惩罚，这都是逻辑层要处理的事
 *
 *  （2） 视图层 ：这没什么好说的 每个界面 英雄外貌 英雄释放技能或者大招的动画 等等
 *
 *  （3） 数据库层 ： 我们要把玩家的数据存入服务器的数据库里面
 *                  那么也就会有对应的类来处理玩家的数据
 */