[转载]设计模式袖珍版nbsp;连续转载之nbsp;-nbsp;Chainnbsp;ofnbsp;Responsibility(职责链)...

设计模式袖珍版nbsp;连续转载之nbsp;-nbsp;Chainnbsp;ofnbsp;Responsibility(职责链)[@more@]Chain of Responsibility定义
Chain of Responsibility(CoR) 是用一系列类 (classes)试图处理一个请求request,这些类之间是一个松散的耦合,唯一共同点是在他们之间传递request. 也就是说,来了一个请 求,A类先处理,如果没有处理,就传递到B类处理,如果没有处理,就传递到C类处理,就这样象一个链条(chain)一样传递下去。

如何使用?
虽然这一段是如何使用CoR,但是也是演示什么是CoR.

有一个Handler接口:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest();
  3. }


这是一个处理request的事例, 如果有多种request,比如 请求帮助 请求打印 或请求格式化:

最先想到的解决方案是:在接口中增加多个请求:
程序代码:

  1. public interface Handler{
  2.   public void handleHelp();
  3.   public void handlePrint();
  4.   public void handleFormat();
  5. }


具体是一段实现接口Handler代码:
程序代码:

  1. public class ConcreteHandler implements Handler{
  2.   private Handler successor;
  3.   public ConcreteHandler(Handler successor){
  4.   this.successor=successor;
  5. }
  6.   public void handleHelp(){
  7.     //具体处理请求Help的代码
  8.     ...
  9.   }
  10.   public void handlePrint(){
  11.     //如果是print 转去处理Print
  12.     successor.handlePrint();
  13.   }
  14.   public void handleFormat(){
  15.     //如果是Format 转去处理format
  16.     successor.handleFormat();
  17.   }
  18. }


一共有三个这样的具体实现类,上面是处理help,还有处理Print 处理Format这大概是我们最常用的编程思路。

虽然思路简单明了,但是有一个扩展问题,如果我们需要再增加一个请求request种类,需要修改接口及其每一个实现。

第二方案:将每种request都变成一个接口,因此我们有以下代码 :
程序代码:

  1. public interface HelpHandler{
  2.   public void handleHelp();
  3. }
  4. public interface PrintHandler{
  5.   public void handlePrint();
  6. }
  7. public interface FormatHandler{
  8.   public void handleFormat();
  9. }
  10. public class ConcreteHandler
  11.   implements HelpHandler,PrintHandler,FormatHandlet{
  12.   private HelpHandler helpSuccessor;
  13.   private PrintHandler printSuccessor;
  14.   private FormatHandler formatSuccessor;
  15.   public ConcreteHandler(HelpHandler helpSuccessor,
  16. PrintHandler printSuccessor,FormatHandler formatSuccessor)
  17.   {
  18.     this.helpSuccessor=helpSuccessor;
  19.     this.printSuccessor=printSuccessor;
  20.     this.formatSuccessor=formatSuccessor;
  21.   }
  22.   public void handleHelp(){
  23.     .......
  24.   }
  25.   public void handlePrint(){this.printSuccessor=printSuccessor;}
  26.   public void handleFormat(){this.formatSuccessor=formatSuccessor;}
  27. }


这个办法在增加新的请求request情况下,只是节省了接口的修改量,接口实现ConcreteHandler还需要修改。而且代码显然不简单美丽。

解决方案3: 在Handler接口中只使用一个参数化方法:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest(String request);
  3. }
  4. 那么Handler实现代码如下:
  5. public class ConcreteHandler implements Handler{
  6.   private Handler successor;
  7.   public ConcreteHandler(Handler successor){
  8.     this.successor=successor;
  9.   }
  10.   public void handleRequest(String request){
  11.     if (request.equals("Help")){
  12.       //这里是处理Help的具体代码
  13.     }else
  14.       //传递到下一个
  15.       successor.handle(request);
  16.     }
  17.   }
  18. }


这里先假设request是String类型,如果不是怎么办?当然我们可以创建一个专门类Request


