華南理工大學UML課件-14設計模式

1、軟件需求分析與建模-設計模式主講：( )2022年8月27日1 基本概念 基本要素 模式分類工廠模式單例模式策略模式MVC模式引言設計模式的起源模式的研究起源于建筑工程設計大師Christopher Alexander的關于城市規(guī)劃和建筑設計的著作(建筑的永恒之道).在面向對象的編程中使用模式化方法研究的開創(chuàng)性著作設計模式-可復用面向對象軟件的基礎這本書的四位作者也通常被稱為“四人幫”。建議閱讀以下三本書1.設計模式可復用面向對象軟件的基礎2.Java與模式，作者：閻宏。3.Inside VCL，作者：李維。在面向對象的編程中，軟件編程人員更加注重現(xiàn)有代碼的重用性和可維護性。設計模式使人們可以

2、更加簡單方便地重用成功的設計和體系結構。將已證實的技術表述成設計模式也會使新系統(tǒng)開發(fā)者更加容易理解其設計思路。A pattern is an idea that has been useful in one practical context and will probably be useful in others.-Martin Fowler設計模式-基本概念一般而言，一個模式有四個基本要素模式名稱（pattern name）問題（problem）解決方案（solution）效果（consequences）設計模式-基本要素模式名稱（pattern name） 一個助記名，它用一兩個詞來描

3、述模式的問題、解決方案和效果。設計模式允許我們在較高的抽象層次上進行設計。模式名可以幫助我們思考，便于我們與其他人交流設計思想及設計結果。找到恰當?shù)哪Ｊ矫彩俏覀冊O計模式編目工作的難點之一。設計模式-基本要素問題（problem） 描述了應該在何時使用模式。它解釋了設計問題和問題存在的前因后果，它可能描述了特定的設計問題，如怎樣用對象表示算法等。也可能描述了導致不靈活設計的類或對象結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。設計模式-基本要素解決方案（solution） 描述了設計的組成成分，它們之間的相互關系及各自的職責和協(xié)作方式。因為模式就像一個模板，可應用于多種不同場合

4、，所以解決方案并不描述一個特定而具體的設計或實現(xiàn)，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或對象組合）來解決這個問題。設計模式-基本要素效果（consequences） 描述了模式應用的效果及使用模式應權衡的問題。盡管我們描述設計決策時，并不總提到模式效果，但它們對于評價設計選擇和理解使用模式的代價及好處具有重要意義。軟件效果大多關注對時間和空間的衡量，它們也表述了語言和實現(xiàn)問題。因為復用是面向對象設計的要素之一，所以模式效果包括它對系統(tǒng)的靈活性、擴充性或可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。設計模式-基本要素創(chuàng)建型模式抽象的實例化過程結構型模

5、式如何組合類和對象以獲得更大的結構行為型模式涉及到算法和對象間職責的分配設計模式-模式分類設計模式的分類1、創(chuàng)建型設計模式 創(chuàng)建型模式隱藏了對象創(chuàng)建的具體細節(jié)，使程序代碼不依賴具體的對象。 創(chuàng)建型類的模式有工廠方法（Factory Method）模式； 創(chuàng)建型對象模式包括抽象工廠（Abstract Factory）、建造（Builder）、原型（Prototype）、單例 （Singleton）四種模式。設計模式的分類及其相互間關系2、結構型設計模式 結構型模式描述類和對象之間通過組織形成新的結構，以實現(xiàn)新的功能。 結構型的類模式采用繼承機制來組合類，如適配器（Adapter）類模式； 結構型

6、的對象模式則描述了對象的組裝方式，如適配器（Adapter）對象模式、橋接（Bridge）模式、組合（Composite）模式、裝飾（Decorator）模式、外觀（Facade）模式、享元（Flyweight）模式、代理（Proxy）模式等。3、行為型設計模式 行為型設計模式描述算法以及對象之間的任務（職責）分配及它們之間的通訊模式。 行為型的類模式用繼承方法完成，有模板方法模式和解釋器模式； 行為型的對象模式使用對象復合方法而不是繼承，它描述一組對象怎樣協(xié)作完成單個對象所無法完成的任務， 如職責鏈（Chain ofReponsibility）模式、命令（Command）模式、迭代器（Ite

