模板方法:

1. 它基于继承
2. 定义了不能被子类改变的算法框架。只有某些操作可以在子类中被重写
3. 父类完全控制算法并且只与具体类的某些步骤不同
4. 绑定在编译时完成

Template_method结构:

策略:

1. 它基于代表团/成分
2. 它改变了对象的内部结构通过修改方法行为
3. 它被用于算法族之间的切换
4. 它完全通过在运行时将一个算法替换为另一个算法改变对象在运行时的行为
5. 绑定在运行时完成

策略结构:

为了更好地理解，可以查看模板方法和策略文章。

相关文章:

JDK中的模板设计模式，无法找到定义方法集的方法按顺序执行

策略模式的真实例子

模板模式:

public abstract class RobotTemplate {
/* This method can be overridden by a subclass if required */
public void start() {
System.out.println("Starting....");
}


/* This method can be overridden by a subclass if required */
public void getParts() {
System.out.println("Getting parts....");
}


/* This method can be overridden by a subclass if required */
public void assemble() {
System.out.println("Assembling....");
}


/* This method can be overridden by a subclass if required */
public void test() {
System.out.println("Testing....");
}


/* This method can be overridden by a subclass if required */
public void stop() {
System.out.println("Stopping....");
}


/*
* Template algorithm method made up of multiple steps, whose structure and
* order of steps will not be changed by subclasses.
*/
public final void go() {
start();
getParts();
assemble();
test();
stop();
}
}




/* Concrete subclass overrides template step methods as required for its use */
public class CookieRobot extends RobotTemplate {
private String name;


public CookieRobot(String n) {
name = n;
}


@Override
public void getParts() {
System.out.println("Getting a flour and sugar....");
}


@Override
public void assemble() {
System.out.println("Baking a cookie....");
}


@Override
public void test() {
System.out.println("Crunching a cookie....");
}


public String getName() {
return name;
}
}

注意在上面的代码中，go()算法步骤总是相同的，但是子类可能为执行特定步骤定义不同的配方。

策略模式:

策略模式是指让客户端在运行时选择具体的算法实现。所有算法都是隔离且独立的，但是实现了一个公共接口，并且没有在算法中定义特定步骤的概念。

/**
* This Strategy interface is implemented by all concrete objects representing an
* algorithm(strategy), which lets us define a family of algorithms.
*/
public interface Logging {
void write(String message);
}


/**
* Concrete strategy class representing a particular algorithm.
*/
public class ConsoleLogging implements Logging {


@Override
public void write(String message) {
System.out.println(message);
}


}


/**
* Concrete strategy class representing a particular algorithm.
*/
public class FileLogging implements Logging {


private final File toWrite;


public FileLogging(final File toWrite) {
this.toWrite = toWrite;
}


@Override
public void write(String message) {
try {
final FileWriter fos = new FileWriter(toWrite);
fos.write(message);
fos.close();
} catch (IOException e) {
System.out.println(e);
}
}


}

完整的源代码，检查我的github 存储库。

策略公开为接口，模板方法公开为抽象类。这通常在框架中被大量使用。 如。 Spring框架的MessageSource类是用于解析消息的策略接口。客户端使用该接口的特定实现(策略)

和相同接口AbstractMessageSource的抽象实现，AbstractMessageSource具有解析消息的通用实现，并公开了resolveCode()抽象方法，以便子类可以以自己的方式实现它们。AbstractMessageSource是模板方法的一个例子。

http://docs.spring.io/spring/docs/4.1.7.RELEASE/javadoc-api/org/springframework/context/support/AbstractMessageSource.html

在此设计模式的模板方法中，子类可以覆盖一个或多个算法步骤，以允许不同的行为，同时确保仍然遵循总体算法(Wiki)。

模式名Template方法的意思是它是什么。假设我们有一个方法calculatessomething()，我们想要创建这个方法的模板。此方法将在基类中声明为非虚方法。假设这个方法是这样的。

