创建模式之二 建造者模式

建造者模式定义理解

什么是建造者模式:建造者模式:是将一个复杂的对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
对象的构建:就是创建对象的流程(有模板方法的影子)
对象的表示:而一个对象的表示是什么呢,对象的表示就是对象内部组件,表示不同就是组件不一致,这里的组件可以是本身产品对其他对象的引用,也可以是本身产品的某个属性.

理解:创建要有流程,这个流程就是去设置各个属性.而表示不同如何做到呢,就是虽然接口定义了流程 但是实现流程的细节不一致 就会表现不同了.

建造模式现实中的使用

肯德基麦丹劳,这两虽说垃圾食品但是为什么那么多人趋之若鹜,味道好啊没办法控制不住自己,为何味道好呢,因为他们的工艺流程都定好了,什么时候撒什么料,炸多少分钟都有流程所以 虽店千千万,味道却一样.
不用建造模式木有规范流程也有例子:咱中国地大物博,但是好多东西都是父子相承,师傅传弟子,传着传着就变味了,这就是木有流程造成的影响了.

建造模式的几个角色

Builder–抽象建造角色
ConcreteBuilder–具体建造角色
Director–导向角色
Product–产品角色

UML图

这里写图片描述
建造模式uml图

案例

这里引用大话模式种的造小人简化了:

   //抽象建造者
public interface PersonBuilder {
  //添加头
  void addHeader();
  //添加身体
  void addBody();
  //添加双手
  void addHands();
  //添加双脚
  void addFoot();
  Person getResult();
}
//具体建造者 这个是个瘦小人 建造者实现具体的细节 决定对象内在表示
public class ThinPersonBuilder implements PersonBuilder {
  private Person p = new Person();
  public void addHeader() {
    System.out.println("增加瘦头");
    p.setHeader("头");
  }

  public void addBody() {
    p.setBody("小身体");
  }

  public void addHands() {
    p.setHank("增加双手");
  }

  public void addFoot() {
    p.setFoot("增加双脚");
  }

  public Person getResult() {
    return p;
  }
}

/** 留个胖小人建造类给大家自己写下
 */

 //指导者  定义构建步骤
 public class Director {
  private PersonBuilder personBuilder = null;
  public Director(PersonBuilder builder){
    personBuilder = builder;
  }
  public void construct(){
    personBuilder.addHeader();
    personBuilder.addBody();
    personBuilder.addHands();
    personBuilder.addFoot();
  }
}

//客户端代码
public class Client {
  public static void main(String[] args){
    PersonBuilder builder = new ThinPersonBuilder();
    Director director = new Director(builder);
    director.construct();
    Person p = builder.getResult();
  }
}

这个造小人案例是一个构造模式的一个小案例,因为构造模式生成的是复杂的对象,有可能构建对象的过程相同但是本身的生成复杂对象是不同的,这时候可以通过定一个标识接口统一返回父类对象,但是如果要用子类特有属性就得向下转型,所以许多构建模式的具体类实现生产的对象可能都是不同的.

从上面的案例可以看到:1.小人要构建起来是比较复杂的,需要头,身体,手脚,而这里的构建就是指导者的construct方法定义构建.2.表示:表示是在具体构建产品的过程中建立的,所以构建与表示是相分离的.3.构建出来的表示可以是胖小人也可以是瘦小人,满足同样的构建过程有不同的表示.
建造者模式相比工厂模式:两者都是用于创建对象的,但不同的是建造模式侧重的是复杂对象的组装,而工厂模式侧重的是对象产品的创建

上一篇—工厂模式

AI 代码审查Review工具 是一个旨在自动化代码审查流程的工具。它通过集成版本控制系统(如 GitHub 和 GitLab)的 Webhook,利用大型语言模型(LLM)对代码变更进行分析,并将审查意见反馈到相应的 Pull Request 或 Merge Request 中。此外,它还支持将审查结果通知到企业微信等通讯工具。 一个基于 LLM 的自动化代码审查助手。通过 GitHub/GitLab Webhook 监听 PR/MR 变更,调用 AI 分析代码,并将审查意见自动评论到 PR/MR,同时支持多种通知渠道。 主要功能 多平台支持: 集成 GitHub 和 GitLab Webhook,监听 Pull Request / Merge Request 事件。 智能审查模式: 详细审查 (/github_webhook, /gitlab_webhook): AI 对每个变更文件进行分析,旨在找出具体问题。审查意见会以结构化的形式(例如,定位到特定代码行、问题分类、严重程度、分析和建议)逐条评论到 PR/MR。AI 模型会输出 JSON 格式的分析结果,系统再将其转换为多条独立的评论。 通用审查 (/github_webhook_general, /gitlab_webhook_general): AI 对每个变更文件进行整体性分析,并为每个文件生成一个 Markdown 格式的总结性评论。 自动化流程: 自动将 AI 审查意见(详细模式下为多条,通用模式下为每个文件一条)发布到 PR/MR。 在所有文件审查完毕后,自动在 PR/MR 中发布一条总结性评论。 即便 AI 未发现任何值得报告的问题,也会发布相应的友好提示和总结评论。 异步处理审查任务,快速响应 Webhook。 通过 Redis 防止对同一 Commit 的重复审查。 灵活配置: 通过环境变量设置基
【直流微电网】径向直流微电网的状态空间建模与线性化:一种耦合DC-DC变换器状态空间平均模型的方法 (Matlab代码实现)内容概要:本文介绍了径向直流微电网的状态空间建模与线性化方法,重点提出了一种基于耦合DC-DC变换器的状态空间平均模型的建模策略。该方法通过数学建模手段对直流微电网系统进行精确的状态空间描述,并对其进行线性化处理,以便于系统稳定性分析与控制器设计。文中结合Matlab代码实现,展示了建模与仿真过程,有助于研究人员理解和复现相关技术,推动直流微电网系统的动态性能研究与工程应用。; 适合人群:具备电力电子、电力系统或自动化等相关背景,熟悉Matlab/Simulink仿真工具,从事新能源、微电网或智能电网研究的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握直流微电网的动态建模方法;②学习DC-DC变换器在耦合条件下的状态空间平均建模技巧;③实现系统的线性化分析并支持后续控制器设计(如电压稳定控制、功率分配等);④为科研论文撰写、项目仿真验证提供技术支持与代码参考。; 阅读建议:建议读者结合Matlab代码逐步实践建模流程,重点关注状态变量选取、平均化处理和线性化推导过程,同时可扩展应用于更复杂的直流微电网拓扑结构中,提升系统分析与设计能力。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值