最近有个校招同学跟我分享了一年升2-1的感悟。
他主要提到三点：
1、要发挥**主观能动性，**多想需求，多想产品没有想到的地方
2、在各种技术会议上，多露脸
3、多找+1沟通
他还提到，在实际工作过程中，《设计模式》基本是必学的，比如他面试的时候就遇到了面试官问策略模式。如下：
面试官: 你好，今天我们来谈一谈策略模式。首先，你能给我解释一下策略模式是什么吗？
求职者: 当然。策略模式是一种设计模式，它定义了一系列算法，并将每个算法封装起来，使它们可以互相替换。策略模式让算法的变化独立于使用算法的客户。
面试官: 很好，那你能给我举几个生活中的例子说明策略模式吗？
求职者: 当然可以。比如说我们出行，可以选择不同的交通工具，这些交通工具就像是不同的策略，每种方式都有不同的费用和时间。在商场购物时，可能会遇到不同的促销活动，如打折、满减、积分返利等，这些促销策略也是策略模式的例子。
面试官: 简单描述一下它的组成部分
求职者: 策略模式主要由三个部分组成：抽象策略类（AbstractStrategy），具体策略类（ConcreteStrategy），以及上下文类（Context）。抽象策略类定义了所有策略都必须实现的接口，具体策略类实现了这些接口，上下文类则持有一个策略类的引用，并根据需要调用其算法。
面试官: 那么，你能用代码示例说明一下这些类是如何交互的吗？
求职者: 当然，这是一个上下文类的定义，它接收一个策略对象，并通过调用策略的方法来执行具体的算法。
public class AbstractContext { AbstractStrategy strategy; public AbstractContext(AbstractStrategy strategy) { this.strategy = strategy; } public void ContextInterface() { strategy.ItsInterface(); } }
对应的抽象策略类和具体策略类可能是这样的：
public abstract class AbstractStrategy { public abstract void ItsInterface(); } public class ConcreteStrategyA extends AbstractStrategy { @Override public void ItsInterface() { // 具体的策略A的实现 } } public class ConcreteStrategyB extends AbstractStrategy { @Override public void ItsInterface() { // 具体的策略B的实现 } }
面试官: 非常好。在实际项目中，你如何看待策略模式的优缺点？
求职者: 策略模式的优点是它提供了一种将算法的使用和算法的实现分离开的方式，这样可以灵活地替换算法。缺点是如果策略很多，那么策略类的数量也会增加，这可能会导致管理上的复杂性。
面试官: 那么，你认为策略模式是否只局限于算法的选择呢？
求职者: 不，策略模式不仅仅局限于算法的选择。它可以用在任何需要在不同行为之间动态选择的场景中。策略模式主要是让客户端能够根据不同的情境选择合适的实现。
面试官: 对，这是一个很好的观点。那你能给出除算法选择之外的策略模式的例子吗？
求职者: 当然可以。策略模式也可以用于不同的业务规则处理。比如，一个电商平台可能根据不同的用户级别或者促销活动提供不同的价格计算策略。另外，它也可以用于选择不同的资源管理策略，例如不同的垃圾回收算法。
面试官: 现在让我们讨论一下策略模式和状态模式之间的区别。你能简单描述一下这两种模式吗
求职者: 当然。策略模式主要是用于选择算法的行为，它允许客户端从一组算法中选择一个算法，并且可以随时替换。而状态模式则是用于一个对象在其内部状态改变时改变它的行为，它让对象看起来似乎修改了它的类。
面试官: 那你认为它们之间有什么关键区别呢？
求职者: 关键区别在于它们各自改变行为的触发因素。策略模式通常是由客户端代码选择算法或行为，而状态模式通常是由对象内部的状态变化来自动改变行为。
面试官: 对，这是一个很好的区分。那么，你能给出一个状态模式的使用场景吗？
求职者: 一个典型的状态模式的使用场景是在用户界面组件中，比如按钮。按钮有不同的状态，如正常、悬浮、按下、禁用等。每个状态下按钮的行为和外观可能都不同，但按钮对象不需要知道当前是哪个状态，状态对象会根据按钮的操作来改变按钮的状态。
面试官: 很好，这个例子很贴切。谢谢你的解释，这就是我们今天讨论的全部内容。