7、rator）模式、中介者（Mediator）模式、備忘錄（Memento）模式、觀察者（Observer）模式、狀態(tài)（State）模式、策略（Strategy）模式、訪問者（Visitor）模式等。模式的另一種分類Architectural Patterns 表達了軟件系統(tǒng)的基本結構組織形式或者結構方案它包含一組預定義的子系統(tǒng)，規(guī)定了這些子系統(tǒng)的責任，同時還提供了用于組織和管理這些子系統(tǒng)的規(guī)則和向導Design Patterns 為軟件系統(tǒng)的子系統(tǒng)、組件或者組件之間的關系提供一個精煉之后的解決方案它描述了在特定環(huán)境下，用于解決通用軟件設計問題的組件以及這些組件相互通信時的可重現(xiàn)結構Idioms

8、 是一個與編程語言相關的低級模式它描述了如何實現(xiàn)組件的某些功能，或者利用編程語言的特性來實現(xiàn)組件內(nèi)部要素之間的通信功能設計模式的指導原則重用(reuse)：是目標兩種重要的重用手段Inheritance & composition/aggregation接口與實現(xiàn)分離接口保持不變，分離帶來靈活性多態(tài)性(polymorphism)Decouple降低復雜性工廠模式的幾種類型工廠模式專門負責將大量有共同接口的類實例化。工廠模式可以動態(tài)地決定將哪一個類實例化，不必事先知道每次要實例化哪一個類。工廠模式具有以下幾種類型：1.簡單工廠：又稱靜態(tài)工廠方法模式2.工廠方法：又稱多態(tài)性工廠模式3.抽象工廠模式

9、：又稱工具箱模式（Toolkit)簡單工廠模式簡單工廠模式是類的創(chuàng)建模式簡單工廠模式是有一個工廠類根據(jù)傳入的參量決定創(chuàng)建出哪一種產(chǎn)品類的實例。情況1：客戶端需要創(chuàng)建各種不同的對象以類Sample為例， 假設要創(chuàng)建Sample的實例對象: Sample sample=new Sample(); 有時候可能要創(chuàng)建不同的Sample對象，那么可以用：If choice = 1 then sample = new Sample1 Else if chose = 2 then sample = new Sample2Else sample = new Sample3情況2：創(chuàng)建時包含大量的初始化工作如果

10、創(chuàng)建sample實例時包含了大量的初始化工作，例如賦值、查詢數(shù)據(jù)庫、安全審核、日志記錄等，那么對象的構造函數(shù)中就包含了大量的額外工作。上述兩種情況都是將對象的創(chuàng)建與使用混合在一起，容易使得代碼變得非常復雜。如何解決這個問題呢？要解決這個問題，應該盡量將創(chuàng)建實例的工作與使用實例的工作分開，也就是說，讓客戶端所做的各種判斷或者創(chuàng)建實例所需要的大量初始化工作與對象本身的構造分離開。 工廠類（Creator）角色：該角色是工廠方法模式的核心，含有與應用緊密相關的商業(yè)邏輯。工廠類在客戶端的直接調用下創(chuàng)建產(chǎn)品對象，它往往由一個具體類實現(xiàn)。 抽象產(chǎn)品（Product）角色：擔任這個角色的類是工廠方法模式所創(chuàng)

