boolean hasCup() {
return true;
}
}
class ModernEra implements EraEnvironment {
}
class StoneAge implements EraEnvironment {
@Override
public boolean hasCup() {
return false;
}
}
// 基于组合的实现
@Value
class PersonInEra implements Person {
Person person;
EraEnvironment era;
@Override
public String drinkCoffee() {
if (era.hasCup()) {
return person.drinkCoffee();
}
return String.format("%s cannot drink, because there is no cup in the era.", person.getName());
}
@Override
public String getName() {
return person.getName();
}
public static void main(String[] args) {
PersonInEra eric = new PersonInEra(new DefaultPerson("Eric"), new StoneAge());
System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
}
}
进一步优化成协调者模式,可以保证各个 Colleague 类(Person、EraEnvironment)独立扩展。
如果以后还有影响 Person 行为的变量,比如天气、心情等,可以引入新的协调者。
可以看出,随着需求的增多,协调者可能越来越多,此时我们就需要重新进行分析,哪些条件可以看做Person的固有属性,对Person进行重构。
// 优化抽取出抽象类
class PersonInEra extends AbstractPersonInEra {
public PersonInEra(Person person, EraEnvironment era) {
super(person, era);
}
@Override
public String drinkCoffee() {
if (getEra().hasCup()) {
return getPerson().drinkCoffee();
}
return String.format("%s cannot drink, because there is no cup in the era.", getName());
}
public static void main(String[] args) {
PersonInEra eric = new PersonInEra(new DefaultPerson("Eric"), new StoneAge());
System.out.println("eric.drinkCoffee() = " + eric.drinkCoffee());
}
}
public abstract class AbstractPersonInEra implements Person {
private final Person person;
private final EraEnvironment era;
public AbstractPersonInEra(Person person, EraEnvironment era) {
this.person = person;
this.era = era;
}
@Override
public String getName() {
return person.getName();
}
protected Person getPerson() {
return person;
}
protected EraEnvironment getEra() {
return era;
}
@Override
public abstract String drinkCoffee();
}
面向对象原则分析
当然,根据对需求的不同理解和对未来需求的预期,我们可能选择不同的实现,这个问题还有可能用状态模式、策略模式等实现,不同的方法有优点也有缺点; 如果在面试中遇到这样的问题,一定要跟面试官明确背景和需求。
我们使用面向对象的基本原则分析下改动前后的代码:
1.单一职责原则(SRP):一个类/方法应该只有一个职责。
满足。以 PersonInEra::drinkCoffee 为例,其只负责根据环境,对调用方法进行选择。
2.开放封闭原则(OCP):软件实体应该对扩展开放,对修改关闭。
满足。对扩展开发不必多说,使用接口或抽象类都方便了拓展。
3.里氏替换原则(LSP):子类对象应该能够替换其父类对象并保持系统的行为正确性。
满足。我们使用时声明类型为接口 Person,使用的实例为其具体实现。
4.依赖倒置原则(DIP):高层模块不应该依赖于底层模块,而是应该通过抽象进行交互。
满足。client 使用了Person, Person的不同实现间的依赖都是接口或抽象类。 一个实体类抽象出接口是一个万金油式的好方法。
5.接口隔离原则(ISP):一个类对另一个类的依赖应该建立在最小的接口上。
满足。比如 AbstractPersonInEra 依赖的是 Person接口,这个接口并不包含其他不必要的方法。
6.合成/聚合复用原则(CARP):优先使用对象合成或聚合,而不是继承来实现代码复用。
满足。AbstractPersonInEra 使用的是组合实现。
7.迪米特法则(LoD):一个对象应该对其它对象保持最小的了解。 满足。这里还是看出了使用接口的好处,AbstractPersonInEra 只知道自己依赖了 Person 和 EraEnvironment, 对于依赖对象的实现一无所知。
策略模式
最后,你可以自己写个策略模式,和我写的策略模式比较一下,从面向对象设计的角度分析其优劣。
使用策略模式编写的代码如下:
// 策略模式,不改变原 DefaultPerson 的实现
@FunctionalInterface
public interface DrinkStrategy {
String drink();
}
public final class Persons {
private Persons(){}
@NotNull
private static DrinkStrategy stoneEraSupport(Person person, EraEnvironment era) {
return () -> {
if (era.hasCup()) {
return person.drinkCoffee();
}
r