public abstract class Animal {
// 普通方法
public void sleep() {
System.out.println("动物在睡觉");
}
// 抽象方法
public abstract void makeSound();
}
2.1 抽象类与接口的核心差异对比
抽象类和接口在Java中像是两种不同的设计工具。抽象类更偏向于建立"是什么"的关系，接口则关注"能做什么"的能力。
语法层面的差异很明显。抽象类可以包含具体实现的方法，也能定义抽象方法，还能有构造器和成员变量。接口在Java 8之前只能声明抽象方法，现在虽然增加了默认方法和静态方法，但本质上仍然是行为规范的集合。
继承机制完全不同。一个类只能继承一个抽象类，这是Java单继承的限制。但可以实现多个接口，这种设计让接口在扩展性方面更有优势。就像一个人只能有一个生物学父亲，但可以同时具备程序员、音乐爱好者、摄影师等多种身份。
设计理念的差异更值得关注。抽象类描述的是"is-a"关系，比如Dog是Animal。接口描述的是"can-do"关系，比如Plane可以Fly。这种根本区别决定了它们的使用场景。
状态管理的方式也不同。抽象类可以定义成员变量并维护状态，子类继承这些状态。接口通常不涉及状态管理，只定义行为规范。这种差异在实际设计中经常影响选择。
我参与过一个电商项目，商品类使用了抽象类，因为所有商品都有价格、库存等共同状态。而可比较、可序列化这些能力则通过接口实现。这种混合设计让系统既保持了状态一致性，又具备了灵活的扩展能力。
2.2 实际开发中的选择策略
选择抽象类还是接口，往往取决于具体的设计需求。当需要为相关类建立紧密的继承关系时，抽象类通常是更好的选择。
考虑代码复用的程度。如果多个类有大量相同的代码和状态，抽象类可以提供更好的代码复用。接口更适合定义轻量级的行为契约，不涉及具体实现。
演化需求也很重要。抽象类在后期修改时可能破坏子类，因为子类依赖于父类的具体实现。接口的默认方法虽然能减少破坏性，但仍然需要谨慎设计。
团队协作的角度。接口作为契约，更适合大型团队并行开发。不同团队可以基于接口独立工作，最后集成时只要保证接口契约一致即可。
版本兼容性考虑。向接口添加新方法会破坏所有实现类，除非使用默认方法。抽象类添加具体方法通常不会破坏现有子类，这种演化特性在长期维护的项目中很关键。
设计模式的适用性。某些模式天然适合接口，比如策略模式、观察者模式。另一些模式如模板方法模式则更适合抽象类。理解这些模式的本质需求有助于做出正确选择。
2.3 混合使用抽象类与接口的最佳实践
现代Java开发中，混合使用抽象类和接口已经成为标准做法。这种组合能发挥两者的优势，创造出既灵活又稳定的设计。
模板方法模式结合接口是个经典组合。抽象类定义算法骨架，接口定义可插拔的行为。比如排序算法，抽象类处理排序流程，接口定义比较逻辑。
装饰器模式也经常混合使用。抽象组件类定义基础功能，接口定义装饰行为。这种设计既保证了基础结构的稳定，又提供了灵活的扩展能力。
我见过一个日志框架的设计很巧妙。抽象类处理日志级别、输出格式等通用逻辑，接口定义具体的日志输出方式（文件、控制台、网络）。这种设计让框架核心稳定，同时支持各种输出方式的灵活扩展。
层次化设计是另一个好实践。顶层使用接口定义核心契约，中间层用抽象类提供通用实现，底层是具体实现类。这种分层让系统既有统一的接口规范，又有可复用的代码实现。
默认方法的合理使用。Java 8的接口默认方法可以在不破坏现有实现的情况下扩展接口。但要注意默认方法的"菱形继承"问题，当多个接口有相同签名的方法时，需要在实现类中明确指定。
组合优于继承的原则在这里同样适用。优先考虑使用接口定义行为，然后用抽象类提供基础实现。这种设计让系统更灵活，更容易测试和维护。
抽象类和接口不是对立的选择，而是互补的工具。理解它们各自的特性和适用场景，才能在具体项目中做出最合适的设计决策。