最后解决方案:接口Handler的代码如下:
程序代码:

  1. public interface Handler{
  2.   public void handleRequest(Request request);
  3. }
  4. Request类的定义:
  5. public class Request{
  6.   private String type;
  7.   public Request(String type){this.type=type;}
  8.   public String getType(){return type;}
  9.   public void execute(){
  10.     //request真正具体行为代码
  11.   }
  12. }

那么Handler实现代码如下:
程序代码:

  1. public class ConcreteHandler implements Handler{
  2.   private Handler successor;
  3.   public ConcreteHandler(Handler successor){
  4.     this.successor=successor;
  5.   }
  6.   public void handleRequest(Request request){
  7.     if (request instanceof HelpRequest){
  8.       //这里是处理Help的具体代码
  9.     }else if (request instanceof PrintRequst){
  10.       request.execute();
  11.     }else
  12.       //传递到下一个
  13.       successor.handle(request);
  14.     }
  15.   }
  16. }


这个解决方案就是CoR, 在一个链上,都有相应职责的类,因此叫Chain of Responsibility.

CoR的优点:
因为无法预知来自外界的请求是属于哪种类型,每个类如果碰到它不能处理的请求只要放弃就可以。无疑这降低了类之间的耦合性。

缺点是效率低,因为一个请求的完成可能要遍历到最后才可能完成,当然也可以用树的概念优化。 在Java AWT1.0中,对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后,就使用Observer代替CoR

扩展性差,因为在CoR中,一定要有一个统一的接口Handler.局限性就在这里。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/374079/viewspace-957461/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/374079/viewspace-957461/

