1. 简单工厂模式
- 向简单工厂传一个参数,立即生成所需的运算类(传一个符号进去,根据符号直接创建出运算类的子类,调用子类重写的运算方法即可计算)
工厂模式举例
/*假如:简单工厂是ObjectFactory:(createOpratorObj(String str)
* 为创建运算类的方法) ;
* 运算类是OperatorObj,此类可为抽象类,
* (属性有numberA, numberB和方法getResult());
* 加减乘除类都是运算类的子类(他们都重写了运算类的getResult()方法)
* /
/**
*测试类方法
*/
public static void main(String[] args) {
// 创建加法的子类
OperatorObj obj = ObjectFactory.createOpratorObj("+");
obj.setNumberA(1);
obj.setNumberB(2);
System.out.println(obj.getResult());
}
/**
*ObjectFactory方法
*/
public static OperatorObj (String opr){
OperatorObj obj = null;
swith(opr){
case "+":
obj = new AddOperator();
breake;
case "-":
obj = new SubOperator();
breake;
...
default:
log.error("没有此操作类型的对象!");
return obj;
}
}
-
适用场景:
-
- 创建的是工厂对象,某些只有某个地方有变化的一类对象适用于这个工厂模式,举例写一个计算器,计算器对象包括两个参数和一个符号,且这个对象类一旦生成,后期修改很少,这种场景就适合运用简单工厂模式。
-
- 再比如说Netty的处理器Handler,处理器对象,子处理器继承主处理器,接收到报文后,根据报文的不同标识,生成不同的子处理器,走不同的子报文处理逻辑
限制场景:
-
- 工厂对象生成后尽量不要经常性的修改,不然工厂模式就没有意思了
2.策略模式
- 策略模式封装的是变化,就是CashSuper类交给CashContext类管理,子类中记载着每个策略的变化
- 和简单工厂模式的不同点是:
-1. 测试类测试工厂模式时需要使用CashSuper和CashFactory;而测试类测试策略模式时,只需要知道CashContext即可
-2.工厂模式的父类一般有静态属性,策略模式的父类方法可以没有静态属性,通常为一接口
策略模式实例
/* ConContext 为管理CashSuper的配置类
* CashSuper为基类,可以为接口或抽象类
* CashNormal, CashRebate, CashReturn是三个子类
*/
/**
*CashSuper基类
*/
public Interface CashSuper{
public void acceptCash();
}
/**@dec 用来管理CashSuper接口
*CashContext配置类
*/
public class ConContext{
public CashSuper cr;
public ConContext(CashSuper cr){
this.cr = cr;
}
public void conInterface(){
cr.acceptCash();
}
}
/**
*测试方法
*/
@Test
public void test(int type) {
private ConContext ct;
swith(type){
case 1:
ct = new ConContext(new CashNormal());
break;
case 2:
ct = new ConContext(new CashRebate());
break;
...
defalut:
log.error("没有此计费策略,请新增策略!");
}
}
-
适用场景:
-
- 将管理对象的权利交给配置类,只封装策略的变化,不做其他逻辑处理,适用于电信计费场景和商品营销场景。
-
- 比如说电信产品的计费,封装计费策略,打几折优惠,阶梯计费等各种计费策略为子对象,创建一个策略的父接口,将接口交给配置类处理,在配置类的构造方法管理策略父接口,方法为父接口的方法。
限制场景:
-
- 封装的是变化,将各种策略变化的策略封装起来。
将简单工厂模式与策略模式合并起来(消除测试类中太多的逻辑判断,只需要修改配置类即可)
/* ConContext 为管理CashSuper的配置类
* CashSuper为基类,可以为接口或抽象类
* CashNormal, CashRebate, CashReturn是三个子类
*/
/**
*CashSuper基类
*/
public Interface CashSuper{
public void acceptCash();
}
/**@dec 用来管理CashSuper接口
*CashContext配置类
*/
public class ConContext{
public CashSuper cr;
public ConContext(int type){
swith(type){
case 1:
cr = new CashNormal();
break;
case 2:
cr = new CashRebate();
break;
...
defalut:
log.error("没有此计费策略,请新增策略!");
}
public void conInterface(){
cr.acceptCash();
}
}
/**
*测试方法
*/
@Test
public void test(int type) {
ConContext ct = new ConContext(1);
ct.conInterface();
}
3. 单一职责原则
描述:一个方法只让他做一件事情,一个方法尽量控制在300行之内
4. 开发——封闭原则
描述:就是在需求设计的时候,要时刻考量需求,要尽量让类写的足够好,写好了就不要去修改了,如果一些新的需求过来了只需要在原有的基础上增加类就可以实现,原来的代码能不动就不动。
需求模块:
无论模块是多么的 ‘封闭’ ,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他的设计模块应该对那种变化封闭做出抉择,他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。
5.依赖倒转原则
描述:抽象不要依赖细节,细节应该抽象,换句话说,就是要针对接口编程,而不是针对实现编程。
依赖倒装原则:
A.高层模块不应该依赖底层模块。两个都应该依赖抽象。
B.抽象不应该依赖细节,细节应该依赖抽象。
6.装饰模式
Component定义了一个对象接口,可以给这些对象动态地添加一些职责。Decorator,装饰抽象类,继承了Component,从外类来扩展Component类的功能,但对于Component来说,是无需知道Decorator的存在的。至于ConcreteDecorator就是具体的装饰对象,起到给Component添加职责的功能。
简述:
所谓的装饰模式就是包装对象,就是将一个对象进行不同的包装,形成不同装饰的对象。
样例:
/**人对象
*/
class Person{
private String name;
publlic Person(String name){
this.name = name;
}
public void show(){
system.out.println("装扮的{0}"+name);
}
}
/**服装类对象 (包装下person)
*/
class Finery extends Person{
private Person component;
//设置包装对象
public void setComponent(Person component){
this.component = component;
}
//执行的方法
public void show(){
if(component != null){
component.show();
}
}
}
/**具体服装类A
*/
class Tshirts extends Finery{
public void show(){
system.out.println("穿一件T-Shirt");
}
}
/**具体服装类B
*/
class BigTrouser extends Finery{
public void show{
system.out.println("穿一件大裤衩");
}
}
/**测试业务类
*/
class TestLogic{
public static void mian(String[] args){
Persion person = new Person("testName");
Tshirts ts = new Tshirts();
BigTrouser bu = new BigTrouser();
//包装装饰
ts.setComponent(person);
bu.setComponent(ts);
bu.show();
}
}