這裡主要就是文字敘述啦，對於設計模式的原則不太好舉例hhh(主要我太菜)

所以大多都是文字敘述

/**
 *
 * @author : cby
 *
 * 這裡主要就是文字描述啦
 *
 * 單一職責原則 ： 就一個類而言， 應該僅有一個引起它變化的原因，降低類內部功能的耦合性
 *
 * 比如我們在寫一個應用程式都時候都會生成類，然後往一個類中新增各種亂七八糟的功能
 * 比如什麼商業運算的演算法，資料庫訪問的SQL語句啥的都往類裡面寫
 * 這就意味著無論什麼需求來，我們都要更改這個類，非常的麻煩，維護麻煩，複用更不可能，缺乏靈活性
 *
 * 再舉一個例子，如果我們要寫一個俄羅斯方塊遊戲
 * 那麼我們就要寫它的視窗類，那如果我們把什麼方塊的操作，或者是方塊的消除，方塊的定義都寫在這個類裡面
 

 * 就是不合理的做法，既然我們要寫這個視窗類，就只要實現視窗這個"單一功能"即可，不要寫那麼多其他的程式碼
 *
 * 如果一個類承擔的職責過多，就相當於把這些職責耦合在一起，一個職責如果變化的話可能會削弱
 * 或者抑制這個類其他的職能，這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞
 *
 * 那麼視線再回到俄羅斯方塊這個程式上來
 * 我們可以把俄羅斯方塊的視窗看成一個二位陣列，0表示這個位置為空，1表示這個位置有方塊了，
 * 控制這個方塊左移實際上就是讓這個方塊的橫座標減 1，消掉一行實際上就是把這行清 0 ，然後讓上面那行的
 * 資料移動到下面來，這差不多就是邏輯層的思路
 * 那麼基於這一點，對於俄羅斯方塊這個遊戲我們就至少可以設定兩個類：
 

 *
 * (1)第一個類是邏輯層的類，邏輯層來控制方塊如何變化，以及如何消去底層，又是怎麼得分的
 *
 * (2)第二個類是檢視層的類，檢視層來控制使用者所看到的，就是方塊的形狀，方塊旋轉的動畫，方塊消去的
 * 動畫等
 *
 * 那麼當有一天我們要修改介面的時候，這與邏輯層沒關係，直接修改就可以了，達到了複用的目的
 *
 * 軟體設計真正要做的許多內容就是發現職責，並且把這些職責相互分離
 * 那麼如何分離呢？ 如果我們能夠想到多於一個的動機去改變一個類，那麼這個類就具有多於一個的職責
 *
 * 再舉個例子，我喜歡的一個遊戲 ： 守望先鋒
 *
 * 這個遊戲可以設計幾個類呢？
 * 這是一個簡答題，我來說一說我的答案：
 

 *
 * （1） 邏輯層 ： 守望先鋒這個遊戲主要有一個戰鬥中的類 ： 關於傷害的計算
 *  每個英雄都有他們的技能和大招 ， 每個英雄的大招和技能的傷害都是固定的
 *  （這裡對於爆頭的計算和距離衰減我就省略了），那麼我們就可以設定一個計算傷害的類
 *  這個類裡面有計算各個英雄傷害的方法，比如麥克雷六連打滿是360傷害，鐵拳右鍵蓄滿打擊敵人並且
 *  撞擊到牆上造成300點傷害，安娜一槍奶人 75滴血，打人70滴血等等
 *
 *  那麼在不戰鬥的時候比如玩家在主介面的時候，玩家有自己的好友，有自己的貨幣，還有自己的
 *  面板等等，我們也可以設計一個類，這個類是玩家自己賬號的類，比如計算玩家的貨幣加成，
 *  新增好友ID，購買英雄面板，或者是觸犯了一些遊戲的規則，造成的一些懲罰，這都是邏輯層要處理的事
 *
 *  （2） 檢視層 ：這沒什麼好說的 每個介面 英雄外貌 英雄釋放技能或者大招的動畫 等等
 *
 *  （3） 資料庫層 ： 我們要把玩家的資料存入伺服器的資料庫裡面
 *                  那麼也就會有對應的類來處理玩家的資料
 */