设计模式 lecture-6
架构师培训讲义6-类结构设计
第六章详细设计阶段的类结构设计详细设计阶段的一个十分重要的问题，就是进行类设计。
类设计直接对应于实现设计，它的设计质量直接影响着软件的质量，所以这个阶段是十分重要的。
这就给我们提出了一个问题，类是如何确定的，如何合理的规划类，这就要给我们提出一些原则，或者是一些模式。
设计模式是有关中小尺度的对象和框架的设计。
应用在实现架构模式定义的大尺度的连接解决方案中。
也适合于任何局部的详细设计。
设计模式也称之为微观架构模式。
第一节类结构设计中的通用职责分配软件模式GRASP模式（General Responsibility Assignment Software Patterns 通用职责分配软件模式）能够帮助我们理解基本的对象设计技术，并且用一种系统的、可推理的、可说明的方式来应用设计理论。
一、根据职责设计对象职责：职责与一个对象的义务相关联，职责主要分为两种类型：1）了解型（knowing）了解私有的封装数据；了解相关联的相关对象；了解能够派生或者计算的事物。
2）行为型（doing）自身执行一些行为，如建造一个对象或者进行一个计算；在其它对象中进行初始化操作；在其它对象中控制或者协调各项活动。
职责是对象设计过程中，被分配给对象的类的。
我们常常能从领域模型推理出了解型相关的职责，这是因为领域模型实际上展示了对象的属性和相互关联。
二、职责和交互图在UML中，职责分配到何处（通过操作来实现）这样的问题，贯穿了交互图生成的整个过程。
例如：所以，当交互图创建的时候，实际上已经为对象分配了职责，这体现到交互图就是发送消息到不同的对象。
三、在职责分配中的通用原则总结一下：●巧妙的职责分配在对象设计中非常重要。
●决定职责如何分配的行为常常在创建交互图的之后发生，当然也会贯穿于编程过程。
●模式是已经命名的问题/解决方案组合，它把与职责分配有关的好的建议和原则汇编成文。
四、信息专家模式解决方案：将职责分配给拥有履行一个职责所必需信息的类，也就是信息专家。
设计模式讲义
1.设计模式概述如果把修习软件开发当做武功修炼的话，那么可以分为招式和内功。
招式：Java、C#、C++等编程语言；Eclipse、Visual Studio等开发工具；JSP、等开发技术；Struts、Hibernate、JBPM等框架技术；内功：数据结构、算法、设计模式、重构、软件工程每一位软件开发人员也都希望成为一名兼具淋漓招式和深厚内功的“上乘”软件工程师，而对设计模式的学习与领悟将会让你“内功”大增，再结合你日益纯熟的“招式”，你的软件开发“功力”一定会达到一个新的境界。
招式可以很快学会，但是内功的修炼需要更长的时间。
1.1 设计模式从何而来模式之父Christopher Alexander（克里斯托弗.亚历山大）———哈佛大学建筑学博士、美国加州大学伯克利分校建筑学教授、加州大学伯克利分校环境结构研究所所长、美国艺术和科学院院士。
“每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的成功的解决方案，无须再重复相同的工作。
”——《建筑的永恒之道》by Christopher AlexanderChristopher Alexander在《建筑的永恒之道》中给出了设计模式的定义，这些话可以总结出一句话那就是：“设计模式是在特定环境下人们解决某类重复出现问题的一套成功或有效的解决方案。
”（设计模式的定义）1.2 软件设计模式又从何而来四人组（Gang of Four），简称GoFRalph Johnson，Richard Helm，Erich Gamma，John VlissidesGoF将模式的概念引入软件工程领域，这标志着软件模式的诞生。
软件模式(Software Patterns)是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。
软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件开发生命周期的每一个阶段都存在着一些被认同的模式。
设计模式详解ppt课件
The Factory Pattern
Factory是最常见的设计模式之一，可帮 助我们组织创建对象的代码，通常用于以 下两种情况： 创建复杂的对象，并进行初始化。 根据不同的环境（输入参数），创建不
同用途的对象。一般这些对象都是实现 了相同的接口或继承于同一基类。
8
Factory模式的JDBC应用
设计模式详解
1
何谓设计模式
在面向对象程序设计（OOP）过程中， 我们经常会遇到很多重复出现的问题，总 结解决这些问题的成功经验和最佳实践便 形成了设计模式（Design Pattern）。
其核心思想是将可重用的解决方案总 结出来，并分门别类。从而指导设计，减 少代码重复和优化体系结构。
2
采用设计模式的益处
28
The Decorator Pattern
Decorator模式为我们提供了一种无需 创建派生类就能改变对象行为的方法。
OracleDataSource负责创建链接，由函数getConnection获取链接
9
Factory模式应用于DAO
XMLDB是XML数据库 访问接口，针对Oracle 和DB2分别提供了实现。 XMLDB_DAOFactory为 类工厂，根据输入的参 数dbtype，创建不同的 XMLDB实现类。
public abstract class Employee { public float getSalary() {...} public String getName() {...} public float getSalaries() {...} public abstract int getTypeCode();
实际上，EJB容器将所有资源（JMS Factory、EJB Home等）的Factory全绑定到了目录服务中，使用这些 Factory的时候都是由目录服务获取，因此目录服务是所有 资源Factory的ngleton Pattern
03设计模式六大原则PPT课件
• 不可复用，公共部分剥离不出来只能到处拷贝。 • 不够稳定，经常出错-改-出错-改….. • 系统运行不可靠，连自己也不敢相信自己的系统
4
原则的诞生
• 面向对象：封装、继承、多态三大支柱蕴含了用 抽象来封装变化，降低耦合，实现复用的精髓。
对扩展开放，对修改关闭。
• 对扩展开放：有新的需求或变化时，可以对现有 代码进行扩展，以适应新情况。
• 对修改关闭：类一旦设计完成，就可以独立完成 自己的工作，而不要再对类进行任何修改。
• 实现方式：抽象，多态，继承，接口
6
实例分析
Console.Write("请输入数字A："); string A = Console.ReadLine(); Console.Write("请选择运算符号(+、-、*、/)："); sCtorinnsgoBle.=WCrioten(s"o请le输.R入ea数要d字L加inB运e：算()";，); 怎么办？ string C = Console.ReadLine(); string D = ""; if (B == "+")
• （2）接口隔离原则
• 接口隔离原则表明客户端不应该被强迫实现一些他们不会使用的接口，应 该把胖接口中的方法分组，然后用多个接口代替它，每个接口服务于一个 子模块。
客户端不应该依赖它不需要的接口
15
实力分析
代码； • 5、如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很
强烈，那就应该用Facade或Proxy模式对代码重构；
设计模式ppt演示课件(96页)
Abstract Factory 当一个对象状态发生变化时，所以依赖于它的对象都将得到通知并自动刷新
解决方案（solution）
解Int决erp方re案te（r solutio提n） 供一个创建一系列相关或相互依赖对象的接口， 而无需指定它们具体的类 增加一个新的子类（被访问对象），则需要更新所有Visitor类接口
The pattern is , in short , at the same time a thing , which happens in the world , and the rule which tells us how to create that thing , a process and a thing , both a description of a thing which is alive , and a description of the process which will generate that thing .
功能增加的时候破坏了原有类的定义
可以对Delete操作进行撤销；
Builder 能对大多数功能支持Undo和Redo操作
Compositor（支持不同格式化算法的代码）
2it3e种rat设or计_b模设式为（Fir结s将t 构）一个复杂对象的创建与它的表示分离，使得同样 的创建过程可以创建不同的表示 一个支持窗口的逻辑概念，另一个描述了窗口的不同实现
使一个类的实例化延迟到其子类
23种设计模式（创建）
Prototype
用原型实例指定创建对象的种类，并通过拷贝这个 原型来创建新的对象
Singleton
保证一个类仅有一个实例，并提供一个访问它的全 局访问点
23种设计模式（结构）
设计模式介绍
设计模式介绍概述设计模式是软件工程领域的一套被广泛接受和应用的解决问题的设计经验总结。
它们提供了一种设计思路和指导原则，帮助开发人员构建可维护、可扩展和可重用的软件系统。
分类设计模式可以根据其目的和使用方式进行分类。
根据目的，常见的设计模式分类如下：创建型模式创建型模式关注对象的创建过程，包括实例化、组合和表示。
常见的创建型模式有：•工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪个类。
•抽象工厂模式：提供一个创建一系列相关或相互依赖对象的接口。
•单例模式：保证一个类只有一个实例，并提供全局访问点。
•原型模式：通过复制现有的实例来生成新的实例。
结构型模式结构型模式关注对象和类之间的组合和关联关系，以及对象和类的组织方式。
常见的结构型模式有：•适配器模式：将一个类的接口转换为客户端所期望的另一个接口。
•装饰器模式：动态地给对象添加额外的责任。
•代理模式：为其他对象提供一个代理，并控制对该对象的访问。
•组合模式：将对象组合成树形结构以表示”部分-整体”的层次结构。
行为型模式行为型模式关注对象之间的通信和交互，以及对象的职责分配。
常见的行为型模式有：•观察者模式：定义对象之间的一对多依赖关系，当一个对象状态改变时，其相关依赖对象会收到通知。
•模板方法模式：定义一个操作中的算法骨架，将一些步骤延迟到子类中实现。
•策略模式：定义一系列算法，并将其封装起来，以使它们可以相互替换。
•迭代器模式：提供一种顺序访问集合对象元素的方法，而又无需暴露集合底层表现形式。
具体模式介绍以下是一些常见的设计模式的详细介绍：1. 工厂方法模式工厂方法模式的核心思想是将对象的实例化推迟到子类中完成。
通过定义一个创建对象的接口，让子类来决定实例化哪个类，可以增强代码的扩展性和灵活性。
2. 观察者模式观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象。
当主题对象状态发生变化时，它的所有观察者都会收到通知并更新。
设计模式六大规则
设计模式六⼤规则1.单⼀职责原则（六⼤规则中的⼩萝莉，⼈见⼈爱）：描述的意思是每个类都只负责单⼀的功能，切不可太多，并且⼀个类应当尽量的把⼀个功能做到极致。
2.⾥⽒替换原则（六⼤原则中最⽂静的姑娘，但却不太招⼈喜欢）：这个原则表达的意思是⼀个⼦类应该可以替换掉⽗类并且可以正常⼯作。
3. 接⼝隔离原则（六⼤原则当中最挑三拣四的挑剔⼥，胸部极⼩）：也称接⼝最⼩化原则，强调的是⼀个接⼝拥有的⾏为应该尽可能的⼩。
4.依赖倒置原则（六⼤原则中最⼩鸟依⼈的姑娘，对抽象的东西⾮常依赖）：这个原则描述的是⾼层模块不该依赖于低层模块，⼆者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
5.迪⽶特原则（六⼤原则中最害羞的姑娘，不太爱和陌⽣⼈说话）：也称最⼩知道原则，即⼀个类应该尽量不要知道其他类太多的东西，不要和陌⽣的类有太多接触。
6.开-闭原则（六⼤原则中绝对的⼤姐⼤，另外五姐妹⼼⽢情愿⾂服）：最后⼀个原则，⼀句话，对修改关闭，对扩展开放。
《简介》说到设计模式，当初第⼀次听到时，第⼀反应就是很深奥，完全理解不了这个概念到底是什么意思，下⾯我先从⽹上摘录⼀份定义。
设计模式（Designpattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。
上⾯是百度当中的解释，来解释⼀下这句简单的话的含义，⼏个关键词。
反复使⽤：这个不⽤过多解释，设计模式被使⽤太多了，上个系列spring源码当中就出现了很多模式，记忆中⽐较深刻的有模板模式，代理模式，单例模式，⼯⼚模式等等。
多数⼈知晓：这个就不需要过多解释了。
分类编⽬：就是说可以找到⼀些特征去划分这些设计模式，从⽽进⾏分类。
代码设计经验：这句很重要，设计经验的总结，也就是说设计模式，是为了指导设计⽽从经验中总结出来的套路。
还有⼀种说法是说，设计模式是可以解决特定场景的问题的⼀系列⽅法，其实我觉得这个解释更贴切⼀点。
《为何学习设计模式》上⾯简单的介绍，是让各位⾸先搞清楚设计模式是什么，下⾯我们来说说为什么要学习设计模式，学习总要有个驱动⼒。
设计模式的知识点总结
设计模式的知识点总结设计模式是软件开发中常用的一种解决问题的方法论。
它提供了一套经过验证和广泛应用的问题解决方案，可以帮助我们更好地设计和组织代码。
本文将总结设计模式的主要知识点，以帮助读者更好地理解和应用设计模式。
一、什么是设计模式？设计模式是软件开发中的一种解决问题的方法论，它是一套被广泛接受和验证的面向对象设计原则的实现方式。
设计模式可以通过重复利用经验和实践，提供可复用的解决方案，使软件具备更好的可维护性、灵活性和扩展性。
二、设计模式的分类设计模式可以分为三种类型：创建型模式、结构型模式和行为型模式。
1. 创建型模式创建型模式关注如何实例化对象，它包括以下几种模式：- 单例模式(Singleton Pattern)：保证一个类只有一个实例，并提供全局访问点。
- 工厂模式(Factory Pattern)：定义一个用于创建对象的接口，由子类决定实例化哪个类。
- 抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无需指定具体类。
- 建造者模式(Builder Pattern)：将一个复杂对象的构建与其表示分离，以便同样的构建过程可以创建不同的表示。
2. 结构型模式结构型模式关注如何将对象和类组合成更大的结构，主要包括以下几种模式：- 适配器模式(Adapter Pattern)：将一个类的接口转换成客户希望的另外一个接口。
- 装饰器模式(Decorator Pattern)：动态地给一个对象添加一些额外的职责。
- 代理模式(Proxy Pattern)：为其他对象提供一种代理以控制对这个对象的访问。
- 组合模式(Composite Pattern)：将对象组合成树形结构以表示“整体-部分”的层次结构。
3. 行为型模式行为型模式关注对象之间的通信和协作，主要包括以下几种模式：- 观察者模式(Observer Pattern)：定义对象间的一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖它的对象都会被通知并更新。
设计模式概述精品PPT课件
泛化
实现
关联
聚合
组合
依赖
设计模式 设计关系 设计原则
3种模式
6大关系 5大原则
创建型
结构型
行为型
结束语
当你尽了自己的最大努力时，失败也是伟大的， 所以不要放弃，坚持就是正确的。
When You Do Your Best, Failure Is Great, So Don'T Give Up, Stick To The End
设计模式
--开启码农的艺术之旅
设计模式 设计关系 设计原则
3大模式 6大关系 5大原则
设计模式 设计关系 设计原则
3种模式 6大关系
5大原则
S – 单一职责原则
O – 开放封闭原则
L – 里氏替换原则
I – 接口隔离原则
D – 依赖倒置原则
设计模式 设计关系 设计原则
3种模式
6大关系
感谢聆听
பைடு நூலகம்不足之处请大家批评指导
Please Criticize And Guide The Shortcomings
演讲人：XXXXXX 时 间：XX年XX月XX日
软件设计模式课件 Lect6-State-Behavioral-更新版-5
Client
Main()
Context
-state: State +request()
state
状态接口
<<interface>>
State
+handle()
1. 定义客户程序需要的接 口
2. 保持当前状态子类对象 3. 可以包含部分业务逻辑
StateA
+handle()
StateB
+handle()
– Happy：dance; – Mad：make noises – Angry：scream
Examples Leading to the State Pattern
First design：use a single class to encapsulate behaviors
Monkey
-state: String +dance (): void +makeNoises: void +scream ():void +behave(): void +changeState():void +getState(): String
+behave(): void
+behave(): void
+behave(): void
Design by encapsulating each state into a separate class
Back
The State Design Pattern
The State Design Pattern
public void behave(){ if( state.equals(“happy”) ) monkey. dance(); else if(state.equals(“sad”) ) monkey. makeNoises(); else if(state.equals(“angry”) ) monkey. scream ();
5.设计模式
FloorCabinet
…
AntiqueWallCabinet
…
AntiqueFloorCabinet
ModernKStyle
getWallCabinet() getFloorCabinet()
AntiqueKStyle
getWallCabinet() getFloorCabinet()
FloorCabinet getFloorCabinet() { return new ModernFloorCabinet(); }
KitchenStyle
Kitchen
getWallCabinet() getFloorcabinet()
WallCabinet
FloorCabinet
ModernWallCabinet
ModernKStyle
getWallCabinet() getFloorCabinet()
AntiqueWallCabinet
5.了解反模式
所谓反模式就是从某些软件系统中总结出的不好的设计
方案，反模式就是告诉你如何采用一个不好的方案解决一个 问题。既然是一个不好的方案，为何还有可能被重复使用呢？ 这是因为，这些不好的方案表面上往往有很强的吸引力，人 们很难一眼就发现它的弊端，因此，发现一个反模式也是非
常有意义的工作。在有了一定的设计模式的基础之后，你可
什么是设计模式
1．设计模式 “设计模式（pattern）是从许多优秀的软件系统中总结出 的成功的可复用的设计方案”。 2．GOF之说
“尽管Alexander所指的是城市和建筑设计模式，但他的思
想也同样适用于面向对象设计模式，只是在面向对象的解决方 案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心 都在于提供了相关问题的解决方案”。
设计模式第六章
广西经干院计算机系
装饰模式UML类图
2013年9月21日星期六5时3分31秒
广西经干院计算机系
装饰模式的结构与使用
1．抽象组件 : Bird.java public abstract class Bird{ public abstract int fly(); }
2013年9月21日星期六5时3分31秒
以增加新的针对该具体组件的具体装饰。 可以使用多个具体装饰来装饰具体组件的实例。
2013年9月21日星期六5时3分31秒
广西经干院计算机系
6.4 应用举例
当前系统已有一个抽象类ReadWord，该类有 一个抽象方法readWord()，另外还有一个 ReadWord类的子类ReadEnglishWord，该 ReadWord ReadEnglishWord 类的readWord()方法可以读取一个由英文单词 构成的文本文件word.txt。系统已有类的类图 如图6.11所示。目前已有一些客户在使用该系 +readWord(File) +readWord(File) 统，并使用ReadWord类的对象调用 readWord()方法读取文件中的单词。
2013年9月22日星期日8时53分37秒广西经干院计算机系当前系统已有一个抽象类readword该类有一个抽象方法readword另外还有一个readword类的子类readenglishword该类的readword方法可以读取一个由英文单词构成的文本文件wordtxt
第六章 装饰模式
主讲：刘 杰
装饰模式
装饰模式（别名：包装器） 动态地给对象添加一些额外的职责。就功能来说装饰 模式相比生成子类更为灵活。 Decorator Pattern(Another Name: Wrapper) Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
设计模式第六次课
• 区别：工厂方法模式只有一个抽象产品类，而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例，而抽象工厂模式可以 创建多个。
设计模式之FACTORY METHOD -工厂模 式
• 请朋友去麦当劳吃汉堡，不同的人有不同 的口味，要每个都记住是一件烦人的事情， 我一般采用Factory Method模式，带朋友到 服务员那儿，说“要一个汉堡”，具体要 什么样的汉堡呢，让朋友直接跟服务员说 就行了。
类图
工厂方法模式案例1
– 抽象产品，具体产品，抽象工厂，具体工厂
• 效果：提供一个创建一系列或相互依赖的 接口，而无须制定它们具体的类。
设计模式之FACTORY METHOD –抽象工 厂模式
• 抽象工厂模式可以向客户端提供一个接口， 使得客户端在不必指定产品具体类型的情 况下，创建多个产品族中的产品对象。这 就是抽象工厂模式的用意。每个模式都是 针对一定问题的解决方案。抽象工厂模式 面对的问题是多产品等级结构的系统设计。
类图
抽象工厂模式案例1
外观模式案例2
代码
• 见txt文档
抽象工厂模式优点
• 见书P141
抽象工厂模式与工厂方法模式
• 工厂方法模式：
– 一个抽象产品类，可以派生出多个具体产品类。 – 一个抽象工厂类，可以派生出多个具体工厂类。 – 每个具体工厂类只能创建一个具体产品类的实例。
• 抽象工厂模式：
设计模式之FACTORY METHOD –抽象工 厂模式
• 在学习抽象工厂具体实例之前，应该明白 两个重要的概念：产品族和产品等级。 产品族：是指位于不同产品等级结构中， 功能相关联的产品组成的家族。比如AMD 的CPU和ADM芯片的主板，组成一个家族。 Intel的CPU和Intel芯片的主板，又组成一个 家族。而这两个家族都来自于两个产品等 级：CPU，主板。一个等级结构是由相同 的结构的产品组成，示意图如下：
教学设计模式讲座
教学设计模式讲座教学设计模式讲座是一种教学方法，旨在向学生介绍不同的设计模式，以帮助他们理解和应用软件设计原则和技术。
在这样的讲座中，我们可以讲解不同的设计模式，并通过实例和案例研究来说明它们的用途和优点。
以下是一个简单的教学设计模式讲座的大纲。
第一部分：介绍设计模式（约200字）- 什么是设计模式？- 设计模式的作用和意义- 设计模式的分类和常见的设计模式第二部分：创建型设计模式（约300字）- 单例模式：介绍单例模式的概念、场景和实现方式- 工厂模式：介绍工厂模式的概念、场景和实现方式- 建造者模式：介绍建造者模式的概念、场景和实现方式- 原型模式：介绍原型模式的概念、场景和实现方式第三部分：结构型设计模式（约300字）- 适配器模式：介绍适配器模式的概念、场景和实现方式- 桥接模式：介绍桥接模式的概念、场景和实现方式- 装饰器模式：介绍装饰器模式的概念、场景和实现方式- 组合模式：介绍组合模式的概念、场景和实现方式第四部分：行为型设计模式（约300字）- 观察者模式：介绍观察者模式的概念、场景和实现方式- 策略模式：介绍策略模式的概念、场景和实现方式- 命令模式：介绍命令模式的概念、场景和实现方式- 迭代器模式：介绍迭代器模式的概念、场景和实现方式第五部分：总结与应用（约200字）- 总结设计模式的概念和分类- 强调设计模式在软件开发中的应用- 提供一些实际案例，让学生能够应用所学的设计模式通过设计模式讲座，学生可以学到以下几点：1. 理解设计模式的概念和意义。
他们将了解到设计模式是一种解决特定软件设计问题的经验总结，能够提高软件的可复用性、可维护性和灵活性。
2. 掌握不同的设计模式。
学生将学习到各种不同的设计模式，并了解它们的适用场景和实现方式。
3. 学会将设计模式应用于实际开发中。
通过实例和案例研究，学生将有机会练习设计模式的应用，从而更好地理解和掌握设计模式的使用技巧。
4. 培养软件设计和架构的思维。
设计模式6大原则
设计模式6大原则设计模式的6大原则设计模式是解决软件设计问题的常用方法，它们有助于更好地处理复杂性，提高质量，提高可维护性和可扩展性。
设计模式的6大原则可以帮助程序员更好地理解和使用这些模式。
要求最少知识原则（Principle of Least Knowledge），简称“迪科特法则”，是最重要的原则之一。
它强调程序设计者应该限制对象间的交互，只允许它们之间的最小的知识交流。
这样可以降低系统的复杂性，减少系统出错的可能性。
开放-封闭原则（Open-Closed Principle），即对扩展开放，对修改封闭的原则，是设计模式的基础。
意思是说，软件实体（类、模块、函数等）应该可以扩展，但是不可修改。
这样可以避免在修改源代码时出现错误。
第三，单一职责原则（Single Responsibility Principle），即一个类、模块或函数只有一个变化的原因。
这意味着一个类只负责一个功能，而不应该承担多个职责。
这样可以避免类的职责混乱，提高代码的可维护性。
接下来，接口隔离原则（Interface Segregation Principle），即客户端不应该依赖它不需要的接口，也就是一个接口应该只服务于一个子系统。
这样可以有效地降低接口的复杂性，提高系统的可维护性。
第五，依赖倒转原则（Dependency Inversion Principle），即高层模块不应该依赖低层模块，两个都应该依赖其抽象。
这样可以减少系统的耦合，提高系统的可维护性。
还有合成/聚合复用原则（Composite / Aggregate Reuse Principle），即尽量使用合成/聚合，而不是继承来达到复用的目的。
这样可以让系统更加灵活，减少系统的复杂性。
设计模式的6大原则是程序员设计软件时必须遵守的基本原则，它们有助于提高系统的质量，提高可维护性和可扩展性，从而让程序员更好地处理复杂的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Lecture 6 Concurrent Computing
• Multiprocess vs. Multithread
• Threading Model • Thread Synchronization • Java Thread API
2
7/10/2013 Page 2
Software Architecture & Design Pattern
Definitions
• Concurrency - “Logically" simultaneous processing - Does not imply multiple processing elements
21
7/10/2013 Page 21
Software Architecture & Design Pattern
22
7/10/2013 Page 22
Software Architecture & Design Pattern
23
7/10/2013 Page 23
Software Architecture & Design Pattern
Java Threading Model
Two-level threads: user thread (java thread class)
kernel thread (O/S kernel support)
Thread model
• one-to-one
• many-to-one • many-to-many
7
7/10/2013 Page 7
Software Architecture & Design Pattern
8
7/10/2013 Pcture & Design Pattern
9
7/10/2013 Page 9
Software Architecture & Design Pattern
One-to-One Model
- one user thread is mapped
to one kernel thread - high concurrency - may overload the kernel
18
7/10/2013 Page 18
Software Architecture & Design Pattern
• Multithread
Multiple execution units within a process share system resources.
4
7/10/2013 Page 4
Software Architecture & Design Pattern
Multiprocess --- single core
Many-to-One Model
- many user threads are
mapped to one kernel thread - low throughput - not quite used now
19
7/10/2013 Page 19
Software Architecture & Design Pattern
Questions ?
Comments?
36
7/10/2013 Page 36
5
7/10/2013 Page 5
Software Architecture & Design Pattern
Multiprocess --- multi-core
6
7/10/2013 Page 6
Software Architecture & Design Pattern
Multithread --- dual-core
16
7/10/2013 Page 16
Software Architecture & Design Pattern
Solaris Two-level Threading Structure
17
7/10/2013 Page 17
Software Architecture & Design Pattern
30
7/10/2013 Page 30
Software Architecture & Design Pattern
31
7/10/2013 Page 31
Software Architecture & Design Pattern
32
7/10/2013 Page 32
Software Architecture & Design Pattern
27
7/10/2013 Page 27
Software Architecture & Design Pattern
28
7/10/2013 Page 28
Software Architecture & Design Pattern
29
7/10/2013 Page 29
Software Architecture & Design Pattern
24
7/10/2013 Page 24
Software Architecture & Design Pattern
25
7/10/2013 Page 25
Software Architecture & Design Pattern
26
7/10/2013 Page 26
Software Architecture & Design Pattern
7/10/2013
3
Page 3
Software Architecture & Design Pattern
Multiprocess vs. Multithread
• Multiprocess Multiple tasks or processes share common system resources such as CPU, I/O, etc.
33
7/10/2013 Page 33
Software Architecture & Design Pattern
34
7/10/2013 Page 34
Software Architecture & Design Pattern
35
7/10/2013 Page 35
Software Architecture & Design Pattern
1
7/10/2013 Page 1
Software Architecture & Design Pattern
Motivation for Concurrency
• Leverage hardware/software advances, e.g. multi-processors and OS thread support • Increase performance, e.g., overlap computation and communication • Improve response-time, e.g., GUIs and network servers • Simplify program structure, e.g., synchronous vs. asynchronous network IPC
Many-to-Many Model
- M user threads are mapped to N kernel threads - use resources efficiently - scheduling issue
20
7/10/2013 Page 20
Software Architecture & Design Pattern
• Parallelism - “Physically" simultaneous processing - Involves multiple processing elements and/or independent device operations
Both concurrency and parallelism require controlled access to shared resources, e.g. I/O devices, files, database records, in-core data structures, consoles, etc
13
7/10/2013 Page 13
Software Architecture & Design Pattern
14
7/10/2013 Page 14
Software Architecture & Design Pattern
15
7/10/2013 Page 15
Software Architecture & Design Pattern
10
7/10/2013 Page 10
Software Architecture & Design Pattern
11
7/10/2013 Page 11
Software Architecture & Design Pattern
12
7/10/2013 Page 12
Software Architecture & Design Pattern