设计模式
番茄鲨鱼面
这个作者很懒,什么都没留下…
展开
-
设计模式01:策略模式
策略模式:定义了算法族,分别封装起来,让它们之间可以相互替换,此模式让算法的变化独立于使用算法的客户。原创 2015-12-21 15:52:15 · 490 阅读 · 0 评论 -
设计模式:适配器模式
适配器模式适配器模式:将一个类的接口,转换成客户期望的另一个接口。适配器让原来接口不兼容的类可以合作无间。 示例:一个农场主,以前一直喂养家禽Poultry中的鸡chicken,后来他又喂养鸽子dove。 家禽接口:package com.adapter;/** * ClassName: Poultry * @Description: 家禽类 * @author Panyk *原创 2016-03-09 09:29:39 · 437 阅读 · 0 评论 -
命令模式
命令模式(封装调用)命令模式:将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持可撤销的操作。命令模式可以将命令的发出者和命令的执行者解耦。package com.command;//电灯public class Light { public void on(){ System.out.println("灯亮!"); }原创 2016-03-08 14:57:09 · 450 阅读 · 0 评论 -
HeadFirst设计模式
单例模式原创 2016-03-08 11:24:20 · 467 阅读 · 0 评论 -
设计模式:单例模式
通过私有化构造方法,我们可以使一个类不能在外部被实例化。public class MyClass { private MyClass(){ System.out.println("private MyClass()"); }}public class Main { public static void main(String[] args) {原创 2016-03-08 10:43:43 · 495 阅读 · 0 评论 -
设计模式02:观察者模式
观察者模式:定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。import java.util.Observable;public class WeatherData extends Observable { private float temperature; private float pressure; public原创 2015-12-23 16:29:40 · 535 阅读 · 0 评论 -
设计模式:依赖倒转原则
依赖倒转原则高层模块不应该依赖底层模块。两个都应该依赖抽象。抽象不应该依赖细节。细节应该依赖抽象。譬如我们把访问数据库的方法写成了一个函数,那么我们做新项目的时候,去调用这些底层的函数就可以了,这就是高层模块依赖与底层模块。里氏代换原则子类型必须能够替换调他们的父类型。一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别原创 2016-01-15 16:53:05 · 419 阅读 · 0 评论 -
设计模式:开闭原则(OCP)
开闭原则(The open-closed principle、ocp)就是说,软件实体(类、模块、函数等等)应该可以扩展,但是不可修改。但是无论设计的多么好,一个类或者一个模块总是要改的,既然不可能完全封闭,那么就要求设计人员必须对于他设计的模块应该对哪些变化封闭做出选择,必须先猜测出最右可能发生的变化种类,然后构造抽象来隔离那些变化。面对需求,对程序的改动是通过增加新代码进行的,而不是更原创 2016-01-15 16:34:35 · 497 阅读 · 0 评论 -
设计模式:单一职责原则
单一职责原则(srp)就一个类而言,应该仅有一个引起它变化的原因。例如,我们不要在一个类中既进行输入输出,又进行算法运算,还访问数据库等,这样的一个类维护麻烦,服用不可能,也缺乏灵活性。还有,我们做web页面,不可能直接在一个jsp文件中访问数据库查询数据,然后进行各种逻辑运算,之后在页面显示,这样html代码和java代码混杂在一起,不仅不利于开发,更无法复用。所以,我们做web项目原创 2016-01-15 16:24:00 · 352 阅读 · 0 评论 -
设计模式:外观模式
外观模式(Facade Pattern)外观模式:提供一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。 模式 功能 装饰者模式 不改变接口,但加入责任 适配器模式 将一个接口转换成另一个接口 外观模式 让接口更简单原创 2016-03-09 09:54:25 · 548 阅读 · 0 评论