面试题：Java抽象类与接口在复杂设计模式组合中的应用权衡

Question

在一个融合了多种设计模式（如工厂模式、装饰器模式、观察者模式）的大型Java项目架构中，如何根据业务需求和系统架构特点，在抽象类和接口之间进行合理选择，以确保系统的可扩展性、灵活性和可维护性？请结合具体场景详细阐述选择的原则和思路。

Answer 1

选择原则和思路

1. 抽象类
   • 场景：当多个子类具有一些共同的属性和行为，并且这些属性和行为可以在抽象类中进行统一实现时，适合使用抽象类。例如，在一个图形绘制系统中，可能有圆形、矩形、三角形等图形类，它们都有一些共同的属性（如颜色）和行为（如绘制方法），可以将这些共同部分提取到一个抽象的Shape类中。
   • 优势：
     • 代码复用：抽象类可以包含具体的方法实现，子类可以直接继承并复用这些代码，减少重复代码。比如在上述Shape抽象类中实现setColor方法，所有子类都能直接使用。
     • 定义部分实现：对于一些通用的行为但又不完全相同的情况，可以在抽象类中定义部分实现，子类根据自身需求进行扩展。例如Shape抽象类中的draw方法，抽象类可以提供一些通用的绘制前准备代码，子类再具体实现自己的绘制逻辑。
   • 劣势：Java 中类是单继承的，如果一个类继承了抽象类，就不能再继承其他类，限制了类的继承结构。
2. 接口
   • 场景：当需要实现多态性，并且不同的实现类之间没有太多共同的实现逻辑时，适合使用接口。例如，在一个电商系统中，不同的支付方式（如支付宝支付、微信支付、银行卡支付）可以通过实现一个Payment接口来实现支付功能。
   • 优势：
     • 多实现：一个类可以实现多个接口，这使得类具有更灵活的扩展性。比如一个类既可以实现Payment接口，又可以实现Loggable接口来记录支付日志。
     • 解耦：接口定义了行为规范，实现类只关注如何实现这些行为，而不关心其他实现类的情况，实现了模块之间的解耦。例如支付模块和订单模块通过Payment接口进行交互，支付模块的具体实现变化不会影响订单模块。
   • 劣势：接口中的方法默认是抽象的，不能有具体实现（Java 8 之前），这意味着实现类需要自己实现所有方法，可能会导致代码重复。

结合设计模式分析

1. 工厂模式
   • 使用抽象类：如果工厂创建的对象具有一些共同的属性和行为，可以将这些对象的抽象定义为抽象类。例如，一个创建不同类型交通工具（汽车、飞机、轮船）的工厂，交通工具类可以定义为抽象类，包含一些通用的属性（如速度）和方法（如启动）。工厂根据不同条件创建不同具体类型的交通工具子类对象。
   • 使用接口：当工厂创建的对象之间没有太多共同实现逻辑，只是有共同的行为特征时，使用接口。比如创建不同类型的加密算法对象的工厂，加密算法类通过实现Encryption接口，工厂根据用户选择创建不同的加密算法实现类对象。
2. 装饰器模式
   • 使用抽象类：装饰器通常需要继承被装饰对象的抽象类。例如，在一个咖啡饮品系统中，有一个抽象的Coffee类，具体的咖啡种类（如拿铁、美式）继承自Coffee类。装饰器（如加糖、加奶）也继承自Coffee抽象类，在保持与被装饰对象相同抽象类型的同时，扩展其功能。
   • 使用接口：如果被装饰对象和装饰器之间只是需要实现一些行为，没有太多共同的属性和实现逻辑，可以使用接口。比如在一个图形绘制装饰系统中，图形对象实现Drawable接口，装饰器（如添加边框、添加阴影）也实现Drawable接口，通过组合的方式装饰图形对象。
3. 观察者模式
   • 使用抽象类：在观察者模式中，主题（被观察对象）可以是抽象类，包含一些管理观察者的通用方法，如添加、删除观察者等。具体的主题子类继承自该抽象类。例如，在一个新闻发布系统中，NewsPublisher抽象类管理观察者，具体的新闻发布子类继承自它。
   • 使用接口：观察者通常实现一个接口，主题只关心观察者是否实现了特定的更新方法。例如，Observer接口定义了update方法，具体的观察者类（如订阅者）实现该接口，主题在状态变化时通知所有实现了该接口的观察者。

总结

在选择抽象类和接口时，需要综合考虑业务需求和系统架构特点。如果多个子类有共同的实现和属性，优先考虑抽象类以实现代码复用；如果需要实现多态性且实现类之间差异较大，优先考虑接口以获得灵活性和扩展性。同时，结合具体的设计模式，根据模式的特点和需求合理选择抽象类或接口，以确保系统的可扩展性、灵活性和可维护性。