11、建的對象的父類，或它們共同擁有的接口。抽象產(chǎn)品角色可以用接口或者抽象類實現(xiàn)。 具體產(chǎn)品（Concrete Product）角色：工廠方法模式所創(chuàng)建的任何對象都是這個角色的實例，具體產(chǎn)品角色由一個具體類實現(xiàn)。角色與結構Creator 類的源代碼public class Creator/* * 靜態(tài)工廠方法 */ public static Product factory() return new ConcreteProduct(); 實現(xiàn)例子/java中的簡單工廠模式如下例 /* 手機接口 */ public interface Mobile public void call(); /* 諾基亞

12、手機 */ public class Nokia implements Mobile public void call() System.out.println(Nokia produced .); /* 摩托羅拉手機 */ public class Motorola implements Mobile public void call() System.out.println(Motorola produced .); /* 簡單工廠模式中的核心部分:工廠類 */ public class SimpleFactory public static Mobile createMobile(Str

13、ing mobileName) if(mobileName.equals(NOKIA) new Nokia(); else if(mobileName.equals(MOTOROLA) new Motorola(); else throw new Exception(還不支持該種類型的手機生產(chǎn)！); /*客戶端測試 */ public class Client public static void main(String args) Mobile mobile = SimpleFactory.createMobile(NOKIA) ; mobile.cell() ; /創(chuàng)建Nokia ; mo

14、bile = SimpleFactory.createMobile(MOTOROLA) ; /接口回調 mobile.cell() ; /創(chuàng)建Motorola ; 對前面的Sample來說，可以建立一個專門生產(chǎn)Sample實例的工廠: public class Factory public static Sample creator(int which) if (which=1) return new SampleA(); else if (which=2) return new SampleB(); 如果要實例化Sample時，就可以就使用 Sample sampleA=Factory.cr

15、eator(1); 工廠類是整個模式的關鍵.包含了必要的邏輯判斷,根據(jù)外界給定的信息,決定究竟應該創(chuàng)建哪個具體類的對象.通過使用工廠類,外界可以從直接創(chuàng)建具體產(chǎn)品對象的尷尬局面擺脫出來,僅僅需要負責“消費”對象就可以了。而不必管這些對象究竟如何創(chuàng)建及如何組織的明確了各自的職責和權利，有利于整個軟件體系結構的優(yōu)化。 簡單工廠模式通過這種做法實現(xiàn)了對責任的分割。模式優(yōu)點 由于工廠類集中了所有實例的創(chuàng)建邏輯，違反了高內(nèi)聚責任分配原則，將全部創(chuàng)建邏輯集中到了一個工廠類中；它所能創(chuàng)建的類只能是事先考慮到的，如果需要添加新的類，則就需要改變工廠類了。 當系統(tǒng)中的具體產(chǎn)品類不斷增多時候，可能會出現(xiàn)要求工廠類

16、根據(jù)不同條件創(chuàng)建不同實例的需求這種對條件的判斷和對具體產(chǎn)品類型的判斷交錯在一起，很難避免模塊功能的蔓延，對系統(tǒng)的維護和擴展非常不利； 模式的缺點功能的擴展體現(xiàn)在引進新的產(chǎn)品上?！伴_閉”原則要求系統(tǒng)允許當新的產(chǎn)品加入系統(tǒng)中，而無需對現(xiàn)有代碼進行修改。這一點對于產(chǎn)品的消費角色是成立的，而對于工廠角色是不成立的。觀察對于產(chǎn)品消費角色來說，任何時候需要某種產(chǎn)品，只需向工廠角色請求即可。而工廠角色在接到請求后，會自行判斷創(chuàng)建和提供哪一個產(chǎn)品。所以，產(chǎn)品消費角色無需知道它得到的是哪一個產(chǎn)品；換言之，產(chǎn)品消費角色無需修改就可以接納新的產(chǎn)品。對于工廠角色來說，增加新的產(chǎn)品是一個痛苦的過程。工廠角色必須知道每一

17、種產(chǎn)品，如何創(chuàng)建它們，以及何時向客戶端提供它們。換言之，接納新的產(chǎn)品意味著修改這個工廠角色的源代碼。簡單工廠角色只在有限的程度上支持“開閉”原則。觀察在JAVA中的應用1.java.text.DateFormat類中的getDateIntance方法.2.SAX2庫中的XMLReaderFactory等.3.大部分的單例模式工廠方法模式是類的創(chuàng)建模式，又叫做虛擬構造子（Virtual Constructor）模式或者多態(tài)性工廠（Polymorphic Factory）模式。工廠方法模式的用意是定義一個創(chuàng)建產(chǎn)品對象的工廠接口，將實際創(chuàng)建工作推遲到子類中。工廠方法模式在簡單工廠模式中，一個工廠類處

18、于對產(chǎn)品類實例化的中心位置上，它知道每一個產(chǎn)品，它決定哪一個產(chǎn)品類應當被實例化。這個模式的優(yōu)點是允許客戶端相對獨立于產(chǎn)品創(chuàng)建的過程，并且在系統(tǒng)引入新產(chǎn)品的時候無需修改客戶端，也就是說，它在某種程度上支持“開-閉”原則。這個模式的缺點是對“開-閉”原則的支持不夠，因為如果有新的產(chǎn)品加入到系統(tǒng)中去，就需要修改工廠類，將必要的邏輯加入到工廠類中。工廠方法模式的引進簡單工廠模式的優(yōu)缺點工廠方法模式是簡單工廠模式的進一步抽象和推廣。由于使用了多態(tài)性，工廠方法模式保持了簡單工廠模式的優(yōu)點，而且克服了它的缺點。工廠方法模式工廠方法模式的簡略類圖在工廠方法模式中，核心的工廠類不再負責所有的產(chǎn)品的創(chuàng)建，而是將具

19、體創(chuàng)建的工作交給子類去做。這個核心類則搖身一變，成為了一個抽象工廠角色，僅負責給出具體工廠子類必須實現(xiàn)的接口，而不接觸哪一個產(chǎn)品類應當被實例化這種細節(jié)。這種進一步抽象化的結果，使這種工廠方法模式可以用來允許系統(tǒng)在不修改具體工廠角色的情況下引進新的產(chǎn)品工廠方法模式工廠方法模式的結構抽象工廠（Creator）角色：擔任這個角色的是工廠方法模式的核心，它是與應用程序無關的。任何在模式中創(chuàng)建對象的工廠類必須實現(xiàn)這個接口。在上面的系統(tǒng)中這個角色由接口Creator 扮演；在實際的系統(tǒng)中，這個角色也常常使用抽象類實現(xiàn)。結構與角色具體工廠（Concrete Creator）角色：擔任這個角色的是實現(xiàn)了抽象工

20、廠接口的具體類。具體工廠角色含有與應用密切相關的邏輯，并且受到應用程序的調用以創(chuàng)建產(chǎn)品對象。在本系統(tǒng)中給出了兩個這樣的角色，也就是具體Java 類ConcreteCreator1 和ConcreteCreator2。結構與角色抽象產(chǎn)品（Product）角色：工廠方法模式所創(chuàng)建的對象的超類型，也就是產(chǎn)品對象的共同父類或共同擁有的接口。在本系統(tǒng)中，這個角色由接口Product 扮演；在實際的系統(tǒng)中，這個角色也常常使用抽象類實現(xiàn)。結構與角色具體產(chǎn)品（Concrete Product）角色：這個角色實現(xiàn)了抽象產(chǎn)品角色所聲明的接口。工廠方法模式所創(chuàng)建的每一個對象都是某個具體產(chǎn)品角色的實例。在本系統(tǒng)中，這

21、個角色由具體類CocnreteProduct1 和oncreteProduct2 扮演，它們都實現(xiàn)了接口Product。結構與角色Client 對象的活動可以分成兩部分。（1）客戶端創(chuàng)建ConcreteCreator1 對象。這時客戶端所持有變量的靜態(tài)類型是Creator，而實際類型是ConcreteCreator1。然后，客戶端調用ConcreteCreator1 對象的工廠方法factory()，接著后者調用ConcreteProduct1 的構造子創(chuàng)建出產(chǎn)品對象。如下面的時序圖所示。工廠方法模式的活動序列圖工廠方法模式的活動序列圖工廠方法模式和簡單工廠模式在結構上的不同是很明顯的。工廠方

22、法模式的核心是一個抽象工廠類，而簡單工廠模式把核心放在一個具體類上。工廠方法模式可以允許很多具體工廠類從抽象工廠類中將創(chuàng)建行為繼承下來，從而可以成為多個簡單工廠模式的綜合，進而推廣了簡單工廠模式。比較工廠方法模式退化后可以變得很像簡單工廠模式。設想如果非常確定一個系統(tǒng)只需要一個具體工廠類，那么就不妨把抽象工廠類合并到具體的工廠類中去。由于反正只有一個具體工廠類，所以不妨將工廠方法改成為靜態(tài)方法，這時候就得到了簡單工廠模式。比較與簡單工廠模式中的情形一樣的是，ConcreteCreator 的factory() 方法返還的數(shù)據(jù)類型是一個抽象類型Product，而不是哪一個具體產(chǎn)品類型，而客戶端也

23、不必知道所得到的產(chǎn)品的真實類型。這種多態(tài)性設計將工廠類選擇創(chuàng)建哪一個產(chǎn)品對象、如何創(chuàng)建這個對象的細節(jié)完全封裝在具體工廠類內(nèi)部。工廠方法模式之所以有一個別名叫多態(tài)性工廠模式，顯然是因為具體工廠類都有共同的接口，或者都有共同的抽象父類。觀察如果系統(tǒng)需要加入一個新的產(chǎn)品，那么所需要的就是向系統(tǒng)中加入一個這個產(chǎn)品類以及它所對應的工廠類。沒有必要修改客戶端，也沒有必要修改抽象工廠角色或者其他已有的具體工廠角色。對于增加新的產(chǎn)品類而言，這個系統(tǒng)完全支持“開-閉”原則。觀察例在JAVA語言的API中的應用1.java.util.Collection接口中的iterator()方法,返回的是一個Iterato

24、r類型的對象.2.List接口中的iterator()方法和listIterator()方法.3.Com架構中的IClassFactory和CFactory類.4.EJB中的Home接口.5.JMS中的TopicConnectionFactory等.抽象工廠模式是所有形態(tài)的工廠模式中最為抽象和最具一般性的一種形態(tài)。抽象工廠(Abstract Factory)模式抽象工廠模式簡略類圖左邊的等級結構代表工廠等級結構，右邊的兩個等級結構分別代表兩個不同的產(chǎn)品的等級結構。抽象工廠模式可以向客戶端提供一個接口，使得客戶端在不必指定產(chǎn)品的具體類型的情況下，創(chuàng)建多個產(chǎn)品族中的產(chǎn)品對象。這就是抽象工廠模式的用

25、意。說明抽象工廠模式抽象工廠模式與工廠方法模式的最大區(qū)別就在于，工廠方法模式針對的是一個產(chǎn)品等級結構；而抽象工廠模式則需要面對多個產(chǎn)品等級結構抽象工廠模式產(chǎn)品族，是指位于不同產(chǎn)品等級結構中，功能相關聯(lián)的產(chǎn)品組成的家族。比如在下圖中，箭頭所指就是三個功能相關聯(lián)的產(chǎn)品，它們位于三個不同的等級結構中的相同位置上，組成一個產(chǎn)品族。產(chǎn)品族產(chǎn)品族如果采用工廠方法模式，就勢必要使用三個獨立的工廠等級結構來對付這三個產(chǎn)品等級結構。由于這三個產(chǎn)品等級結構的相似性，會導致三個平行的工廠等級結構。隨著產(chǎn)品等級結構的數(shù)目增加，工廠方法模式所給出的工廠等級結構的數(shù)目也會隨之增加。抽象工廠模式抽象工廠模式設計抽象工廠（A

26、bstractFactory）角色：擔任這個角色的是工廠方法模式的核心，它是與應用系統(tǒng)的商業(yè)邏輯無關的。通常使用Java 接口或者抽象Java 類實現(xiàn)，而所有的具體工廠類必須實現(xiàn)這個Java 接口或繼承這個抽象Java 類。結構與角色具體工廠類（Concrete Factory）角色：這個角色直接在客戶端的調用下創(chuàng)建產(chǎn)品的實例。這個角色含有選擇合適的產(chǎn)品對象的邏輯，而這個邏輯是與應用系統(tǒng)的商業(yè)邏輯緊密相關的。通常使用具體Java 類實現(xiàn)這個角色。結構與角色抽象產(chǎn)品（Abstract Product）角色：擔任這個角色的類是工廠方法模式所創(chuàng)建的對象的父類，或它們共同擁有的接口。通常使用Java

27、接口或者抽象Java 類實現(xiàn)這一角色。結構與角色具體產(chǎn)品（Concrete Product）角色：抽象工廠模式所創(chuàng)建的任何產(chǎn)品對象都是某一個具體產(chǎn)品類的實例。這是客戶端最終需要的東西，其內(nèi)部一定充滿了應用系統(tǒng)的商業(yè)邏輯。通常使用具體Java 類實現(xiàn)這個角色。結構與角色抽象工廠模式的起源 將一組算法中的每個算法封裝到具有共同接口的獨立類中，使得它們可以相互替換。1使用策略模式的時機 多個類之間的區(qū)別僅在于它們的行為，使用策略模 式可以動態(tài)地選擇一種行為。 一個系統(tǒng)需要動態(tài)地在幾種算法中選擇一種。 一個系統(tǒng)的算法使用的數(shù)據(jù)不可以讓客戶端知道。 避免使用難以維護的多重條件選擇語句，體現(xiàn)面向 對象設計

28、的概念。策略模式（Strategy） 策略模式的結構策略模式涉及到三個角色： 語境（Context）角色：持有策略類Strategy的引用。 抽象策略（Strategy）角色：這是一個接口或抽象類。 具體策略（ConcreteStrategy）角色：以Strategy接口實現(xiàn)某個具體算法。實例分析例子：在一個販賣各種書籍的電子商務網(wǎng)站中，針對不同的書有不同的折扣.有些書不提供折扣；.有些書有一個固定折扣額；.有些書提供百分比折扣；實例分析策略模式的優(yōu)點有： 策略模式提供了管理相關的算法族的辦法。避免重復 的代碼。 策略模式提供了可以替換繼承關系的辦法。使其不可 能動態(tài)改變算法或行為。 使用策略

29、模式可以避免使用多重條件轉移語句。策略模式的缺點有： 客戶端必須知道所有的策略類，并自行決定使用哪一 個策略類。 策略模式造成很多的策略類。策略模式的優(yōu)點和缺點典型的應用1.AWT中的LayoutManger中的各種GUI構件的排列方式:BorderLayer,FlowLayout, GridLayout,GridBayLayout等2.例如酒店客房的費用折扣計算3.常見的排序,例如二元排序,冒泡排序,堆棧排序,快速排序等.MVC概述WEB應用的兩種開發(fā)模式MVC操作順序MVC優(yōu)點MVC的適用性設計模式-MVC模式視圖控制器控制器模型int value=1MVC概述設計模式-實例:MVC模式M

30、VC模式最初使用SmallTalk開發(fā)，后來在Swing組件庫中廣泛應用。該模式采用一個圖形化對象并將其任務分解成三部分:控制器：觸發(fā)一個對組件的改變。模型：提供修改、訪問數(shù)據(jù)的方法。視圖：提供當前數(shù)據(jù)的直觀顯示。MVC概述設計模式-實例:MVC模式JSP + JavaBean設計模式-實例:MVC模式Model1的主要特點表現(xiàn)層用HTML或JSP。JSP文件還負責所有的業(yè)務和處理邏輯JSP直接用代碼訪問數(shù)據(jù)或JSP通過JavaBean存取數(shù)據(jù)。以頁面為中心，應用程序的業(yè)務邏輯和程序流程都在頁面中出現(xiàn)。JSP要跳轉到別的頁面，通過超級鏈接或Form表單的action實現(xiàn)。設計模式-實例:MVC

31、模式JSP不僅負責表示邏輯，還負責控制邏輯大型項目中如果采取此方式，每個開發(fā)小組必須了解其它小組開發(fā)的所有頁面的詳細信息，否則對頁面的修改將會破壞應用程序的流程。當輸出設備不同時（比如股票信息輸出到顯示器、手機、PDA上），需要采用不同的輸出格式(即不同的視圖)，那么用此方式JSP不僅要判定設備的類型，而且要為不同類型的設備提供正確的顯示格式。Model1的缺點設計模式-實例:MVC模式JSP + JavaBean +Servlet設計模式-實例:MVC模式MVC模型在一個典型的J2EE Web應用中，MVC設計模式包括三個部分：模型（Model）: 用于封裝數(shù)據(jù)，一般是關系數(shù)據(jù)庫或EJB。視

32、圖（View）: 數(shù)據(jù)的表現(xiàn)組件，通常就是JSP頁面，也可以是GUI，可以有多個。控制器（Controller）: 接受用戶動作，負責統(tǒng)一管理。一般是Servlet。在一個典型的企業(yè)級應用中，經(jīng)常需要用多種類型的接口來支持多種類型的用戶。比如，一個網(wǎng)上商店可能需要:為網(wǎng)上顧客提供HTML前端，為無線用戶提供WML前端，為系統(tǒng)管理員提供JFC/Swing GUI，為供應商提供基于XML的Web service。MVC模型HTMLViewWMLViewJFC/SwingViewXML-basedView企業(yè)信息系統(tǒng)傳統(tǒng)Web用戶無線用戶系統(tǒng)管理員B2B用戶Model含有應用程序的功能核心，表示應用程序的狀態(tài)，它不管View和