衆所周知，unity的編程屬於腳本化，腳本沒有一個具體的概念跟架構， 導致在項目過程中，經常出現哪裏需要實現什麼功能，就隨便添加腳本，
結果，就造成了一片混亂，不好管理。
更有甚者，自己的寫的代碼閒置一段時間後，再去想找某個功能的實現，都要在視圖中翻來覆去找半天。
哎!請容許我在此感嘆一聲，這還是你寫的東西麼？
因此，一個好的設計模式是多麼的重要啊，
如何寫腳本架構
那麼，我們在使用unity3d開發東西的時候，腳本架構到底應該如何來寫？
其實，我也給不了你們具體答案，因爲每個人的開發習慣，每個團隊的開發模式也各有千秋，
so，在此我只做幾種設計模式的總結，
設計模式對編程人員來說，的確非常重要。
當然，如果大家的理解跟我有所不同，歡迎留言，大家共同探討。
單一職責原則
說到單一職責原則，很多人都會不屑一顧。
因爲它太簡單了，稍有經驗的程序員即使從來沒有讀過設計模式、從來沒有聽說過單一職責原則，在設計軟件時也會自覺的遵守這一重要原則，因爲這是常識。
在軟件編程中，誰也不希望因爲修改了一個功能導致其他的功能發生故障。
而避免出現這一問題的方法便是遵循單一職責原則。
雖然單一職責原則如此簡單，並且被認爲是常識，但是即便是經驗豐富的程序員寫出的程序，也會有違背這一原則的代碼存在。
爲什麼會出現這種現象呢？因爲有職責擴散。所謂職責擴散，就是因爲某種原因，職責被分化成了更細的職責。
用一個類描述動物呼吸這個場景
class Animal
{
public void breathe(string animal)
{
Debug.Log(animal + "呼吸空氣");
}
}
public class Client
{
Animal animal = new Animal();
void Start()
{
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
}
}
//運行結果：
//牛呼吸空氣
//羊呼吸空氣
//豬呼吸空氣
當需求變動
程序上線後，發現問題了，並不是所有的動物都呼吸空氣的，比如魚就是呼吸水的。
修改時如果遵循單一職責原則，需要將Animal類細分爲陸生動物類Terrestrial，水生動物Aquatic，代碼如下：
class Terrestrial
{
public void breathe(String animal)
{
Debug.Log(animal + "呼吸空氣");
}
}
class Aquatic
{
public void breathe(String animal)
{
Debug.Log(animal + "呼吸水");
}
}
public class Client
{
public static void main(String[] args)
{
Terrestrial terrestrial = new Terrestrial();
terrestrial.breathe("牛");
terrestrial.breathe("羊");
terrestrial.breathe("豬");
Aquatic aquatic = new Aquatic();
aquatic.breathe("魚");
}
}
//運行結果：
//牛呼吸空氣
//羊呼吸空氣
//豬呼吸空氣
//魚呼吸水
改動量小的方法
我們會發現如果這樣修改花銷是很大的，除了將原來的類分解之外，還需要修改客戶端。
而直接修改類Animal來達成目的雖然違背了單一職責原則，但花銷卻小的多，代碼如下：
class Animal
{
public void breathe(String animal)
{
if ("魚" == animal)
{
Debug.Log((animal + "呼吸水"));
}
else
{
Debug.Log((animal + "呼吸空氣"));
}
}
}
public class Client
{
public static void main(String[] args)
{
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
animal.breathe("魚");
}
}
隱患
可以看到，這種修改方式要簡單的多。
但是卻存在着隱患：有一天需要將魚分爲呼吸淡水的魚和呼吸海水的魚，
則又需要修改Animal類的breathe方法，而對原有代碼的修改會對調用“豬”“牛”“羊”等相關功能帶來風險，
也許某一天你會發現程序運行的結果變爲“牛呼吸水”了。
這種修改方式直接在代碼級別上違背了單一職責原則，雖然修改起來最簡單，但隱患卻是最大的。
另一種修改方式
class Animal
{
public void breathe(String animal)
{
Debug.Log(animal + "呼吸空氣");
}
public void breathe2(String animal)
{
Debug.Log(animal + "呼吸水");
}
}
public class Client
{
public static void main(String[] args)
{
Animal animal = new Animal();
animal.breathe("牛");
animal.breathe("羊");
animal.breathe("豬");
animal.breathe2("魚");
}
}
可以看到，這種修改方式沒有改動原來的方法，而是在類中新加了一個方法，這樣雖然也違背了單一職責原則，
但在方法級別上卻是符合單一職責原則的，因爲它並沒有動原來方法的代碼。這三種方式各有優缺點，
那麼在實際編程中，採用哪一中呢？
其實這真的比較難說，需要根據實際情況來確定。
我的原則是：只有邏輯足夠簡單，纔可以在代碼級別上違反單一職責原則；只有類中方法數量足夠少，纔可以在方法級別上違反單一職責原則。
更多unity2018的功能介紹請到paws3d爪爪學院查找。