策略模式

本篇是系列第二篇，标题起得有点大，希望内容对得起这个标题，这篇文章主要总结一下在 jQuery 中一些十分讨巧的 coding 方式，将会由浅及深，可能会有一些基础，但是我希望全面一点，对看文章的人都有所帮助，源码我还一直在阅读，也会不断的更新本文。 即便你不想去阅读源码，看看下面的总结，我想对提高编程能力，转换思维方式都大有裨益，废话少说，进入正题。 短路表达式 与 多重短路表达式 短路表达式这个应该人所皆知了。在 jQuery 中，大量的使用了短路表达式与多重短路表达式。 短路表达式：作为"&&"和"||"操作符的操作数表达式，这些表达式在进行求值时，只要最终的结果已经可以确定是真或假，求值过程便告终止，这称之为短路求值。这是这两个操作符的一个重要属性。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // ||短路表达式 var foo = a || b; // 相当于 if (a){ foo = a; } else { foo = b; } // &&短路表达式 var bar = a && b; // 相当于 if (a){ bar = b; } else { bar = a; } 当然，上面两个例子是短路表达式最简单是情况，多数情况下，jQuery 是这样使用它们的： 1 2 3 4 5 6 7 8 9 // 选自 jQuery

1、策略模式(Strategy) 将定义的算法家族、分别封装起来，让他们之间可以互相替换，从而让算法的变化不会影响到使用算法的用户。 策略模式属于 行为性模式 2、实现方式 Context上下文 Context 封装角色，起承上启下的作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。 /** * @Author: Liu * @Descripition: * @Date; Create in 2020/3/14 20:31 **/ public class Context { private IStrategy iStrategy ; public Context(IStrategy iStrategy){ this.iStrategy = iStrategy; } //上下文 public void algorithm(){ iStrategy.algorithm(); } } 策略角色 抽象策略角色，是对策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。 /** * @Author: Liu * @Descripition: * @Date; Create in 2020/3/14 20:26 **/ public interface IStrategy { void algorithm(); } 具体策略角色 用于实现抽象策略中的操作

什么是策略模式 策略模式是对算法的包装，把使用算法的责任和算法本身分隔开，委派给不同的对象管理。策略模式通常把一系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。 先直接上代码吧： //竞猜揭晓抽象类（应该有平手、有人竞猜成功、无人竞猜成功三种情况；所以对应的就是三种策略的算法） public abstract class GuessOperationAbs { /** * 发布竞猜结果：更新用户竞猜信息 */ public abstract void publishGuessResult(***); } /** * 平局的算法处理 **/ @Service public class FlatGuess extends GuessOperationAbs { @Override public void publishGuessResult() { } } /** * 有人竞猜成功的算法处理 **/ @Service public class HadWinGuess extends GuessOperationAbs { @Override public void publishGuessResult() { } } /** * 无人竞猜成功的算法处理 **/ @Service public class NotWinGuess extends

简单代理模式与策略模式在功能上的很大的区别是： 简单代理模式中，代理类知道被代理类的行为，因为代理类与被代理类实现的是同一个接口，因此代理类与被代理类的结构是相同的； 而策略模式中，策略容器并不知道内部策略的详细信息，因为容器并没有实现与内部策略相同的接口，即容器与内部策略只是简单的组合关系，容器只是将内部策略的行为抽取出来，进行了统一的实现。 两者得实现方式都类似，即代理模式中的代理类中实现和策略模式中的策略容器中的实现类似，都是通过多态的方式将具体的被代理类/具体的策略类当参数传入。 来源： oschina 链接： https://my.oschina.net/u/3605441/blog/1627179

策略模式定义了一系列算法，并将每个算法封装起来，使他们可以相互替换，且算法的变化不会影响到使用算法的客户。 需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数 抽象折扣类： public interface MemberStrategy { /** * 计算图书的价格 * @param booksPrice 图书的原价 * @return 计算出打折后的价格 */ public double calcPrice(double booksPrice); } 三个实现类：（初级会员、中级会员、高级会员） public class PrimaryMemberStrategy implements MemberStrategy { @Override public double calcPrice(double booksPrice) { System.out.println("对于初级会员的没有折扣"); return booksPrice; } } public class IntermediateMemberStrategy implements MemberStrategy { @Override public double calcPrice(double booksPrice) { System.out

一、策略模式的定义与特点 1 、定义：定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的用户。 2 、优点： 类的行为被封装进一组类中，可以被轻易地扩充与改变，如果需要，甚至可以在运行时改变行为 多重条件语句不易维护， 使用策略模式可以避免使用多重条件语句。 提供相同行为的不同实现，可以根据不同条件选择不同的行为。 扩展性好，方便增加新的行为实现，不用修改原代码，只要增加即可。 3 、缺点： 策略类数量可能会很多，每个策略都是一个类，复用的可能性小 所有的策略类都要对外暴露 二、策略模式的设计原则： 1 、找出应用中可能需要变化之处，把它们独立出来进行封装，不要和那些不需要变化的代码混在一起，这样做的好处是：一旦它真的变化了，只要更改相应部分即可，其他部分不会受到影响，这样代码变化引起的不经意后果变少，系统变得更有弹性。 2 、针对接口编程，而不是针对实现编程，即尽量将需要实现的功能 / 系统先进行抽象总结，形成接口，而具体的行为或者说实现部分作为可能会变化的部分，独立出来单独编码，一旦变化则其引起的后果会降低。 3 、多用组合，少用继承。 三、策略模式的结构 1 、抽象策略类：定义了公共接口 2 、具体策略类：封装了具体的实现算法或行为，继承自抽象策略类 3 、上下文 / 环境：用来维护一个对抽象策略类的对象的引用 四、策略模式的应用 1

定义 定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化不会影响到使用算法的用户。 if…else… 类型 行为型 适用场景 ①、系统有很多类，而它们的区别仅仅在于它们的行为不同。 ②、一个系统需要动态地在几种算法中选择一种。 优缺点 优点： ①、开闭原则 ②、避免使用多重条件转移语句 ③、提高算法的保密性和安全性 缺点： ①、客户端必须知道所有的策略类，并自行决定使用哪一个策略类 ②、 产生很多策略类 代码实现 案例：电商网站经常会在不同的节日搞不同的促销活动，例如：满减、立减、返现等等。根据这个场景来使用策略模式实现。 首先创建一个促销策略的接口 public interface PromotionStrategy { /** * 促销 */ void doPromotion ( ) ; } 然后，分别创建不同促销策略的实现类。 返现促销 public class FanXianPromotionStrategy implements PromotionStrategy { @Override public void doPromotion ( ) { System . out . println ( "返现促销,返回的金额存放到用户的余额中" ) ; } } 立减促销 public class LiJianPromotionStrategy

设计模式，无论是coder们业余聊天，还是面试时面试官喜欢出的问题中，都会看到它的影子。设计模式，是基于面向对象之上的，应用好设计模式，我们在平时开发，还是架构设计，在系统的架构性，可拓展，可维护性方面的考虑都会有质的提升。当我们会一些基础语法，逻辑控制之后，就需要考虑我现在写的代码，在以后的拓展，维护会有那些瓶颈，如何改善，这些问题考虑清楚后在进行编码，开发就会事半功倍。范围说小一点，基于Java , 无论是JDK源码，还是我们每天都在接触的各种框架，都使用了各种设计模式。 设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。 本文会先着重写一下策略模式的应用。后期考虑会写几篇博文来记录学习其他设计模式。 PS: 本人是在边学编写，如果有错误，望指正。 策略模式（Strategy Pattern） 在策略模式中，一个行为可以在系统运行时动态修改。这种类型设计模式是行为型设计模式，策略模式中，会有代表各种策略的对象和执行策略的context上下文对象。策略对象改变context执行的算法。 举例： 出门旅行，拥有很多出行策略，比如飞机，汽车，火车等； JDK AWT中的LayoutManager；

策略模式(Strategy)： 概念：对于一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以互相替换。 目的：环境仅依赖抽象策略，但是不依赖具体的某个策略，故可以做到在不改变环境的前提下，进行策略的更换。 优点：提供了管理一个算法族的解决方案，可以避免使用多重条件语句来判断具体采用哪个算法。 缺点：客户端必须知道所有的策略类，并自行决定使用哪一个策略类；策略模式会造成很多(策略)类。 角色： 环境(Context)：持有一个Strategy类的引用。 抽象策略(Strategy)：所有的具体策略类必须实现此接口。 具体策略(ConcreteStrategy)：包装了相关的算法。 jdk中的策略模式： /** * 环境ThreadPoolExecutor：持有一个RejectedExecutionHandler类的引用 */ public class ThreadPoolExecutor extends AbstractExecutorService { private volatile RejectedExecutionHandler handler; } /** * 抽象策略RejectedExecutionHandler */ public interface RejectedExecutionHandler { void rejectedExecution

package designpattern.pool; import designpattern.staticagent.MyConnecntion; import java.sql.Connection; import java.sql.SQLException; import java.util.ArrayList; import java.util.List; public class ConnectionPool { private static List<Connection> connections=new ArrayList<>(); static { for (int i=0;i<10;i++){ //可以考虑dbcp，c3p0的配置，进行设置 Connection connection=new MyConnecntion(); connections.add(connection); } } public static synchronized Connection getConnection() throws SQLException { for(Connection connection:connections){ MyConnecntion myConnecntion=(MyConnecntion)connection; if(!myConnecntion