设计模式
wwj_zy
这个作者很懒,什么都没留下…
展开
-
大话设计模式阅读(1) UML类图各种关系与代码的对应理解
1、继承:代码略去 2、实现接口:略去 3、关联关系:一个类(箭头起点的类)中包含另一个类(箭头所指的类)的对象成员 class Penguin //企鹅类关联气象类 { private Climate climate; } 4、聚合关系:一种弱的拥有关系,一个类包含另一个类(箭头所指的类)的成员集合原创 2015-04-30 14:55:52 · 741 阅读 · 0 评论 -
几个设计模式的例子
观察者模式 Observer 观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。 这个主题对象在状态上发生变化时,会通知所有观察者对象,让它们能够自动更新自己。 观察者模式的组成 抽象主题角色:把所有对观察者对象的引用保存在一个集合中,每个抽象主题角色都可以有任意数量的观察者。抽象主题提供一个接口,可以增加和删除观察者角色。一般用一个抽象类和接转载 2015-11-24 21:01:10 · 699 阅读 · 0 评论 -
Head First 设计模式(2):观察者模式
观察者模式:定义了对象之间的一对多依赖,当一个对象状态改变时,他的所有依赖者都会收到通知并自动更新 例子: 代码: package headfirst.designpatterns.observer.weather; public interface Subject { public void registerObserver(Observer o); public v原创 2015-07-01 21:41:35 · 395 阅读 · 0 评论 -
Head First 设计模式(4):工厂模式
工厂方法模式:定义了一个创建对象的接口,由子类决定要实例化的类是哪一个,让类把实例化推迟到子类 抽象工厂模式:提供一个接口,用于创建相关或者依赖对象的家族,不需要明确指定具体类 他们都把对象的创建封装起来,得到更松耦合、更有弹性的设计 工厂方法: 抽象工厂:原创 2015-07-02 14:59:31 · 507 阅读 · 0 评论 -
Head First 设计模式(1):策略模式
策略模式:定义了算法族,分别封装起来,相互之间可以互相替换,让算法的变化独立于使用算法的客户。 例子: 代码: package headfirst.designpatterns.strategy; public abstract class Duck { FlyBehavior flyBehavior; QuackBehavior quackBehavior; public D原创 2015-07-01 21:16:00 · 342 阅读 · 0 评论 -
Head First 设计模式(5):单件模式
单件模式:确保一个类只有一个实例,并提供一个全局访问点 1、经典实现: package headfirst.designpatterns.singleton.classic; // NOTE: This is not thread safe! public class Singleton { private static Singleton uniqueInstance; priv原创 2015-07-02 15:37:12 · 412 阅读 · 0 评论 -
Head First 设计模式(3):装饰者模式
装饰者模式:动态地把责任附加到对象上,如果要扩展功能,提供了比继承更有弹性的解决方案 例子: 代码: package headfirst.designpatterns.decorator.starbuzz; public abstract class Beverage { String description = "Unknown Beverage"; public String原创 2015-07-02 10:36:27 · 364 阅读 · 0 评论 -
UML图中类之间的关系:依赖,泛化,关联,聚合,组合,实现
类与类图 1) 类(Class)封装了数据和行为,是面向对象的重要组成部分,它是具有相同属性、操作、关系的对象集合的总称。 2) 在系统中,每个类具有一定的职责,职责指的是类所担任的任务,即类要完成什么样的功能,要承担什么样的义务。一个类可以有多种职责,设计得好的类一般只有一种职责,在定义类的时候,将类的职责分解成为类的属性和操作(即方法)。 3) 类的属性即类的数据职责,类的操作即类的行转载 2015-07-01 15:50:40 · 292 阅读 · 0 评论 -
设计模式的六大原则
单一职责原则(Single Responsibility Principle) 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案:遵循单一职责原则。分别建立两个类T1、T2,使T1完成职责P1功能,T2完成职责转载 2015-11-24 21:06:11 · 406 阅读 · 0 评论