原来这些设计模式的理念都是相同的
作者:互联网
点击上方 "程序员小乐"关注, 星标或置顶一起成长
关注订阅号「程序员小乐」,收看更多精彩内容
每日英文
Destiny is responsible for shuffle, play CARDS is myself, Letter, follow fate walk, don't phase is destiny dragged walk; Life is not a rehearsal, every day is live!
命运负责洗牌,玩牌的是自己;相信命运跟着命运走,不相信命运被命运拖着走;人生没有彩排,每天都是现场直播!
每日掏心话
我为自己的心感到骄傲。它曾受玩弄,曾经心焦,曾遭破碎,却依然鲜活跳动。
来自:唐子玄 | 责编:乐乐
链接:juejin.im/user/5771d75d2e958a0078f97976
程序员小乐(ID:study_tech)第 1014 次推文
往日回顾:#北工大#男生自宫事件? 太狠了!称性欲影响学业,最新情况...
正文
虽然不同的设计模式解决的问题各不相同,但从一个更高的抽象层次来看,它们通过相同的手段来实现相同的目的。本文将以更抽象的视角剖析工厂模式、策略模式、模版方法模式,以及这些模式所遵循的设计原则。先用一句话总结它们的共同点:
它们增加了一层抽象将变化封装起来,然后对抽象编程,并利用多态应对变化。
/ 工厂模式 /
变化是什么
对工厂模式来说,变化就是构建对象的方式,举个例子:
public class PizzaStore{
public Pizza orderPizza(String type){
Pizza pizza ;
//构建具体pizza对象
if(type.equals("cheese")){
pizza = new CheesePizza();
}else if(type.equals("bacon")){
pizza = new BaconPizza();
}
//使用pizza对象
pizza.prepare();
pizza.bake();
return pizza ;
}
}
抽象的反义词是具体,对于工厂模式,具体就是用new来构建对象。这样做的后果是PizzaStore不仅需要引入具体的Pizza类,而且和构建Pizza的细节耦合在一起。
如果PizzaStore一辈子只做这两种Pizza,上面的代码就很好,不需要重构。但如果需要新增Pizza类型,就不得不修改orderPizza(),向其中增加if-else。
如何应对变化
通过将变化封装在一层新的抽象中,实现了上层代码和变化的隔离,达到解耦的目的。对于工厂模式来说,新建的抽象叫做工厂,它将对象的构建和对象的使用分隔开,让使用对象的代码不依赖于构建对象的细节。
解耦的好处是:“当变化发生时上层代码不需要改动”,这句话也可以表达成:“在不修改既有代码的情况下扩展功能”。这就是著名的 “开闭原则” 。
“对修改关闭”的意思是:当需要为类扩展功能时,不要想着去修改类的既有代码,这是不允许的!为啥不允许?因为既有代码是由数位程序员的努力,历经了多个版本的迭代,好不容易才得到的正确代码。其中蕴含着博大精深的知识,和你不曾了解的细节,修改它一定会出bug的!
“对扩展开放”的意思是:类的代码应该具备良好的抽象,使得扩展类的时候,不需要修改类的既有代码。
现实的问题来了,如果项目中的既有类不具备扩展性,甚至是牵一发动全身的那种类。在一个时间较紧的迭代中需要往里添加新功能,你会怎么做?是违背“对修改关闭”,还是咬牙重构?(欢迎讨论~~)
三种封装变化方式
1.简单工厂模式
既然目的是消除orderPizza()中构建具体pizza的细节,那最直接的做法是,将他们提取出来放到另一个类中:
public class PizzaFactory{
public static Pizza createPizza(String type){
Pizza pizza ;
if(type.equals("cheese")){
pizza = new CheesePizza();
}else if(type.equals("bacon")){
pizza = new BaconPizza();
}
return pizza ;
}
}
然后使用Pizza的代码就变成:
public class PizzaStore{
public Pizza orderPizza(String type){
Pizza pizza = PizzaFactory.createPizza(type);
pizza.prepare();
pizza.bake();
return pizza ;
}
}
等等,这和我们平时将一段常用代码抽离出来放到Util类中有什么区别吗?
是的,没有任何区别。从严格意义上说,这不是一个设计模式,更像是一种编程习惯。虽然只是代码搬家,但这种习惯的好处是:它隐藏了构建对象的细节,因为构建对象是经常会发生变化的,所以它还封装了变化,最后它还可以被复用,比如菜单类也需要构建 pizza 对象并获取他们的价格。
使用静态方法是这类封装常用的技巧,它的好处是不需要新建工厂对象就可以实现调用,但缺点是不具备扩展性(静态方法不能被重写)。
2.工厂方法模式
简单工厂模式中,工厂能够构建几种对象是在编译之前就定义好的,如果想要新增另一种新对象,必须修改既有的工厂类。这不符合开闭原则。所以简单工厂模式对于新增对象类型这个场景来说显得不够有弹性。
有没有办法不修改既有类就新增对象类型?
工厂方法模式就可以做到,因为它采用了继承:
//抽象pizza店
public abstract class PizzaStore{
public Pizza orderPizza(String type){
Pizza pizza = createPizza(type);
pizza.prepare();
pizza.bake();
return pizza ;
}
//不同地区的pizza店可以推出地方特色的pizza
protected abstract Pizza createPizza(String type) ;
}
//A商店提供芝士和培根两种pizza
public class PizzaStoreA extends PizzaStore{
@Override
protected Pizza createPizza(String type){
Pizza pizza ;
if(type.equals("cheese")){
pizza = new CheesePizza();
}else if(type.equals("bacon")){
pizza = new BaconPizza();
}
return pizza ;
}
}
简单工厂模式将构建对象的细节封装在一个静态方法中(静态方法无法被继承),而工厂方法模式将其封装在一个抽象方法中,这样子类可以通过重写抽象方法新增 pizza。
现在是介绍另一个设计原则的绝佳时机,它就是 “依赖倒置原则” :上层组件不能依赖下层组件,并且它们都不能依赖具体,而应该依赖抽象。
上面的例子中PizzaStore
是上层组件,CheesePizza
是下层组件,如果直接在PizzaStore
中构建CheesePizza
就违反了依赖倒置原则,经过工厂模式的重构,PizzaStore
依赖于Pizza
这个抽象,同时CheesePizza
也依赖于这个抽象。所以违反依赖倒置会让代码缺乏弹性,不易扩展。
Android 中RecyclerView.Adapter
就运用了工厂方法模式:
public abstract static class Adapter<VH extends ViewHolder> {
//封装了各式各样ViewHolder的构建细节,延迟实现构建细节到子类中
public abstract VH onCreateViewHolder(ViewGroup parent, int viewType);
}
3.抽象工厂模式
如果需要构建一组对象怎么办?
抽象工厂模式用来处理这种情况,它将构建一组对象的细节封装在一个接口中:
//抽象原料工厂(原材料构建者)
public interface IngredientFactory{
void Flour createFlour() ;
void Sause createSause();
}
//原材料使用者
public class Pizza{
private Flour flour;
private Sause sause;
//使用组合持有构建者
private IngredientFactory factory;
//注入一个具体构建者
//同一种pizza,在不同地区可能会有不同口味
//那是因为虽然用的是同类原材料(抽象),当产地不同味道就不同(具体)
public Pizza(IngredientFactory factory){
this.factory = factory;
}
//使用具体工厂构建原材料(发生多态的地方)
public void prepare(){
flour = factory.createFlour();
sause = factory.createSause();
}
public void bake(){}
public void cut(){}
}
//具体工厂
public class FactoryA implements IngredientFactory{
public Flour createFlour(){
return new FlourA();
}
public Sause createSause(){
return new SauseA();
}
}
//构建pizza的时候传入具体工厂
public class PizzaStoreA extends PizzaStore{
@Override
protected Pizza createPizza(String type){
Pizza pizza ;
FactoryA factory = new FactoryA();
if(type.equals("cheese")){
pizza = new CheesePizza(factory);
}else if(type.equals("bacon")){
pizza = new BaconPizza(factory);
}
return pizza ;
}
}
如果地区B开了一家新pizza店,只需要新建FactoryB并在其中定义地区B原材料的构建方式,然后传入Pizza类,整个过程不需要修改Pizza基类。
抽象工厂模式 和 工厂方法模式 的区别在于:
前者适用于构建多个对象,并且使用组合。
后者适用于构建单个对象,并且使用继承。
/ 策略模式 /
变化是什么
对策略模式来说,变化就是一组行为,举个例子:
public class Robot{
public void onStart(){
goWorkAt9Am();
}
public void onStop(){
goHomeAt9Pm();
}
}
机器人每天早上9点工作。晚上9点回家。公司推出了两款新产品,一款早上8点开始工作,9点回家。另一款早上9点工作,10点回家。
面对这样的行为变化,继承是可以解决问题的,不过你需要新建两个Robot
的子类,重载一个子类的onStart()
,重载另一个子类的onStop()
。如果每次行为变更都通过继承来解决,那子类的数量就会越来越多(膨胀的子类)。更重要的是,添加增子类是在编译时新增行为, 有没有办法可以在运行时动态的修改行为?
如何应对变化
通过将变化的行为封装在接口中,就可以实现动态修改:
//抽象行为
public interface Action{
void doOnStart();
void doOnStop();
}
public class Robot{
//使用组合持有抽象行为
private Action action;
//动态改变行为
public void setAction(Action action){
this.action = action;
}
public void onStart(){
if(action!=null){
action.doOnStart();
}
}
public void onStop(){
if(action!=null){
action.doOnStop();
}
}
}
//具体行为1
public class Action1 implements Action{
public void doOnStart(){
goWorkAt8Am();
}
public void doOnStop(){
goHomeAt9Pm();
}
}
//具体行为2
public class Action2 implements Action{
public void doOnStart(){
goWorkAt9Am();
}
public void doOnStop(){
goHomeAt10Pm();
}
}
//将具体行为注入行为使用者(运行时动态改变)
public class Company{
public static void main(String[] args){
Robot robot1 = new Robot();
robot1.setAction(robot1);
Robot robot2 = new Robot();
robot2.setAction(robot2);
}
}
策略模式将具体的行为和行为的使用者隔离,这样的好处是,当行为发生变化时,行为的使用者不需要变动。
Android 中的各种监听器都采用了策略模式,比如:
public class RecyclerView{
//使用组合持有抽象滚动行为
private List<OnScrollListener> mScrollListeners;
//抽象滚动行为
public abstract static class OnScrollListener {
public void onScrollStateChanged(RecyclerView recyclerView, int newState){}
public void onScrolled(RecyclerView recyclerView, int dx, int dy){}
}
//动态修改滚动行为
public void addOnScrollListener(OnScrollListener listener) {
if (mScrollListeners == null) {
mScrollListeners = new ArrayList<>();
}
mScrollListeners.add(listener);
}
//使用滚动行为
void dispatchOnScrollStateChanged(int state) {
if (mLayout != null) {
mLayout.onScrollStateChanged(state);
}
onScrollStateChanged(state);
if (mScrollListener != null) {
mScrollListener.onScrollStateChanged(this, state);
}
if (mScrollListeners != null) {
for (int i = mScrollListeners.size() - 1; i >= 0; i--) {
mScrollListeners.get(i).onScrollStateChanged(this, state);
}
}
}
}
列表滚动后的行为各不相同,所以使用抽象类将其封装起来(其实和接口是一样的)。
策略模式的实战应用可以点击这里
juejin.im/post/5ce0e55ae51d451075366eeb
/ 模板方法模式 /
变化是什么
从严格意义上讲,模版方法模式并不能套用开篇的那句话:“它们增加了一层抽象将变化封装起来,然后对抽象编程,并利用多态应对变化”。因为如果这样说,就是在强调目的是 “应对变化” 。但模版方法的目的更像是 “复用算法”,虽然它也有应对变化的成分。
对模版方法模式来说,变化就是算法的某个步骤,举个例子:
public class View{
public void draw(Canvas canvas) {
...
// skip step 2 & 5 if possible (common case)
if (!verticalEdges && !horizontalEdges) {
// Step 3, draw the content
if (!dirtyOpaque) onDraw(canvas);
// Step 4, draw the children
dispatchDraw(canvas);
drawAutofilledHighlight(canvas);
// Overlay is part of the content and draws beneath Foreground
if (mOverlay != null && !mOverlay.isEmpty()) {
mOverlay.getOverlayView().dispatchDraw(canvas);
}
// Step 6, draw decorations (foreground, scrollbars)
onDrawForeground(canvas);
// Step 7, draw the default focus highlight
drawDefaultFocusHighlight(canvas);
if (debugDraw()) {
debugDrawFocus(canvas);
}
// we’re done...
return;
}
...
}
protected void dispatchDraw(Canvas canvas) {
}
}
节选了View.draw()方法中的某一片段,从注释中可以看出draw()定义了一个绘图的算法框架,一共有七个步骤,所有步骤都被抽象成一个方法,其中的变化在于,每个步骤对于不同类型的View都可能是不同的。所以为了让不同View复用这套算法框架,就把它定义在了父类中,子类可以通过重写某一个步骤来定义不同的行为。
模版方法模式一种常用的重构方法,它将子类的共用逻辑抽象到父类中,并将子类特有子逻辑设计成抽象方法供子类重写。
对比
模版方法模式 vs 工厂方法模式
从代码层面看,模版方法的实现方式和工厂方法模式几乎一样,都是通过子类重写父类的方法。唯一的不同是,工厂方法模式父类中的方法必须是抽象的,也就是说强制子类实现,因为子类不实现父类就无法工作。而模版方法模式父类中的方法可以是不抽象的,也就是说子类可以不实现,父类照样能工作。这种在父类中空实现的方法有一个专门的名字叫 “hook(钩子)” ,钩子的存在,可以让子类有能力对算法的流程进行控制,比如ViewGroup.onInterceptTouchEvent()。
模版方法模式 vs 策略模式
从产出来看,模版方法模式和策略模式是一个阵营的,因为他们产出的都是一组行为(算法),而工厂模式产出的是一个对象。但它们俩对算法的控制力不同,策略模式可以轻松的替换掉整个算法,而模版方法模式只能替换掉算法中的某个步骤。从代码层面来看,它们的实现方式也不同,策略模式使用组合,而模版方法模式使用继承。组合比继承更具有弹性,因为它可以在运行时动态的替换行为。
/ 后续 /
《Head First》是一本让我对设计模式理解升级的书,强烈推荐(本篇中工厂模式的例子摘自其中)。
欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,欢迎转发分享给更多人。欢迎加入程序员小乐技术交流群,在后台回复“加群”或者“学习”即可。
猜你还想看
面试官:小伙汁,你画的SpringMVC请求处理过程是从网上抄的吧?
嘿,你在看吗?
标签:理念,相同,void,模式,Pizza,抽象,设计模式,public,pizza 来源: https://blog.51cto.com/u_15233911/2871901