内容概要:本文围绕“基于多面体聚合与闵可夫斯基和的电动汽车可调能力评估研究”展开,系统提出一种基于多面体建模与几何运算的聚合方法,用于量化大规模电动汽车集群的可调节能力。通过构建单车充电可行域的凸多面体表示,并利用闵可夫斯基和实现群体调控潜力的数学聚合,形成统一的等效灵活资源集合,从而精确刻画电动汽车集群在时间与功率维度上的整体调节边界。该方法结合Matlab代码实现,支持对聚合结果的可视化呈现与边界分析,为电力系统中的需求响应、虚拟电厂运营及分布式能源调度提供了高精度建模工具。研究强调科研应兼顾严谨逻辑与创新思维,倡导借助YALMIP等优化工具提升建模效率与求解可靠性。; 适合人群:具备电力系统分析、凸优化理论或运筹学背景,从事新能源并网、电动汽车调度、综合能源系统等方向的研究生、科研人员及工程技术人员。; 使用场景及目标:①掌握多面体建模与闵可夫斯基和在电力系统灵活性聚合中的数学原理与实现方法;②学习利用Matlab完成电动汽车集群可调能力的建模、聚合与可视化分析;③应用于虚拟电厂资源聚合、需求响应潜力评估、配电网柔性负荷调控等实际场景的建模与优化决策。; 阅读建议:建议读者结合文中Matlab代码逐模块复现算法流程,重点理解多面体定义、约束处理及闵可夫斯基和的近似计算实现,同时参考提供的YALMIP工具包资源,深入掌握优化建模技巧,以全面提升对复杂系统聚合建模的能力。
内容概要:本文系统研究了基于Wasserstein生成对抗网络(W-GAN)的光伏出力场景生成方法,旨在应对新能源出力的高度不确定性。相较于传统GAN,W-GAN通过引入Wasserstein距离与梯度惩罚机制,显著提升了模型训练的稳定性与生成数据的质量,能够更精确地捕捉光伏功率时序数据的波动性与时序相关性。研究详细阐述了模型架构设计、损失函数构建、梯度惩罚项(GP)的实现细节,并通过Python代码实现了完整的数据预处理、模型训练、场景生成与后评估流程。生成的高保真光伏场景在统计特性(如分布形态、波动幅度、日内趋势)上与真实数据高度吻合,有效满足了电力系统对不确定性建模的严苛要求。; 适合人群:具备Python编程能力和深度学习基础知识,从事新能源发电预测、电力系统规划、运行调度、储能配置及风险管理等领域的研究生、科研人员和工程技术人员。; 使用场景及目标:①为含高比例光伏的电力系统进行可靠性评估、优化调度与安全校核提供高质量、多样化的输入场景;②支撑储能系统容量配置、需求响应策略制定等决策,以应对光伏出力的波动性;③作为深度学习在能源领域应用的典型案例,服务于相关课题的教学、科研与项目开发。; 阅读建议:建议读者深入研读并运行所提供的Python代码,重点关注W-GAN中判别器(Critic)的构造、梯度惩罚项的编码实现以及训练过程中的超参数(如学习率、惩罚系数)调优策略,可通过对比生成场景与真实场景的可视化结果来评估模型性能,并尝试将其扩展至条件W-GAN(CW-GAN)以生成特定气象条件下的光伏场景。
内容概要:本文围绕基于生成对抗网络(GAN)与Wasserstein GAN(W-GAN)的光伏场景生成展开研究,重点介绍如何利用Python代码实现W-GAN模型,以生成高质量、高稳定性的光伏发电出力场景数据。相较于传统GAN,W-GAN通过引入Wasserstein距离和梯度惩罚机制,有效缓解了训练过程中的模式崩溃与梯度消失问题,显著提升了生成数据的真实性和多样性。该方法在新能源出力不确定性建模、电力系统仿真分析等领域具有重要应用价值。文中提供了完整的实现流程,涵盖数据预处理、网络结构设计、损失函数构建、模型训练优化及生成结果可视化等关键环节。; 适合人群:具备一定Python编程能力和深度学习基础,从事新能源发电预测、电力系统规划、智能电网仿真或人工智能算法应用等相关方向的研究人员及高校研究生。; 使用场景及目标:①用于构建高精度的光伏出力不确定性场景集,支撑电力系统调度决策、储能配置与风险评估;②为高比例可再生能源接入下的电力系统提供可靠、多样化的输入场景,提升仿真与优化模型的鲁棒性;③帮助研究者深入理解W-GAN的理论机制与工程实现,推动其在能源系统建模中的创新应用。; 阅读建议:建议读者结合提供的代码进行动手实践,重点关注判别器与生成器的网络架构设计、Wasserstein损失函数的实现方式以及梯度惩罚项的添加技巧,同时可在不同气候区域或时间尺度的光伏数据集上进行迁移实验,进一步验证模型泛化能力。
内容概要:本文详细介绍了“计及风电不确定性的电力系统黑启动恢复模型”的Matlab代码实现,旨在通过仿真手段研究在风电出力具有强波动性和不可预测性的背景下,电力系统发生大范围停电事故后的黑启动恢复过程。该模型综合考虑风电不确定性对系统频率稳定、电压支撑能力及关键恢复路径供电可靠性的影响,采用鲁棒优化或分布鲁棒优化等先进数学方法构建恢复策略,科学制定机组启动优先级、功率爬升计划与网络重构路径,确保系统在复杂不确定性环境下仍能安全、有序、高效地实现电网重建。文中强调科研需具备严密逻辑、善于借助成熟工具与方法,并倡导结合创新思维推进研究,建议读者循序渐进学习,避免陷入技术细节迷宫。完整资源可通过指定公众号或网盘接获取。; 适合人群:具备电力系统分析、优化理论及随机建模基础知识,熟悉Matlab编程与优化工具箱(如Yalmip、CPLEX等),从事电力系统恢复控制、高比例新能源并网安全、不确定性优化调度等相关方向的研究生、科研人员及工程技术人员。; 使用场景及目标:①深入研究高比例风电接入场景下电力系统黑启动的关键挑战与应对策略;②掌握不确定性建模(如随机规划、鲁棒优化、分布鲁棒优化)在电力系统恢复中的具体应用方法;③复现、验证并拓展相关高水平学术论文中的数学模型与求解流程,提升科研实践能力。; 阅读建议:建议结合文中提供的完整代码、模型说明文档及参考文献,按照逻辑结构逐步学习,重点钻研风电不确定性刻画、黑启动阶段动态建模、多约束耦合机制与优化算法实现等核心环节,鼓励动手调试参数、修改模型结构并进行对比实验,以深化对现代电力系统恢复机制与智能优化技术融合应用的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值