运维.售后
论坛
潜水/灌水快乐,沉淀知识,认识更多同行。
ToB圈子
加入IT圈,遇到更多同好之人。
朋友圈
看朋友圈动态,了解ToB世界。
博客
Blog
ToB门户
了解全球最新的ToB事件
排行榜
Ranklist
文库
业界最专业的IT文库,上传资料也可以赚钱
下载
分享
Share
导读
Guide
相册
Album
记录
Doing
搜索
本版
文章
帖子
ToB圈子
用户
免费入驻
产品入驻
解决方案入驻
公司入驻
案例入驻
登录
·
注册
只需一步,快速开始
账号登录
立即注册
找回密码
用户名
Email
自动登录
找回密码
密码
登录
立即注册
首页
找靠谱产品
找解决方案
找靠谱公司
找案例
找对的人
专家智库
悬赏任务
圈子
SAAS
ToB企服应用市场:ToB评测及商务社交产业平台
»
论坛
›
软件与程序人生
›
后端开发
›
Java
›
建造者模式
建造者模式
美丽的神话
金牌会员
|
2023-9-11 05:22:49
|
显示全部楼层
|
阅读模式
楼主
主题
894
|
帖子
894
|
积分
2682
建造者模式
案例引入
1.建房子,过程分为打桩,砌墙,封顶。
2.房子有各种各样的,比如普通房,高楼,别墅,各种房子要求不一样,但是建造过程是一样的。
传统方式实现
代码如下
public abstract class AbstractHouse {
public abstract void buildBasic();
public abstract void buildWalls();
public abstract void roofed();
public void build(){
this.buildBasic();
this.buildWalls();
this.roofed();
}
}
public class CommonHouse extends AbstractHouse{
@Override
public void buildBasic() {
System.out.println("普通房子打地基");
}
@Override
public void buildWalls() {
System.out.println("普通房子砌墙");
}
@Override
public void roofed() {
System.out.println("普通房子封顶");
}
}
public class HighBuilding extends AbstractHouse{
@Override
public void buildBasic() {
System.out.println("高楼打地基");
}
@Override
public void buildWalls() {
System.out.println("高楼砌墙");
}
@Override
public void roofed() {
System.out.println("高楼封顶");
}
}
public class Client {
public static void main(String[] args) {
CommonHouse commonHouse = new CommonHouse();
commonHouse.build();
}
}
复制代码
传统方式分析
1.优点是比较好理解,简单易操作。
2.设计的程序结构,过于简单,没有设计缓存层对象,程序的扩展和维护不好,也就是说,这种设计方案,把产品(房子)和创建房子的过程耦合在一起,耦合性过高。
3.解决方案 => 建造者模式
基本介绍
1.建造者模式(Builder Pattern)又叫生成器模式,是一个对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类),使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。
2.建造者模式是一步一步创建一个复杂对象,它允许用户通过指定复杂对象的类型和内容就可以构建他们,用户不需要知道内部的具体构建细节。
构建者模式的四个角色
1.Product(产品角色),一个具体的产品对象。
2.Builder(抽象建造者),创建一个Product对象的各个部件指定的接口/抽象类。
3.ConcreteBuilder(具体建造者),实现接口,构建和装配各个部件。
4.Director(指挥者),构建一个使用Builder接口的对象。它主要用于创建一个复杂的对象。作用,一是隔离客户与对象的生成过程。二是负责控制产品对象的生成过程。
建造者模式完成案例
uml类图
代码实现
//house 对应建造者模式中的 产品
public class House {
//产品对应的属性
private String basic;
private String wall;
private String roofed;
public String getBasic() {
return basic;
}
public void setBasic(String basic) {
this.basic = basic;
}
public String getWall() {
return wall;
}
public void setWall(String wall) {
this.wall = wall;
}
public String getRoofed() {
return roofed;
}
public void setRoofed(String roofed) {
this.roofed = roofed;
}
}
//抽象的建造者
public abstract class HouseBuild {
//为了给产品的各个属性,赋值,并生成一个产品(House)
//所以需要设置一个House对象 House类组合于HouseBuild类
protected House house = new House();
//定义创建一个House对象的流程的抽象方法
public abstract void buildBasic();
public abstract void buildWalls();
public abstract void roofed();
//返回一个house
public House getHouse(){
return house;
}
}
//高楼的构建过程
public class HighFloorBuild extends HouseBuild{
@Override
public void buildBasic() {
house.setBasic("50m");
System.out.println("高楼打地基50m");
}
@Override
public void buildWalls() {
house.setWall("15cm");
System.out.println("高楼砌墙15cm");
}
@Override
public void roofed() {
house.setRoofed("封顶");
System.out.println("高楼封顶");
}
}
//普通房子的build过程
public class CommonHouseBuild extends HouseBuild{
//在实际使用建造者模式时,这些重写的构建方法,往往是对
//产品属性的赋值
@Override
public void buildBasic() {
house.setBasic("5m");//设置产品属性
System.out.println("普通方法打地基5m");
}
@Override
public void buildWalls() {
house.setWall("厚10cm");
System.out.println("普通房子砌墙厚10cm");
}
@Override
public void roofed() {
house.setRoofed("封顶");
System.out.println("普通房子封顶");
}
}
/**
* @author 长名06
* @version 1.0
* 构建过程的指挥者,这样的写法,有一个坏处 就是当一个产品可以由不同的构建过程
* 即产品构建者中,对应的构建流程的方法,以不同的顺序生成的话 就要写 多个产品build方法,这样会多写一些代码
* 我记得曾经使用过jdk或者spring框架自带的api,其中他们是这样写的
* 一个产品对应的build器中有构建过程的方法,最后也有一个build()
* 即是说,代码编写者,可以自己定义产品的构建过程,最后调用build()方法,返回一个
* 产品对象
* 在使用设计模式的时候,重要的是使用该思想,去进行产品和产品构建的解耦
* 并不在于形似
* 老师教的是一个完整的设计模式该有的角色,但是并不是这些角色都存在才能使用建造者模式
*/
public class HouseBuildDirector {
//指挥者决定对于构建方法的调用流程
//所以需要一个对应的HouseBuild的对象用,来调用代表构建过程的方法
//HouseBuild类 组合于HouseBuildDirector类
private HouseBuild houseBuild;
public HouseBuildDirector(){}
//该对象就不使用默认的了 可以使用构建器方法完成houseBuild赋值
public HouseBuildDirector(HouseBuild houseBuild) {
this.houseBuild = houseBuild;
}
//也可使用setter方法完成赋值
public void setHouseBuild(HouseBuild houseBuild){
this.houseBuild = houseBuild;
}
//定义一个build方法,并再构建方法中,设置构建产品的流程
// (即是调用产品构建方法的顺序)
public House build(){
//执行构建产品流程,完成产品对应属性的赋值
houseBuild.buildBasic();
houseBuild.buildWalls();
houseBuild.roofed();
//返回构建后的产品
return houseBuild.getHouse();
}
}
public class Client {
public static void main(String[] args) {
HouseBuildDirector houseBuildDirector = new HouseBuildDirector();
houseBuildDirector.setHouseBuild(new CommonHouseBuild());
House commonHouse = houseBuildDirector.build();
houseBuildDirector.setHouseBuild(new HighFloorBuild());
House highFloor = houseBuildDirector.build();
}
}
复制代码
建造者模式在JDK源码分析
1.java.lang.StringBuilder的建造者模式
2.StringBuilder关系图
3.StringBuilder关系图分析
3.1Appendable接口定义了多个append方法(抽象方法),即Appendable接口为抽象构建者,定义了抽象方法
3.2AbstractStringBuilder实现了append方法,这里的AbstractStringBuilder已经是具体抽象类了,只是不能实例化。
3.3StringBuilder即是指挥者角色,也是具体的构建者,建造方法的实现是AbstractStringBuilder完成,而StringBuilder继承了AbstractStringBuilder。
注意事项和细节
1.客户端(使用程序)
不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
2.每一个具体建造者都相对独立,而与其他的具体建造者无关,因此可以很方便地替换具体建造者或增加新的具体建造者,
用户使用不同的具体建造者即可得到不同的产品对象。
3.
可以更加精细地控制产品的创建过程
。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
4.
增加新的具体建造者无须修改原有类库的代码
,指挥者类针对抽象建造者类编程,系统扩展方便,符合“开闭原则”。
5.建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,
如果产品之间的差异性很大,则不适合使用建造者模式
,因此其使用范围受到一定的限制。
6.如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大,因此在这种情况下,要考虑是否选择建造者模式。
7.抽象工厂模式vs建造者模式:
抽象工厂模式实现对产品家族的创建
,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式不需要关心构建过程,只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的蓝图建造产品
,它的主要目的是通过组装零配件而产生一个新产品。
只是为了记录自己的学习历程,且本人水平有限,不对之处,请指正。
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
本帖子中包含更多资源
您需要
登录
才可以下载或查看,没有账号?
立即注册
x
回复
使用道具
举报
0 个回复
倒序浏览
返回列表
快速回复
高级模式
B
Color
Image
Link
Quote
Code
Smilies
您需要登录后才可以回帖
登录
or
立即注册
本版积分规则
发表回复
回帖并转播
回帖后跳转到最后一页
发新帖
回复
美丽的神话
金牌会员
这个人很懒什么都没写!
楼主热帖
Python 实现贪心算法
Spark快速上手(3)Spark核心编程-RDD转 ...
什么是超融合数据中心网络? ...
java中Files.mismatch方法具有什么功能 ...
哈工大软件构造Lab3(2022)
Kubernetes——Pod对象的声明周期(Pod ...
Python自动操作 GUI 神器——PyAutoGUI ...
C# net core 微信公众号导出历史文章 ...
微服务介绍
彻底理解 volatile 关键字及应用场景, ...
标签云
存储
服务器
快速回复
返回顶部
返回列表