建站教程

建站教程

Products

当前位置:首页 > 建站教程 >

设计模式第1招第4式之建造者模式(javascript设计模式外观模式的原理和使用方法)

GG网络技术分享 2025-03-18 16:13 7


设计模式第1招第4式之建造者模式



设计模式

前言:

本系列文章共23篇,详细介绍GOF (Gang Of Four)所定义的23种设计模式。共分为三大类对应标题中的3大招,每类中的每一种设计模式对应3大招中的某一式:

内容摘要:

  1. 定义

  2. 应用场景

  3. Java代码实例

  4. 优缺点

  5. 小结

一、定义

今天的主角是建造者模式,对,他是对象建造的楷模。建造者模式解决了复杂对象的构建问题。试想一下,如果一个类有n个属性,构造函数该怎么写?我不知道客户端会使用哪几个参数构造对象。是的,可以用setter()方法。其实有更好的做法,那就是建造者模式。做过Android的同学可能使用过Volley、Universal-Image-Loader这类的第三方法框架,开发者为了使其定制性够好,会定义很多属性供用户配置。这时,他们首选的就是建造者模式。

建造者模式:将一个复杂对象的构建过程与其表示分离,使得同样的构建过程可以创建不同的表示。

建造者模式UML图

二、应用场景

  1. 当一个类涉及到多个参数的构造问题时;

  2. 游戏中英雄的装备搭配场景;

  3. 新房装修的场景;

三、Java代码实例

本文只实现建造者模式的变种-简单建造者模式:

1. 建造者模式类;

建造者模式类部分-1

建造者模式类部分-2

2. 客户端使用。

客户端使用

四、优缺点

优点:

  1. 构建过程和表示分离,使得构建过程易扩展灵活多变;

  2. 易于构建过程的细节控制,比如某个属性的构造验证;

  3. 每个独立的构建过程可以发生变化而不影响其它过程。

缺点:

  1. 产品本身要有共性,范围受限;

  2. 需要生成的对象内部属性本身相互依赖;

  3. 暴露了部分构建细节。

五、小结

总算到小结了!构建过程是比较常用的设计模式之一。《Effective Java》一书中,对于对象的创建就建议使用静态工厂模式和构建者模式替换构造函数。建造者模式本身很复杂,但一般情况下使用简单建造者模式就够了。对于创建型设计模式还有一个原型模式,下一节介绍。还等什么?赶紧把设计模式用到你的程序中吧!!!

最可爱的人-程序员

javascript设计模式外观模式的原理和使用方法

本文介绍了javascript设计模式外观模式的原理和使用方法。与您分享,供您参考,如下所示:

简介:外观模式是一种常用的结构设计模式。引入了外观角色,简化了客户端与子系统的交互,为复杂的子系统调用提供了统一的入口,隐藏了系统的复杂性。度,减少子系统与客户端的耦合。

定义:为子系统中的一组接口提供统一入口。外观模式定义了一个高级接口,使该子系统更易于使用。

场景:我们画一个圆来介绍外观模式。

var Rectangle = function(){

this.draw = function(){

console.log(\'画一个矩形\');

}

}

var Circle = function(){

this.draw = function(){

console.log(\'画一个圆\');

}

}

var Triangle = function(){

this.draw = function(){

console.log(\'画一个三角形\');

}

}

var ShapeMaker = function(){

this.rectangle = new Rectangle();

this.circle = new Circle();

this.triangle = new Triangle();

this.drawRectangle = function(){

this.rectangle.draw();

}

this.drawCircle = function(){

this.circle.draw();

}

this.drawTriangle = function(){

this.triangle.draw();

}

}

var shapeMaker = new ShapeMaker();

shapeMaker.drawRectangle(); //画一个矩形

shapeMaker.drawCircle(); //画一个圆

shapeMaker.drawTriangle(); //画一个三角形

是不是豁然开朗?其实我们日常最常用的就是外观模式。我们的工具类,jquery,包括一些浏览器兼容,我们都会把他们封装到一个对象里。

这就是外观模式提倡的把复杂的操作封装到一个简单接口中。几乎所有的涉及多个业务对象交互的场景都可以考虑使用外观模式进行重构。

外观模式总结:

优点:

* 对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并且提升使用便捷度。

* 实现了客户端与子系统之间的松耦合关系,这使得子系统的变化不会影响客户端。

缺点:

* 不能姮好的限制客户端直接使用子系统类

* 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开关原则

适用场景:

* 需要对一个复杂子系统提供一个简单入口时可以采用外观模式

标签:

提交需求或反馈

Demand feedback