軟件工程概述及設計模式課件(PPT 112頁)

1、目錄1OO概述4常用設計模式3OO六大原則2面向接口編程.第1頁，共112頁。1 OO概述面向對象分析(OOA)做什么？從問題域中獲取需要的類和對象，以及它們之間的關系。面向對象設計(OOD)怎么做？面向對象編程(OOP)Do it.第2頁，共112頁。1 OO概述老張開車去東北。請用OO思想進行分析(OOA)和設計(OOD),體現(xiàn)OO三大特性封裝類(名詞)：.第3頁，共112頁。1 OO概述老張開車去東北。請用OO思想進行分析(OOA)和設計(OOD)。封裝類(名詞)：.第4頁，共112頁。1 OO概述老張開車去東北。封裝創(chuàng)建成員方法。.第5頁，共112頁。1 OO概述老張開車去東北。獲取屬

2、性，完善成員方法。.第6頁，共112頁。1 OO概述老張開車去東北。封裝:作用？隱藏信息，降低類間耦合性。.第7頁，共112頁。1 OO概述老張開車去東北。初始設計.第8頁，共112頁。1 OO概述public class Driver private String driverName;public String getName() return driverName;public void drive(Car car) car.go(new Address(東北);.第9頁，共112頁。1 OO概述public class Carpublic void go(Address dest) S

3、ystem.out.println(一路哼著歌，冒著煙，去了 + dest.getName();.第10頁，共112頁。1 OO概述public class Address private String addressName;public String getName() return addressName ;public void setName(String name) addressName = name;.第11頁，共112頁。1 OO概述老張開車去東北。設計優(yōu)化：繼承和多態(tài)在某個粒度視圖層面上對同類事物不加區(qū)別的對待而統(tǒng)一處理.第12頁，共112頁。1 OO概述public cl

4、ass Driver private String driverName;public String getName() return driverName;public void setName(String name) driverName = name;/Vihecle vihecle = new Car();public void drive(Vihecle vihecle) vihecle.go(new Address(東北);.第13頁，共112頁。1 OO概述public abstract class Vihecle public abstract void go(Address

5、 dest);public class Car extends Viheclepublic void go(Address dest) System.out.println(一路哼著歌，冒著煙，去了 + dest.getName();public class Plane extends Viheclepublic void go(Address dest) System.out.println(“一路駕著云彩去了 + dest.getName();.第14頁，共112頁。1 OO概述public class Address private String addressName;public A

6、ddress(String name) addressName = name;public String getName() return addressName ;public void setName(String name) addressName = name;.第15頁，共112頁。1 OO概述public class Clientpublic static void main(String args) Driver d = new Driver();d.setName(老張); /d.drive(new Plane();d.drive(new Car();有什么缺陷？.第16頁，共

7、112頁。1 OO概述持續(xù)優(yōu)化：添加而不修改，系統(tǒng)擴展性強！重載.第17頁，共112頁。2 面向接口編程面試題:1.抽象類可以有構造方法,接口不可以.2.抽象類中可以有普通成員變量,普通方法.接口不可以.3.抽象類中的抽象方法的訪問類型不能是private訪問類型,但接口的抽象方法只能是public.4.抽象類可以包含靜態(tài)方法,但接口不可以.5. 抽象類中靜態(tài)成員變量的訪問類型可以任意.但接口只能是Public(static)final類型.6.一個類可以實現(xiàn)多個接口,但只能繼承一個抽象類.1 abstract class和interface有什么區(qū)別?.第18頁，共112頁。2 面向接口編程

8、設計層面：抽象類是某種抽象事物(is a)。接口是一組行為規(guī)范(like a)。接口體現(xiàn)了 “如果你是則必須能”的理念語法層面：抽象類體現(xiàn)單繼承關系；接口可實現(xiàn)多繼承。.第19頁，共112頁。2 面向接口編程.第20頁，共112頁。2 面向接口編程面試題（擴展題）:2.1 接口是否可以繼承接口? 2.2 接口是否可以繼承抽象類？2.3 抽象類是否可以實現(xiàn)接口? 2.4 抽象類是否可以繼承具體類? 2.5 抽象類中是否可以有靜態(tài)的main方法? 抽象類與普通類的唯一區(qū)別就是不能創(chuàng)建實例對象和允許有abstrct方法!.第21頁，共112頁。2 面向接口編程面向接口編程：在系統(tǒng)分析和架構中，分清層

9、次和依賴關系，下層不是直接向其上層提供服務：即不是直接實例化在上層中，而是通過定義一組接口，僅向上層暴露其接口功能，上層對于下層僅僅是接口依賴，而不依賴具體類。 系統(tǒng)層次間協(xié)作關系是系統(tǒng)設計的關鍵 ，小到不同類之間的通信，大到各模塊之間的交互 。本質：面向抽象編程，定義與實現(xiàn)的分離。.第22頁，共112頁。2.1.1 設計模式四人幫GoF（“四人幫”，又稱Gang of Four，即Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides四人）的設計模式，原名Design Patterns: Elements of Reusable O

10、bject-Oriented Software，第一次將設計模式提升到理論高度，并將之規(guī)范化。該書提出了23種基本設計模式。 .第23頁，共112頁。3.8 六大原則總覽.第24頁，共112頁。3.1 單一職責原則(SRP)單一職責原則(SingleResponsibilityPrinciple )定義：應該有且僅有一個原因引起類的變更。通俗言之：一個類只負責一個職責。單一職責原則:實現(xiàn)高內聚、低耦合的指導方針。問題由來：類T負責兩個不同的職責：職責P1，職責P2。則職責P1需求發(fā)生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發(fā)生故障?？偨Y：接口一定要做到單一職責，類的設計盡量

11、做到一個原因引起變化就行。.第25頁，共112頁。3.2 接口隔離原則(ISP)接口隔離原則(Interface Segregation Principle)定義：1、客戶端不應該依賴它不需要的接口。2、類間的依賴關系應該建立在最小的接口上。通俗言之：不要建立臃腫龐大的接口 。與單一原則的區(qū)別單一職責要求的是類和接口單一，注重的是職責，這是業(yè)務邏輯上的劃分。而接口隔離原則要求接口的方法盡量少。.第26頁，共112頁。3.2 接口隔離原則(ISP)Eg:設計門的類abstract Doorabstract void Open();abstract void Close();.第27頁，共112頁

12、。3.2 接口隔離原則(ISP)新需求：需要門具有報警功能。解決方案一：在抽象類(或接口)Door添加alarm方法。abstract Doorabstract void Open();abstract void Close();abstract void Alarm();.第28頁，共112頁。3.2 接口隔離原則(ISP)問題？違背ISP(接口隔離原則)，Alarm方法對于依賴Door的模塊是多余的。修改方案：abstact Door保留Open()、Close(),Alarm由子類擴展。拆分成interface Door和interface Alarm接口。拆分成abstact Door

13、和interface Alarm。.第29頁，共112頁。3.2 接口隔離原則(ISP)abstract Doorabstract void Open();abstract void Close();Interface Alarmablevoid Alarm();class AlarmDoor extends Door implents Alarmable.第30頁，共112頁。3.3 里氏替換原則(LSP)里氏替換原則(Liskov Substitution Principle)定義：所有引用基類的地方必須能透明地使用其子類的對象。 通俗言之：任何父類出現(xiàn)的地方，子類一定可以出現(xiàn)。在程序中盡

14、量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象?？偨Y：子類可以擴展父類的功能，但不能改變父類原有的功能.第31頁，共112頁。3.4 依賴倒置原則(DIP)依賴倒置原則(Dependence Inversion Principle )定義：1、高層模塊不應該依賴低層模塊，兩者都應該依賴于抽象（抽象類或接口）。2、抽象（抽象類或接口）不應該依賴于細節(jié)（具體實現(xiàn)類）。3、細節(jié)（具體實現(xiàn)類）應該依賴抽象。通俗言之：依賴抽象，不依賴實現(xiàn)。總結：面向接口編程.第32頁，共112頁。3.5 開閉原則(OCP)開閉原則(Open Close Principle)定義：一

15、個軟件實體如類、模塊和函數(shù)，應該對擴展開放，對修改關閉。通俗言之：一個好的系統(tǒng)是在不修改已有源代碼的情況下,可以擴展功能。實現(xiàn)開閉原則的關鍵就是抽象化。.第33頁，共112頁。3.5 開閉原則(OCP)在開-閉原則中,不允許修改的是抽象的類或者接口,允許擴展的是具體的實現(xiàn)類,抽象類和接口在開-閉原則中扮演著極其重要的角色。模板方法模式和觀察者模式都是開閉原則的極好體現(xiàn)。.第34頁，共112頁。3.6 合成復用原則(CRP)合成復用原則(Composite ReusePrinciple ，CARP)：要優(yōu)先使用對象組合（聚合）通俗言之：要盡量使用合成/聚合，盡量不要使用繼承。繼承復用：從基類繼承

16、而來的實現(xiàn)是靜態(tài)的，不可能在運行時發(fā)生改變，沒有足夠的靈活性；破壞封裝性，把父類實現(xiàn)細節(jié)直接暴露給子類（白箱復用）；父類發(fā)生改變，子類也應改變，類與類之間高耦合。.第35頁，共112頁。3.6 合成復用原則(CRP)組合/聚合復用：耦合度相對較低，可以在運行時動態(tài)進行。黑箱復用！如果兩個類之間是“Has-A”的關系應使用組合或聚合，如果是“Is-A”關系可使用繼承。橋接模式遵循該原則！.第36頁，共112頁。3.6 合成復用原則(CRP).第37頁，共112頁。3.6 合成復用原則(CRP).第38頁，共112頁。3.7 迪米特原則(LOD)迪米特原則(Law Of Demeter)定義：指一

17、個對象應該對于其他對象有最少的了解 。問題由來：類與類之間的關系越密切，耦合度越大，當一個類發(fā)生改變時，對另一個類的影響也越大。通俗言之：不要跟陌生人說話。類應該對自己需要耦合或調用的類知道得越少越好 。.第39頁，共112頁。2.1.2 設計模式概述設計模式（Design pattern）是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結。 為何提倡設計模式？根本原因是為了代碼復用，增加可維護性 。設計模式有助于對框架結構的理解，成熟的框架通常使用了多種設計模式。設計模式通過實現(xiàn)面向對象六大原則，從而達到了代碼復用、增加可維護性的目的。 .第40頁，共112頁。2.2.1 設

18、計模式基本元素模式名稱問題解決方案效果.第41頁，共112頁。2.2.2 設計模式分類設計模式分為三種類型，共23類。 創(chuàng)建型模式：單例模式、抽象工廠模式、建造者模式、工廠模式、原型模式。 結構型模式：適配器模式、橋接模式、裝飾模式、組合模式、外觀模式、享元模式、代理模式。 行為型模式：模版方法模式、命令模式、迭代器模式、觀察者模式、中介者模式、備忘錄模式、解釋器模式、狀態(tài)模式、策略模式、職責鏈模式、訪問者模式。 .第42頁，共112頁。2.3.1設計模式之單例模式（Singleton）單例設計模式的特點：1.單例設計模式保證一個類只有一個實例;2.要提供一個訪問該類對象實例的全局訪問點。單例

19、模式最重要的就是要保證一個類只有一個實例并且這個類易于被訪問。一個全局類使得一個對象可以被訪問，但是這樣做卻不能防止你實例化多個對象。.第43頁，共112頁。2.3.1 設計模式之單例模式（Singleton）單例設計模式的實現(xiàn)：1.為了避免其它程序過多的建立該類的對象，先禁止其它程序建立該類對象實例（將構造器私有化）。2.為了方便其它程序訪問該類的對象，只好在本類中自定義一個對象，由1可知該對象是static的，并對外提供訪問方式。.第44頁，共112頁。2.3.1 設計模式之單例模式（Singleton）單例模式具體實現(xiàn)有兩種：懶漢式 class Singleton private sta

20、tic Singleton instance=null; private Singleton() public static Singleton getInstance() if(instance=null) instance=new Singleton(); return instance; .第45頁，共112頁。2.3.1 設計模式之單例模式（Singleton）餓漢式 class Singleton private static Singleton instance=new Singleton(); private Singleton() public static Singleton

21、 getInstance() return instance; .第46頁，共112頁。2.3.1 設計模式之單例模式（Singleton）餓漢式(總結) 對象預先加載，線程是安全的，在類創(chuàng)建好的同時對象生成，調用獲得對象實例的方法反應速度快，代碼簡練。懶漢式(總結) 對象延遲加載，效率高，只有在使用的時候才實例化對象，若設計不當線程會不安全，代碼相對于餓漢式復雜，第一次加載類對象的時候反應不快。.第47頁，共112頁。2.3.1 設計模式之多例模式（Multiton Pattern）class Multiton private static Multiton multi1=new Multi

22、ton(); private static Multiton multi2=new Multiton(); private Singleton() public static Singleton getInstance(int value) if(1=value)return multi1;elsereturn multi2; /多例模式：單例模式的推廣。.第48頁，共112頁。2.3.1 設計模式之多例模式（Multiton Pattern）class Multiton private static List list = new ArraryList(); private static M

23、ultiton multi1=new Multiton(); private static Multiton multi2=new Multiton(); private static final int maxCount = 2;/最多的實例數(shù) static list.add(multi1); list.add(multi2); private Singleton() public static Singleton getInstance(int value) return list.get(index); /多例模式：單例模式的推廣。.第49頁，共112頁。2.3.2 工廠模式（Facto

24、ry）工廠模式在java與模式中分為三類：簡單工廠模式(靜態(tài)工廠Simple Factory)工廠方法模式(Factory Method)抽象工廠模式(Abstract Factory)GOF在設計模式一書中，將簡單工廠模式看做特殊的工廠方法模式。.第50頁，共112頁。2.3.2 工廠模式（Factory）簡單工廠模式(靜態(tài)工廠Simple Factory)Creater(工廠角色):是簡單工廠的核心。工廠角色可被外部直接調用，創(chuàng)建所需產品對象。Product(抽象產品角色)：具體產品類的父類。ConcreteProduct(具體產品類)。.第51頁，共112頁。2.3.2 工廠模式（Fac

25、tory）public class Creater /靜態(tài)工廠模式public static Dog CreateDog(String dogName)throws Exceptionif(carName.equalsIgnoreCase(“TaiDi)return new TaiDi();else if(carName.equalsIgnoreCase(“MuYang)return new MuYang(); public abstract Dogpublic void run();.第52頁，共112頁。2.3.2 工廠模式（Factory） public Taidi extends Do

26、gpublic MuYang extends Dog.第53頁，共112頁。2.3.2 工廠模式（Factory）public class Clientpublic static void main(String args)/Dog dog= new TaiDi();/Dog dog = new MuYang();Dog dog = Creater.CreateDog(“TaiDi);.第54頁，共112頁。2.3.2 工廠模式（Factory）靜態(tài)工廠在創(chuàng)建產品時，通常結合反射一起使用。public class Creater /靜態(tài)工廠模式public static TaiDi Creat

27、eDog(String carName)throws Exception TaiDi taidiDog = (TaiDi) Class.forName(“zhong.xxx + carName).newInstance();return taidiDog ;問題簡單工廠為什么要用靜態(tài)方法實現(xiàn)？靜態(tài)方法的繼承問題？缺點：對于新產品的加入創(chuàng)建，無能為力！違背開閉原則！.第55頁，共112頁。2.3.2 工廠模式（Factory）工廠方法模式(Factory Method)簡單工廠模式對增加新產品，無能為力，不符合開閉原則(對擴展開發(fā)，對修改封閉)。工廠方法模式是對簡單工廠模式的抽象.第56頁，共1

28、12頁。2.3.2 工廠模式（Factory）public abstract class Factory Dog getInstance(); public class TaiDiFactory implements Factory public Dog getInstance() return new TaiDi (); public class MuYangFactory implements Factory public Dog getInstance() return new MuYang (); CreaterConcreteCreaterConcreteCreater.第57頁，共

29、112頁。2.3.2 工廠模式（Factory）public abstract class Dogpublic abstract void run();public class TaiDi extends Dogpublic class MuYang extends Dogpublic void run() public void doAfraid()System.out.println(“我是MuYang我怕誰！”);ProductConcreteProductConcreteProduct.第58頁，共112頁。2.3.2 工廠模式（Factory）public static void m

30、ain(String args) Factory factory = new TaiDiFatory(); Dog dog = factory. getInstance(); dog . run(); /dog.doAfraid(); 哪些情況使用工廠模式？1) 當客戶程序不需要知道要使用對象的創(chuàng)建過程。 2) 客戶程序使用的對象存在變動的可能，或者根本就不知道使用哪一個具體的對象。.第59頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。 .第60頁，共112頁。2.3.3 抽象工廠模式（Abstr

31、act Factory）1.AbstractFactory 聲明一個創(chuàng)建抽象產品對象的操作接口。2.ConcreteFactory 實現(xiàn)創(chuàng)建具體產品對象的操作。 3.AbstractProduct 為一類產品對象聲明一個接口。 4.ConcreteProduct 定義一個將被相應的具體工廠創(chuàng)建的產品對象,實現(xiàn)AbstractProduct接口。 5.Client 僅使用由AbstractFactory和AbstractProduct類聲明的接口 .第61頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）AbstractFactory:public interface

32、AbstractFactory public Car CreateBmwCar();public Car CreateBenzCar(); .第62頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）ConcreteFactory:class ConcreteSportFactory implents AbstractFactory public Car CreateSportBmwCar()return new BmwSportsCar();public ISporting CreateSportBenzCar()return new BenzSportsCar();

33、.第63頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）AbstractProduct:public abstract Car void go(); .第64頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）ConcretePorduct:public class BmwSportsCar extend Car public void go() System.out.println( BmwSportsCar run!); public class BenzSportsCar extend Car public void go() Syst

34、em.out.println( BenzSportsCar run!); .第65頁，共112頁。2.3.3 抽象工廠模式（Abstract Factory）Client:public static void main(String args) AbstractFactory sportCarFactory = new ConcreteSportFactory (); Car car = sportCarFactory . CreateSportBmwCar(); /Car car = sportCarFactory . CreateSportBenzCar(); 能不能把增加產品家族數(shù)量？.

35、第66頁，共112頁。2.3.4 外觀模式(Facade)Facade模式.第67頁，共112頁。2.3.4 外觀模式(Facade)Facade模式：1 定義了一個更高的接口，使子系統(tǒng)更加容易使用；2 為子系統(tǒng)中的一組接口提供一個統(tǒng)一的接口。.第68頁，共112頁。2.3.4 外觀模式(Facade)Eg:開關電腦模擬程序(見開關電腦模擬程序文檔).第69頁，共112頁。2.3.4 外觀模式(Facade)核心思想：封裝交互，簡化調用(化繁為簡)！作用：外部減少與子系統(tǒng)內多個模塊的交互，松散耦合；讓外部能夠更簡單的使用子系統(tǒng)；大大節(jié)省學習時間。.第70頁，共112頁。2.3.5 適配器模式(

36、Adapter)Adapter模式（結構型）1 將一個類的接口轉換成客戶希望的另外一個接口;2 使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。 Eg1 :電源適配器.第71頁，共112頁。2.3.5 適配器模式(Adapter)Eg2:android email顯示一個ListView的使用涉及了兩個部分，一個是數(shù)據(jù)源DataSource，另外一個是數(shù)據(jù)源的各項的布局顯示ItemLayout。DataSource是不能直接展示在用戶面前，ItemLayout才是直接用戶，DataSource向ItemLayout填充和轉換就是一個典型的適配過程，就需要一個適配器對象來參與其中。 .

37、第72頁，共112頁。2.3.5 適配器模式(Adapter)示例程序(見Adapter-獲取電壓程序).第73頁，共112頁。2.3.5 適配器模式(Adapter)Adapter模式（結構型）它不是為了解決還處在開發(fā)階段的問題，而是解決正在服役的項目問題。解決接口不相容的問題：復用代碼，不修改原有代碼。缺點：對于對象適配器來說，更換適配器的實現(xiàn)過程比較復雜。對象適配器和類適配器？.第74頁，共112頁。2.3.6 職責鏈模式(COR)職責鏈(Chain of Responsibility):行為型發(fā)送方發(fā)送一個請求，使多個對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關系。將

38、這些對象連成一條鏈， 并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。 核心思想：給多個對象處理一個請求的機會，從而解耦發(fā)送者和接受者 。.第75頁，共112頁。2.3.6 職責鏈模式(COR)適用范圍1 有多個對象可以處理同一個請求2 不能明確指定接收者.第76頁，共112頁。2.3.6 職責鏈模式(COR)Eg1:公司請假Eg2:brew平臺消息機制Eg3:java 異常處理trycatch(Exception e1) catch(Exception e2) finally .第77頁，共112頁。2.3.6 職責鏈模式(COR).第78頁，共112頁。2.3.7 觀察者模式(Obser

39、ver)觀察者模式:定義對象間的一種一對多的依賴關系,當一個對象的狀態(tài)發(fā)生改變時, 所有依賴于它的對象都得到通知并被自動更新。 觀察者中涉及了兩個對象，一個是觀察目標，一個是觀察者。觀察目標有典型的3個方法： 訂閱，取消訂閱，通知。訂閱： 增加狀態(tài)或事件通知的對象取消訂閱： 刪除狀態(tài)或事件通知對象通知： 通知所有訂閱了狀態(tài)和事件的對象。.第79頁，共112頁。2.3.7 觀察者模式(Observer)Eg:雜志訂閱，雜志是主題，觀察者是訂閱者。當出版新雜志時候，這個事件會自動通知所有的訂閱者。Eg:貓和老鼠.第80頁，共112頁。2.3.7 觀察者模式(Observer)觀察者模式:定義對象間

40、的一種一對多的依賴關系,當一個對象的狀態(tài)發(fā)生改變時, 所有依賴于它的對象都得到通知并被自動更新。 觀察者中涉及了兩個對象，一個是觀察目標，一個是觀察者。觀察目標有典型的3個方法： 訂閱，取消訂閱，通知。訂閱： 增加狀態(tài)或事件通知的對象取消訂閱： 刪除狀態(tài)或事件通知對象通知： 通知所有訂閱了狀態(tài)和事件的對象。.第81頁，共112頁。2.3.8 中介者模式(Mediator)中介者模式:1 用一個中介對象來封裝一系列的對象交互;2 中介者使各對象不需要顯式地相互引用，從而使其耦合松散，而且可以獨立地改變它們之間的交互。 Eg:android-Activity與IntentDemo程序：Mediat

41、or模式-居委會大媽.第82頁，共112頁。2.3.8 中介者模式(Mediator).第83頁，共112頁。2.3.8 中介者模式(Mediator).第84頁，共112頁。2.3.8 中介者模式(Mediator)中介者模式本質： 封裝交互 何時選用中介者模式 1 如果一組對象之間的通信方式比較復雜，導致相互依賴、結構混亂;2 如果一個對象引用很多的對象，并直接跟這些對象交互，導致難以復用該對象 。.第85頁，共112頁。2.3.9 模式區(qū)別外觀模式和中介者模式1 中介者模式主要用來封裝多個對象之間相互的交互，多用在系統(tǒng)內部的多個模塊之間；而外觀模式封裝的是單向的交互 。2 在中介者模式的

42、實現(xiàn)里面，是需要實現(xiàn)具體的交互功能的；而外觀模式的實現(xiàn)里面，一般是組合調用或是轉調內部實現(xiàn)的功能，通常外觀模式本身并不實現(xiàn)這些功能。.第86頁，共112頁。2.3.9 模式區(qū)別外觀模式和單例模式通常一個子系統(tǒng)只需要一個外觀實例，所以外觀模式可以和單例模式組合使用，把Facade類實現(xiàn)成為單例 。.第87頁，共112頁。2.3.9 模式區(qū)別外觀模式和抽象工廠模式外觀模式的外觀類通常需要和系統(tǒng)內部的多個模塊交互，每個模塊一般都有自己的接口，所以在外觀類的具體實現(xiàn)里面，需要獲取這些接口，然后組合這些接口來完成客戶端的功能。 那么怎么獲取這些接口呢？就可以和抽象工廠一起使用，外觀類通過抽象工廠來獲取所

43、需要的接口，而抽象工廠也可以把模塊內部的實現(xiàn)對Facade進行屏蔽，也就是說Facade也僅僅只是知道它從模塊中獲取的它需要的功能，模塊內部的細節(jié)Facade也不知道了。.第88頁，共112頁。2.3.10 狀態(tài)模式狀態(tài)模式允許一個對象在其內部狀態(tài)改變的時候改變其行為。這個對象看上去就像是改變了它的類一樣。狀態(tài)模式把所研究的對象的行為包裝在不同的狀態(tài)對象里，每一個狀態(tài)對象都屬于一個抽象狀態(tài)類的一個子類。狀態(tài)模式的意圖是讓一個對象在其內部狀態(tài)改變的時候，其行為也隨之改變。.第89頁，共112頁。2.3.10 狀態(tài)模式天氣案例（瘋狂設計模式）.第90頁，共112頁。2.3.11 橋接模式橋接模式：

44、將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立地變化。應用場景：某個類具有兩個或兩個以上的維度變化，如果只是使用繼承將無法實現(xiàn)這種需要，或者使得設計變得相當臃腫。.第91頁，共112頁。2.3.11 橋接模式.第92頁，共112頁。2.3.11 橋接模式舉例來說：面館供應牛肉面、豬肉面，而且顧客可根據(jù)自己的口味選擇是否添加辣椒。此時就產生了一個問題，我們如何來應對這種變化：我們是否需要定義辣椒牛肉面、無辣牛肉面、辣椒豬肉面、無辣豬肉面4個子類？如果餐廳還供應羊肉面、韭菜面呢？如果添加辣椒時可選擇無辣、微辣、中辣、重辣風味呢？那程序豈非一直忙于定義子類？騰訊筆試題（）設計模式將抽象部分與它的實現(xiàn)部分相分離。A、Singleton（單例）B、Bridge（橋接）C、Comp