C#實現(xiàn)六大設(shè)計原則之單一職責(zé)原則
單一職責(zé)(SRP)定義:
不要存在多于一個導(dǎo)致類變更的原因,通俗的說,即一個類只負(fù)責(zé)一項職責(zé)。
問題由來:
類T負(fù)責(zé)兩個不同的職責(zé):職責(zé)P1,職責(zé)P2。當(dāng)由于職責(zé)P1需求發(fā)生改變而需要修改類T時,有可能會導(dǎo)致原本運行正常的職責(zé)P2功能發(fā)生故障。
解決方案:
遵循單一職責(zé)原則。分別建立兩個類T1、T2,使T1完成職責(zé)P1功能,T2完成職責(zé)P2功能。這樣,當(dāng)修改類T1時,不會使職責(zé)P2發(fā)生故障風(fēng)險;同理,當(dāng)修改T2時,也不會使職責(zé)P1發(fā)生故障風(fēng)險。
ps:
說到單一職責(zé)原則,很多人都會不屑一顧。因為它太簡單了。稍有經(jīng)驗的程序員即使從來沒有讀過設(shè)計模式、從來沒有聽說過單一職責(zé)原則,在設(shè)計軟件時也會自覺的遵守這一重要原則,因為這是常識。在軟件編程中,誰也不希望因為修改了一個功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡單,并且被認(rèn)為是常識,但是即便是經(jīng)驗豐富的程序員寫出的程序,也會有違背這一原則的代碼存在。為什么會出現(xiàn)這種現(xiàn)象呢?因為有職責(zé)擴散。所謂職責(zé)擴散,就是因為某種原因,職責(zé)P被分化為粒度更細(xì)的職責(zé)P1和P2。
比如:類T只負(fù)責(zé)一個職責(zé)P,這樣設(shè)計是符合單一職責(zé)原則的。后來由于某種原因,也許是需求變更了,也許是程序的設(shè)計者境界提高了,需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1,P2,這時如果要使程序遵循單一職責(zé)原則,需要將類T也分解為兩個類T1和T2,分別負(fù)責(zé)P1、P2兩個職責(zé)。但是在程序已經(jīng)寫好的情況下,這樣做簡直太費時間了。所以,簡單的修改類T,用它來負(fù)責(zé)兩個職責(zé)是一個比較不錯的選擇,雖然這樣做有悖于單一職責(zé)原則。(這樣做的風(fēng)險在于職責(zé)擴散的不確定性,因為我們不會想到這個職責(zé)P,在未來可能會擴散為P1,P2,P3,P4……Pn。所以記住,在職責(zé)擴散到我們無法控制的程度之前,立刻對代碼進行重構(gòu)。)
C#代碼舉例說明:
我們用一個天空類, 去描述一個動物飛的動作。
class Program { static void Main(string[] args) { Sky SkyExample = new Sky(); SkyExample.fly("老鷹"); SkyExample.fly("麻雀"); Console.ReadKey(); } } public class Sky { public void fly(string name) { Console.WriteLine(name + "天上飛"); } }
但是仔細(xì)看, 會發(fā)現(xiàn)問題, 并不是所有的動物都會在天上飛, 比如狗, 它就是在地上跑。
所以要去修改它, 但如果要在遵循單一職責(zé)的原則下, 我們則需要新增一個地的類(Land), 提供一部分跑的動作 (run),
class Program { static void Main(string[] args) { Sky SkyExample = new Sky(); SkyExample.fly("飛機"); SkyExample.fly("老鷹"); SkyExample.fly("麻雀"); Land LandExample = new Land(); LandExample.run("豬"); LandExample.run("狗"); LandExample.run("馬"); Console.ReadKey(); } } public class Sky { public void fly(string name) { Console.WriteLine(name + "天上飛"); } } public class Land { public void run(string name) { Console.WriteLine(name + "地上跑"); } }
可以看到,這種修改方式?jīng)]有改動原來的類,而是新增了一個類加了一個方法, 這個即在類級別符合單一職責(zé)原則, 也在方法上符合單一職責(zé), 因為它沒有動或影響原來的代碼, 但是在實際的
開發(fā)過程中, 我們往往會將類變得更抽象(sky則改成不再是天空,變成Animal), 而我們則需要在 Animal 類下, 提供多個方法, 可以 fly,run,climb等等, 這樣也就不會我們重新建一個類去到達目的。
顯然, 這種方法違背了單一職責(zé)原則, 但是這樣在方法級別
上是符合單一職責(zé)原則得。
遵循單一職責(zé)原的優(yōu)點:
· 可以降低類的復(fù)雜度,一個類只負(fù)責(zé)一項職責(zé),其邏輯肯定要比負(fù)責(zé)多項職責(zé)簡單的多;
· 提高類的可讀性,提高系統(tǒng)的可維護性;
· 變更引起的風(fēng)險降低,變更是必然的,如果單一職責(zé)原則遵守的好,當(dāng)修改一個功能時,可以顯著降低對其他功能的影響。
ps: 需要說明的一點是單一職責(zé)原則不只是面向?qū)ο缶幊趟枷胨赜械?,只要是模塊化的程序設(shè)計,都適用單一職責(zé)原則。
到此這篇關(guān)于C#實現(xiàn)六大設(shè)計原則之單一職責(zé)原則的文章就介紹到這了。希望對大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
深入淺出掌握Unity ShaderLab語法基礎(chǔ)
Unity中所有Shader文件都通過一種陳述性語言進行描述,稱為“ShaderLab”, 這篇文章主要介紹了Unity圖形學(xué)之ShaderLab入門基礎(chǔ),需要的朋友可以參考下2023-05-05C# 文件操作函數(shù) 創(chuàng)建文件 判斷存在
本文列舉了C#中文件操作中常用的函數(shù),創(chuàng)建文件和判斷文件存不存在的基本使用,簡單實用,希望能幫到大家。2016-05-05