UML与软件工程

适用性
当创建复杂对象的算法应该独立于该对象的 组成部分以及它们的装配方式时。
当构造过程必须允许被构造的对象有不同的 表示时。 当你要强调一系列相关的产品对象的设计以 便进行联合使用时。
当你提供一个产品类库，而只想显示它们的 接口而不是实现时。。
设计模式
创建型
4、Builder（建造者）
— 7—
建造者模式的实现
适用性
你想使用一个已经存在的类，而它的接口不 符合你的需求。
你想创建一个可以复用的类，该类可以与其 他不相关的类或不可预见的类（即那些接口 可能不一定兼容的类）协同工作。
（仅适用于对象Adapter ）你想使用一些已 经存在的子类，但是不可能对每一个都进行 子类化以匹配它们的接口。对象适配器可以 适配它的父类接口。
设计模式之禅
演讲人：唐有炜
概览
前言
概览
阐述为什么要使用设计 模式，他能解决什么问 题，不能解决什么问题 设计模式适用场合以及 最佳实践，避免设计模 式的滥用和误用
— 2—
设计模式解决的痛点
最佳实践
02 01
何为设计模式
了解什么是设计模式， 他出现的背景
04 03
23种设计模式分类概览
对23种经典设计模式 进行分析，体会设计模 式的内涵
设计模式
创建型
3、Abstract Factory（抽象工厂）
— 7—
抽象工厂模式的实现
/developer_zhang/article/details/19619927
设计模式
创建型
4、Builder（建造者）
— 7—
建造者模式的UML类图
要点
意图：
将一个复杂对象的构建与它的表示分离，使 得同样的构建过程可以创建不同的表示。
设计模式
创建型
2、Factory Method（工厂方法）
— 7—
工厂方法模式的实现
/xiaofeixiang/p/4712973.html /developer_zhang/article/details/19609225
4
何为设计模式
背景
没有设计模式之前软件面临的问题－软件危机
— 3—
软件还没完成，预算就没了？囧！
1
项目运行超出预算
怎么又有这么多Bug？
3
2
软件质量低落
明天能交付吗？
项目运行超过时间
5
项目无法管理，且代码 难以维护
4
软件通常不符合需求
我要求的不是这样！
这尼玛代码谁写的，改起 来真蛋疼？
何为设计模式
行为型
8. Composite（组合） 9. Decorator（装饰） 10. Facade（外观） 11. Flyweight（享元） 12. Proxy（代理）
13. Interpreter（解释器 ） 14. Template Method（ 模板方法） 15. Chain of Responsibility（责任链 ） 16. Command（命令）
设计模式
创建型
2、Factory Method（工厂方法）
— 7—
要点 工厂方法模式的UML类图
意图：
定义一个用于创建对象的接口，让子类决定 实例化哪一个类。Factory Method 使一个 类的实例化延迟到其子类。
适用性
当一个类不知道它所必须创建的对象的类的 时候。 当一个类希望由它的子类来指定它所创建的 对象的时候。 当类将创建对象的职责委托给多个帮助子类 中的某一个，并且你希望将哪一个帮助子类 是代理者这一信息局部化的时候。
17. Iterator（ 迭代器） 18. Mediator （中介者） 19. Memento （备忘录） 20. Observer （观察者） 21. State（状 态） 22. Strategy （策略） 23. Visitor（ 访问者）
设计模式
创建型
1、Singleton（单例模式） //第二种写法 @implementation Singleton static Singleton sharedInstance = nil; + (id) sharedInstance { @synchronized(self) { if (!sharedInstance) { sharedInstance ＝ [[self alloc] init]; } }
设计模式的出现
软件设计模式是在面向对象的系统设计过程中反复出现的问题解决方案。这个术语是在1990年代由Erich Gamma 等人从建筑设计领域引入到计算机科学中来的。这个术语的含义目前还存有争议。设计模式通常描述了一组相互紧 密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他 设计者掌握。设计模式还为软件重构提供了目标。 上面是关于设计模式的普遍定义。设计模式是与语言无关的一套针对特定上下文的特定问题的解决方案，这种 解决方案被抽象化、模版化，就是设计模式。 关于这个Apple 的 Cocoa Fundamentals Guide有这么一句话： [Design Pattern is] a solution to a problem in a context.
3ห้องสมุดไป่ตู้
2 4
设计模式解决 的痛点
概念
设计模式解决的痛点
— 3—
设计模式六大原则
设计模式就是一套经过理论 和实践验证的可行的符合软 3 件工程思想的解决方案。 4
1
设计模式解决 的痛点
概念
设计模式6大原则
— 5—
单一职责原则
一个类应该只有一 个发生变化的原因 。
里氏代换原则
子类应该可以替换任何基 类能够出现的地方，并且 经过替换以后，代码还能 正常工作。
1
色。
（2）迭代式模型 （3）快速原型模型 所以，可以看出只要系统分析和设计到位了，写代码只是水到渠成的。
3
2
2、为什么要搞这么复杂？ 有这种想法的人，要么是新手，要么没有做过大项目。其实软件的维护周期在一定程度上要远远大于开发周期 。一个好的优美的、可扩展架构往往可以节省很多维护成本，让程序更健壮。这点，越到后来，做的越多，体会会 越加深刻。 一旦到这个时候，你会发现，这些架构不是让软件复杂，想法，他们的目的就是让软件优美、简洁、健壮。
设计模式
分析
设计模式分类
— 6—
创建型
结构型
1. Singleton（单例） 2. FactoryMethod（工厂 方法） 3. Abstract Factory（抽 象工厂） 4. Builder（建造者） 5. Prototype（原型）
6. Adapter Class/Object （适配器） 7. Bridge（ 桥接）
为了避免创建一个与产品类层次平行的工厂 类层次时；或者
当一个类的实例只能有几个不同状态组合中 的一种时。建立相应数目的原型并克隆它们 可能比每次用合适的状态手工实例化该类更 方便一些。
设计模式
创建型
5、Prototype（原型）
— 7—
原型模式的实现
/developer_zhang/article/details/9173015
何为设计模式
引言
几个疑问
— 3—
1、一个软件（或者系统）真正的生命周期是什么样的？ 可能对于刚开始接触软件开发或者对这行了解不深的人，会认为，软件开发，不就是写代码吗？ 错？大错特特错。在真正的正规流程中，写代码只不过是不到1/4的工作。真正的软件声明周期是这样的： （1）瀑布式模型 需求分析->软件设计->程序编码->软件测试->运行维护 想对应的职位：需求分析师、架构师、程序员（软件工程师）、软件测试员、系统运维 这些都是对应非常规范的大公司，小公司，可能压根没这么多步骤，有时候可能不自觉自己会担任多个角
— 7—
桥接模式的UML类图
要点
意图：
将抽象部分与它的实现部分分离，使它们都 可以独立地变化。
适用性
你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是 因为，在程序运行时刻实现部分应可以被选择或者切换。 类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge 模式 使你可以对不同的抽象接口和实现部分进行组合，并分别对它们进行扩充。 对一个抽象的实现部分的修改应对客户不产生影响，即客户的代码不必重新编译。 （C++）你想对客户完全隐藏抽象的实现部分。在C++中，类的表示在类接口中是可 见的。 有许多类要生成。这样一种类层次结构说明你必须将一个对象分解成两个部分。 Rumbaugh 称这种类层次结构为“嵌套的普化”（nested generalizations ）。 你想在多个对象间共享实现（可能使用引用计数），但同时要求客户并不知道这一 点。一个简单的例子便是Coplien 的String 类[ Cop92 ]，在这个类中多个对象可以共享 同一个字符串表示（StringRep ）。
/eagle927183/p/3462439.html
设计模式
结构型
6、Adapter Class/Object（适配器）
— 7—
适配器模式的UML类图
要点
意图：
将一个类的接口转换成客户希望的另外一个 接口。Adapter 模式使得原本由于接口不兼 容而不能一起工作的那些类可以一起工作。
— 4—
意图： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。 适用性： 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能 使用一个扩展的实例时。
UML类图
}
+ (id) Singleton//第一种写法 { static dispatch_once_t onceToken; static Singleton * sharedInstance; dispatch_once(&onceToken, ^{ sharedInstance = [[self alloc] init]; }); return sharedInstance; }