設計模式 迪米特法則

2020-12-16 mySoulCode

設計模式 迪米特法則

只和朋友交流

Only talk to your immediate friends 只與直接的朋友通信。即每個對象都有耦合關係,對象之間有耦合。

定義老師類

public class Teacher{ // 老師對學生發布命令,清點學生 public void commond(GroupLeader groupLeader){ List listGirls = new ArrayList(); // 初始化學生 for(int i = 0; i < 20; i++){ listGirls.add(new Girl()); } // 然後進行查詢任務 groupLeader.countGirls(listGirls); }}然後定義體育文員,清查學生

public class GroupLeader{ // 查詢數量 public void countGirls(List listGirls){ }}定義學生類

public class Girl{}最後定義場景

public class Client{ public static void main(String[] args){ Teacher teacher = new Teacher(); // 發布命令 teacher.commond(new GroupLeader()); }}上方代碼的問題,Teacher類有一個朋友類,即GroupLeader,並且Girl類出現在commond方法體內,不屬於朋友類。

朋友類:出現在成員變量,方法的輸入參數中的類稱為成員朋友類,出現在方法內部的類不屬於朋友類,

迪米緹法則 一個類,只和朋友交流。不能和非朋友交流。但是剛剛定義的commond於Girl類有交流,即聲明了List數組,即與陌生的Girl類有交流

修改如下

修改後的老師類

public class Teacher{ // 老師對學生發布命令 public void commond(GroupLeader groupLeader){ // 告訴體育委員進行清查任務 groupLeader.countGirls(); }}體育委員

public class GroupLeader{ private List listGirls; // 將全班學生帶入,通過此構造函數Girl產生聯繫 public GroupLeader(List _listGirls){ this.listGirls = _listGirls; } // 進行學生數量的清理 public void countGirls(){ System.out.println(" " + this.listGirls.size()); }}定義場景

public class Client{ public static void main(String[] args){ List listGirls = new ArrayList(); // 創建一個群體列表 // 對學生初始化 for(int i = 0; i < 20; i++){ listGirls.add(new Girl()); } Teacher teacher = new Teacher(); // 發布命令 teacher.commond(new GroupLeader(listGirls)) }}總結, 類與類之間的關係是建立在類之間,一個方法中不要引入一個類中不存在的對象。

朋友間有距離

一個軟體安裝的過程

first定義第一步,second定義第二步,third定義第三 步。

public class Wizard{ private Random rand = new Random(); // 第一步 public int first(){ } // 第二步 public int third(){ } // 第三步 public int third(){ }}最後定義installSoftware

public class installSoftware{ public void installWizard(Wizard wizard){ int first = wizard.first(); int second = wizard.second(); int third = wizard.third(); }}最後定義場景

public class Client{ public static void main(String[] args){ installSoftware invoker = new installSoftware(); invoker.installWizard(new Wizard()); }}根據迪米特法則,兩個類之間知道的越少越好,Wizard類的太多方法被installSoftware使用,兩者的關係過於親密,修改後如下

public class Wizard{ private Random rand = new Random(); private int first(){ } private int second(){ } privaet int third(){ } // 對外只提供了一個installWizard方法 public void installWizard(){ int first = this.first(); int second = this.second(); int third = this.third(); }}public class insatllSoftware{ public void installWizard(Wizard wizard){ wizard.installWizard(); // 兩個類通過此方法連接 }}場景類

public class Client{ public static void main(String[] args){ installSoftward invoker = new installSoftware(); invoker.installWizard(new Wizard()); }}是自己的就是自己的

如果一個方法放在本類中,即不增加類間關係,也不會對本類不產生負面影響,那就放置在本類中。

相關焦點