CalculateSomething(){
int i = 0;
i = Step1(i);
i++;
if (i> 10) i = 5;
i = Step2(i);
return i;

在策略模式中，基类没有提供实现(这就是为什么基类实际上是类图中的接口)。

经典的例子是排序。根据需要排序的对象数量，创建适当的算法类(merge, bubble, quick等)，并将整个算法封装在每个类中。

现在我们可以将排序实现为模板方法了吗?当然可以，但是您不会发现有太多/任何共性可以抽象出来并放置在基本实现中。因此，它违背了模板方法模式的目的。

.

相似之处

策略和模板方法模式之间有很多相似之处。策略和模板方法模式都可以用于满足开闭原则，并使软件模块易于扩展而无需更改其代码。这两种模式都表示通用功能与该功能的详细实现的分离。但是，它们在提供的粒度方面略有不同。

差异

以下是我在研究这两种模式时观察到的一些差异:

1. 在Strategy中，客户端与策略的耦合更多 而在模板方法中，两个模块更紧密 李耦合。< / > 在Strategy中，大多数接口是通过抽象类can来使用的 也要视情况而定，而具体类是不用的 而在模板方法中使用的大多是抽象类或具体类
. . 在策略模式中，一般来说，整个类的行为是 另一方面，使用Template方法 中定义了样板代码，以减少代码重复 基框架或抽象类。在模板方法中，甚至可以有一个具体的类
2. 简单来说，你可以改变整个策略(算法) 不过，策略模式在模板方法中只有一些东西 改变(部分算法)，其余的东西保持不变。在模板方法中，不变步骤在抽象基类中实现，而 变量步骤要么给出一个默认实现，要么没有 根本不需要执行。在模板方法中，组件设计器 的顺序 步骤，但允许组件客户端扩展或替换一些

图片来自一口体积博客。

策略设计模式

• 支持组成。
• 为您提供在运行时更改对象行为的灵活性。
• 减少客户端代码和解决方案/算法代码之间的耦合。

模板方法设计模式

• 更喜欢继承而不是组合
• 在基类中定义算法。算法的各个部分可以在子类中定制。

我认为主要的区别是，有了模板，你需要一个算法来做一些事情，但让我们说，在算法的中间，你想要运行不同的行为，所以你可以发送一个接口的实现，使算法在运行时动态。

但是对于策略，你实际上有完全不同的算法执行而不仅仅是算法的一个变体，然后你选择运行哪个算法，但是模板你只有一个变体的算法。

最后，你可以实现你想要的，使用模板作为策略，反之亦然，但我看到了区别。

模板方法模式善于阐明算法的整体步骤，而策略模式适合灵活性和可重用性，因此如果需要，可以将策略组合在一起，例如:jdk8中的许多功能接口，如Comparator.reversed().thenComparing(Comparator)是策略的一个角色。

模板方法模式侧重于更高的内聚性，而策略模式则与上下文对象松散耦合以分离关注点。

策略易于维护，因为上下文不知道具体的策略，无论主要算法在上下文中发生什么变化都不会影响策略。另一方面，如果在抽象模板类中改变算法的框架，可能会影响其子类的升级。

它们都是不同的技术来达到相同的结果，所以问题是在什么时候使用哪一种。

• 如果你正在使用一个框架或库，你不能访问源代码，你想改变一个类的一些行为，所以你必须选择模板方法。这仅仅意味着继承。
• 如果您正在开发一个类，并且很明显需要以不同的方式实现逻辑的某些部分以处理各种情况，则采用Strategy模式。策略比模板法更可靠。它涵盖了依赖倒置和打开/关闭原则。因此，它是可扩展的，而且易于测试。
• 如果您正在开发一个类，并且您不知道将来会发生什么变化，请将您的逻辑尽可能地划分为独立的和单一的负责函数。只是这一点。(既不是模板方法也不是策略)。