6大設計原則之單一職責原則
單一職責原則
如果有一個用戶管理類,類圖如下
我想,任誰也能看的出這個接口設計的有問題,用戶的屬性和用戶的行為沒有分開,應該把用戶的信息抽取成一個業務對象,把用戶的行為抽取成一個業務對象,按照這個思路對類圖進行修正,如下圖所示
其實,在實際使用中我們更傾向於使用兩個不同的接口: 一個IUserBO,一個IUserBiz
單一職責原則定義
應該有且僅有一個原因引起類的變更
單一職責原則的好處:
- 類的復雜性降低,實現什麽職責都有清晰明確的定義
- 可讀性提高,復雜性降低了,可讀性當然就提高了
- 可維護性提高,可讀性提高了,當然更容易維護了
- 變更引起的風險降低.變更是必不可少的,如果接口的單一職責做的好,一個接口修改只對相應的實現類有影響,對其他類無影響,這對系統的擴展性、維護性都有非常大的幫助
單一職責原則適用於接口、類,同樣也適用於方法.
單一職責原則是非常優秀的,但是在實際使用中受很多因素的制約
建議,接口一定要做到單一職責,類的設計盡量做到只有一個原因引起變化
可以關註一下鄙人的公眾號, 謝謝各位了!
6大設計原則之單一職責原則
相關推薦
6大設計原則之單一職責原則
方法 接口設計 sta 其他 一個 src 沒有 不同的 可維護性 單一職責原則 如果有一個用戶管理類,類圖如下 我想,任誰也能看的出這個接口設計的有問題,用戶的屬性和用戶的行為沒有分開,應該把用戶的信息抽取成一個業務對象,把用戶的行為抽取成一個業務對象,按照這個思
學習設計模式 - 六大基本原則之單一職責原則
enc more ref 組合 代碼 aso HERE ali 不可 設計模式總共有六大基本原則，統稱為SOLID （穩定）原則，分別是S-單一職責原則(Single Responsibility Principle)， O-開閉原則(Open closed Pri
面向物件的五大設計原則之單一職責原則
我們都知道，面向物件是一種高度抽象的思維，我們在面向物件設計中，類是最基本的單位，我們的各種設計都是圍繞著類來進行的，可以這麼說，類與類之間的關係，構成了設計模式的大部分內容，我麼可能認為，類是屬性+函式構成的，事實上在底層儲存上確實也是這麼來搞的，但是這些僅僅只是確定一個獨立的類，而類與類之間
嘻哈說：設計模式之單一職責原則
1、定義 首先呢，我們來看一下單一職責原則的定義。 就一個類而言，應該只有一個引起它變化的原因 這個說法不是很好懂，有一些抽象，不過呢，我們依舊可以嘗試著理解一下。 就一個類而言，只有一個引起它變化的原因，也就是說，除此之外，不能有其它引起變化的原因。 這樣就
大話設計模式之單一職責原則
引用的3篇部落格，都很詳細的例子，這篇部落格是通過對參考內容的總結，便於自己理解，例子可以看參考的3篇部落格，這裡不寫 什麼是單一職責原則 單一職責原則：就一個類而言，應該僅有一個引起它變化的原因 簡單記憶：術業有專攻，我是專門搬磚的！！
Android 面向物件六大設計原則之單一職責原則
1.單一職責原則簡介單一職責原則(SRP:Single responsibility principle)又稱單一功能原則，面向物件六個基本原則(SOLID)之一。它規定一個類應該只有一個發生變化的原因
設計原則之單一職責原則(SRP)
簡介 單一職責原則是最重要的設計原則，也是最抽象的設計原則。小到函式，大到平臺的設計，都可以使用單一職責原則來指導。也正因為它的抽
深入淺出系列第一篇（設計模式之單一職責原則）—— 從純小白到Java開發的坎坷經歷
各位看官大大們，晚上好。好久不見，我想死你們了... 先說說寫這個系列文章的背景： 工作了這麼久了，每天都忙著寫業務，好久沒有好好靜下心來好好總結總結了。正好這段時間公司組織設計模式的分享分，所以我才有機會在這裡和大家嘮嘮嗑。 也許因為自己是小白自學的吧，所以磕磕絆絆走了好多彎路。
《大話設計模式》——單一職責原則
有一個 導致 完成 如果能 原因 如果 分離 破壞 一個 單一職責原則(SRP)：就一個類而言，應該僅有一個能引起它變化的原因。 如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發
七大設計原則之一單一職責原則
單一職責：一個類應該有且只有一個變化的原因。通俗的說，即一個類只負責一項職責。 單一職責原則在實際使用中即容易也非常難。我們通常賦予一個類過多相關功能，使這個類非常累。職責過多也引起很多問題。過多的職責，使類本身混亂。 參考：1.https://www.c
設計模式：單一職責原則、開放-封閉原則以及依賴倒置原則
在設計程式碼中，我們有許多可以依照的設計模式，讓我把整個專案的邏輯結構變得清晰易於維護。當然，在設計模式中我們不只有各種模式，還有許多設計的原則，雖然他們不是程式碼架構的模板，但是這些原則卻時刻提醒我們提高程式碼質量和防止未來麻煩。這次我就將單一職責原則、開放-封閉原則以及依賴倒轉原則進行解釋。
設計模式原則1----單一職責原則
個人部落格：開啟連結 1、官方定義 單一職責原則，英文縮寫SRP，全稱Single Responsibility Principle。 原始定義：There should never be more than one reason for a clas
設計模式的七大原則(1) --單一職責原則
前言 最近工作中備受打擊，之前設計的很多程式都被老大否決，需要重構，讓我好好看看設計模式。之前對這一塊內容的確不怎麼重視，感覺枯燥無聊又派不上用場。後來沉下心來研究了一番... 我靠，原來如此，之前寫程式碼的時候怎麼這麼傻逼，很多問題其實在一開始設計的時候就能避免。之前寫的都是些什麼鬼。 我們踩過的坑，歷代前
面向對象五大原則_1.單一職責原則&2.裏氏替換原則
解決 一次 cti prot 輸入 名稱 enter wid col 單一職責原則:Single Responsibility Principle (SRP) 一個類。僅僅有一個引起它變化的原因。應該僅僅有一個職責。每個職責都是變化的一個軸線。假設一個類有一個以
設計模式之單一職責
想要精通設計模式，必須要先搞清楚設計模式的六大原則。 在開始設計模式之前，先來談談設計模式的六大設計原則，第一個便是單一職責原則(Single Responsibility Principle)了。 單一職責原則定義 There should never
敏捷開發原則-SRP(單一職責原則)
SRP(Single Responsibility Principle): 定義：就一個類而言，應該僅有一個引起它變化的原因。(類，介面，方法等，都應該使用該原則) 如果一個類承擔了過多的職責，那麼引起該類變化的原因也會隨之變多。 例如： 一個圖形類中包含了draw() 繪
設計模式學習筆記（二） 設計基本原則之【單一職責原則】
code 分享 開發者 實際應用 需要 ret ext file類 tor 單一職責原則（SRP： Single Responsibility Principle） 名詞解釋： 1） 職責：是指類變化的原因。 2） 職責擴散：就是因為某種原因，職責P被分化為粒度更細的職責P
西遊記之設計模式原則——單一職責原則
void 可能 equals main person 方法 隱患 客戶端代碼 p s 單一職責原則 ——專心致誌只做一件事 1 package danyizhize; 2 3 class SunWuKong { 4 public void XiangM
設計模式之6大設計原則
單一職責原則 單一職責原則(Single Responsibility Principle, SRP)的定義是: 應該有且僅有一個原因引起類或介面的變更。即一個類或介面只負責一個功能領域中的相應職責。 單一職責原則提出了一個編寫程式的標準, 它使類的複雜性降低、提高了程式碼的可讀性、可維護性和可擴充套件性
設計模式之六大設計原則之《一》魔性的單一職責原則
定義：單一職責原則，英文全稱Single Responsbility Property。怎樣的類設計才稱的上符合單一職責原則呢？一句話：應該有且僅有一個原因引起類的變更(There should never be more than one reason for a class to chang