  • 類間解耦,迪米特法則是如何規範的?
    帶著這個問題,咱們可以了解下迪米特法則,它的核心觀念是類間解耦,提高類的復用率。01 迪米特法則是什麼定義一個對象應該對其他對象保持最少的了解,也稱最少知道原則。會點UML,學習設計模式不再難!》類與類之間的關係是建立在類間的,不是方法間,因此一個方法儘量不引入一個類中不存在的對象,除JDK API提供的類。
  • 面試官:這程式設計師講的「迪米特法則」有那麼點東西
    簡介創建史:迪米特法則是1987年秋天由美國Northeastern University的Ian Holland提出的。基本概念:1、一個類對自己依賴的其它類知道的越少越好,為此迪米特法則又被稱為「最少知道原則」。
  • 設計模式設計原則——備忘錄
    2、裡氏代換原則(Liskov Substitution Principle)裡氏代換原則是面向對象設計的基本原則之一。裡氏代換原則:任何父類可以出現的地方,子類一定可以出現。由此可見,其實設計模式就是從大型軟體架構出發、便於升級和維護的軟體設計思想,它強調降低依賴,降低耦合。
  • 萬字長文帶你捋清六種設計模式的設計原則(建議收藏)
    其實設計模式的提出都是為了解決一個常見的問題而總結出來的辦法。所以當你思考採用何種設計模式的時候,你應該先問問自己當前問題的是什麼?根據問題去選取合適的設計模式。當然,本文並不是教你是如何使用設計模式。而是講解設計模式的設計原則。設計模式在被設計出來的時候,也是遵循一些規則的。
  • 軟體設計模式六大原則,你懂多少呢?
    軟體設計模式軟體設計模式,簡稱設計模式,它是一種反反覆覆被使用,多數人經過分類編目的,代碼設計經驗的總結。使用設計模式可以為了減少重複的代碼,讓代碼變得更加簡潔,讓人更加容易理解,保證代碼的可靠性,程序可重複性。設計模式的六大原則,你懂多少呢?1.六大原則-單一職責原則原則思想:一個方法只負責一件事情。
  • 面向對象設計(OOD):迪米特法則(LoD)
    單一職責讓代碼可讀性更強,可維護性更好,且更容易被復用,單一職責的理念貫穿於軟體設計的各個方面,不僅僅適用於類和函數的設計,也適用於模塊劃分,文件拆分。比如你應該讓一個函數專注於一件事情從而提高它的健壯性和可復用性,比如你不應該設計巨類從而避免讓你為類命名而頭疼,比如你應該讓文件保持簡潔短小,而不是隨意的把不相干的東西塞進來像垃圾一樣堆在一起。
  • 面向對象的六原則一法則,而現實中只需要一個原則:老婆,我錯了
    例如,琴棋書畫就應該分別設計為四個接口,而不應設計成一個接口中的四個方法,因為如果設計成一個接口中的四個方法,那麼這個接口很難用,畢竟琴棋書畫四樣都精通的人還是少數,而如果設計成四個接口,會幾項就實現幾個接口,這樣的話每個接口被復用的可能性是很高的。
  • 軟體設計的幾大原則匯總
    軟體設計的幾大原則匯總單一職責原則單一職責原則:英文為Single Responsibility Principle(SRP),這個原則要求我們在設計類或者接口的時候尤其在設計接口的時候把職責分清楚,通常一個職責不是單一的方法,是一類方法的組合。在開發的時候很難做到單一,我們在接口設計時一定做單單一,在類的設計時儘量做到單一原因引起變化。
  • 尚矽谷Java數據結構與算法、設計模式教程雙雙發布
    優秀的程序應該是這樣的:閱讀時,感覺很優雅;新增功能時,感覺很輕鬆;運行時,感覺很快速,這就需要設計模式支撐。設計模式包含了大量的編程思想,講授和真正掌握並不容易,網上的設計模式教程不少,大多講解的比較晦澀,沒有真實的應用場景和框架源碼支撐,學習後,只知其形,不知其神。就會造成這樣結果: 知道各種設計模式,但是不知道怎麼使用到真實項目。
  • 讓設計模式飛一會兒|①開篇獲獎感言
    從今天開始我將正式開啟有關設計模式的系列文章的寫作,和大家一同來聊聊設計模式這個老生常談的玩意。關於設計模式的文章,書籍,多如牛毛,隨便百度、Google一下都能給你搜出不計其數關於講解設計模式的文章來。那為什麼我還要花費如此大的精力和時間,來寫這麼個耳熟能詳的東西呢?
  • 從零開始學設計模式(一)——設計模式介紹及工廠模式
    他們所提出的設計模式主要是基於以下的面向對象設計原則。對接口編程而不是對實現編程。優先使用對象組合而不是繼承。設計模式的主要用途有兩個,一是提供了一個標準的術語系統,且具體到特定的場景。如單例設計模式意味著使用單個對象,這樣所有熟悉單例設計模式的開發人員都能使用單個對象,並且可以通過這種方式告訴對方,程序使用的是單例模式。
  • java 23種設計模式及其在spring,tomcat,jdk中的應用
    設計模式是前人(一般都是大師)對程序設計經驗的總結,學習並應用設計模式可以使我們開發的項目更加規範、便於擴展和維護,這大概是為什麼設計模式基本是面試必問的原因吧!本文主要內容有四部分:設計原則、設計模式分類、23種設計模式、設計模式應用。設計模式雖多,但重要的、主流開源框架應用較多的往往就那幾個。
  • 爬梯:七大設計原則
    設計原則設計模式原則,其實就是程式設計師在編程時,應當遵守的原則,也是各種設計模式的基礎(即:設計模式設計的依據)1、單一職責原則基本介紹對類來說,即一個類應該只負責一項職責。5)使用接口或抽象類的目的是制定規範(設計),而不涉及任何具體的操作,把展現細節的任務交給實現類完成。
  • 策略模式
    今天我們介紹的策略模式,就能優雅的實現這一需求。定義策略模式定義了一系列的算法,並將每一個算法封裝起來,使他們可以相互替換。策略模式讓算法獨立於使用它的客戶而獨立變化。話說東漢末年分三國,烽火連天不休周瑜想用美人釣來劉備,押住好換荊州諸葛亮讓趙雲護送,並帶著三個錦囊應對顯然這三個錦囊就是用來應對的策略,而為什麼要用錦囊裝著不告訴趙雲(策略執行者),那是因為諸葛亮作為一個資深程式設計師,深知「迪米特法則
  • 超實用通用設計法則解析 —「80/20法則」
    經過多年的沉澱,前輩們留下了大量的通用設計法則,小編匯集法則進行講解,抓取法則在用戶界面設計中的呈現,幫助大家更好的理解和運用。法則包含跨學科的專業知識,重拾那些被忽略的本源,將其融入日常設計和用戶體驗體系中,活用法則來驗證自己的設計過程和設計成果。「優秀的設計師有時會無視設計法則。但當他們這樣做的時候,通常會有一些補償性的措施。
  • 六大設計原則超詳細介紹(再不理解你打我)
    軟體設計最大的難題就是應對需求的變化,但是紛繁複雜的需求變化又是不可預料的,我們要為不可預料的變化做好準備,這本身是一件非常痛苦的事情,但好在有大師們已經給我們提出了非常好的六大設計原則和23種設計模式來「封裝」未來的變化。本文只針對六大設計原則進行介紹,設計模式放在後面的文章進行詳解。
  • 大神詳解,這麼詳細的Java設計模式不收藏可惜了
    引子設計模式是很多程式設計師總結出來的優秀實踐。曾經在剛開始寫項目的時候學習過設計模式,在開發過程中,也主動或者被動的使用過。現在寫代碼雖說不會特意明確在用哪種設計模式,但潛移默化的寫出來公認的優秀實踐代碼,畢竟看的比較清爽。
  • ICON設計法則-菱形法則
    (ID:SuYifilmstudio)作者:亮king網絡上有很多關於Icon設計的文章,一些文章從部分維度切入講述Icon的設計理念,但大部分缺乏整體性。所以我嘗試把自己的思考方式結合其他人的設計理念整理了一個完整的Icon設計法則,通過簡單易懂的描述語言,並且結合設計案例呈現出來,希望能夠對大家有所幫助。文章使用的案例只代表個人觀點,並不代表相關產品。本文重點講述Icon設計思維,關於Icon的具體定義以及具體的製作過程就不再贅述,網絡上有很多相關文章都有講述。
  • 那些很熟悉但又不知怎麼用的設計法則(1):80/20法則
    每次在做項目總結的時候,總想列舉一些法則和方法論來增加總結的專業性以及可信服度,但是總有些熟知的方法卻怎麼也叫不上名字,所以決定開設一個這樣的專題,敦促自己在做設計的時候不要留於表象,有理可循。80/20法則(80/20 Rule / Pareto principle)在整個產品中,大部分效果由少數幾項關鍵因素決定。80/20法則又名二八定律、帕累託法則(定律),也叫巴萊特定律、最省力的法則、不平衡原則等。是19世紀末20世紀初義大利經濟學家巴萊多發現的。