OOP 面试题

OOP 面试涵盖内容

OOP 面试题示例

• 解释 OOP 的四大支柱并给出现实世界的例子。
  好回答应覆盖

  • 封装：隐藏内部状态，通过方法暴露行为
  • 继承：从父类派生子类，复用代码
  • 多态：同一接口不同实现，运行时动态绑定
  • 抽象：定义抽象概念，忽略细节

  查看范例答案

  OOP的四大支柱是封装、继承、多态和抽象。封装指将数据和操作数据的方法绑定在一起，并对外隐藏内部实现细节，例如银行账户类将余额字段设为私有，仅通过公开的存款和取款方法访问。继承允许一个类（子类）从另一个类（父类）继承属性和方法，实现代码复用，如汽车类继承交通工具类的颜色和速度属性，并添加自己的属性。多态意味着同一方法在不同对象上可以有不同的行为，例如Shape类定义draw()方法，Circle和Rectangle子类各自实现绘制方法，调用时根据实际对象类型执行对应版本。抽象是隐藏复杂实现细节，只暴露必要功能，通常通过抽象类或接口实现，如将移动设备抽象为可以打电话和发短信，而不关心具体是安卓还是iOS设备。这四个支柱共同支持了面向对象设计的灵活性、可维护性和可扩展性。

• 抽象类和接口有什么区别？什么时候你会使用哪一个？
  好回答应覆盖

  • 抽象类可以有构造器、字段、具体方法和抽象方法
  • 接口只能有抽象方法（Java 8前），Java 8后可以有默认方法和静态方法
  • 一个类只能继承一个抽象类，但可以实现多个接口
  • 抽象类用于“is-a”关系，接口用于“has-a”能力

  查看范例答案

  抽象类和接口都是实现抽象的方式，但关键区别在于：抽象类可以包含构造器、字段和具体方法，而接口（Java 8之前）只能有抽象方法，Java 8后引入了默认方法和静态方法。一个类只能单继承一个抽象类，但可以多实现多个接口。我们应该在类之间具有“is-a”关系时使用抽象类，例如Dog继承Animal，因为狗是一种动物，并且可以共享一些基础实现。而当我们想定义一组行为契约（能力）时使用接口，例如Flyable接口表示可以飞行的能力，鸟类、飞机类都可以实现它，但这些类没有共同的基类。通常优先使用接口以获得更大的灵活性和解耦，但若需要共享代码或状态，则考虑抽象类。在实际设计中，经常结合两者：使用抽象类作为骨架，接口定义行为。

• 用 Java（或你选择的语言）实现单例模式，并讨论线程安全性。
  好回答应覆盖

  • 单例模式确保一个类只有一个实例，并提供全局访问点
  • 线程安全实现方式：饿汉式、懒汉式（同步）、双重检查锁定、静态内部类、枚举

  查看范例答案

  单例模式的核心是限制类的构造方法为私有，并通过静态方法返回唯一实例。实现时需考虑线程安全性：最简单的饿汉式在类加载时就创建实例，天然线程安全但浪费资源；懒汉式延迟创建，但需同步确保线程安全，可以使用synchronized关键字修饰getInstance方法，但性能较差；更优的是双重检查锁定（Double-Checked Locking），先检查实例是否为空，若为空则同步创建，并再次检查，结合volatile关键字禁止指令重排序；静态内部类方式利用类加载机制保证延迟加载和线程安全；最推荐的是枚举单例，它简洁、线程安全且可防止反序列化破坏。实际开发中，若实例不昂贵，饿汉式足够；若需延迟加载且高并发，用静态内部类或枚举。

  // 双重检查锁定单例
  public class Singleton {
      private static volatile Singleton instance;
      private Singleton() {}
      public static Singleton getInstance() {
          if (instance == null) {
              synchronized (Singleton.class) {
                  if (instance == null) {
                      instance = new Singleton();
                  }
              }
          }
          return instance;
      }
  }
  // 枚举单例
  public enum SingletonEnum {
      INSTANCE;
      public void doSomething() {}
  }

• 设计一个形状（圆形、矩形）的类层次结构，计算面积，演示多态。
  好回答应覆盖

  • 定义Shape抽象类，包含calcArea()抽象方法
  • Circle和Rectangle继承Shape并实现calcArea()
  • 使用父类引用指向子类对象调用calcArea()，演示多态
  • 可添加printArea方法接受Shape参数，展示运行时多态

  查看范例答案

  多态通过方法重写实现：父类引用指向子类对象，调用重写的方法时执行子类的版本。在形状类层次中，Shape作为抽象父类定义calcArea()抽象方法，Circle和Rectangle分别实现自己的面积计算逻辑。当编写一个方法如printArea(Shape shape)时，传入Circle或Rectangle对象，calcArea()会动态调用对应的实现。这体现了开闭原则——对扩展开放，对修改封闭，新增形状只需添加新子类而不必修改现有代码。多态也提高了代码的灵活性，例如可以将所有形状放入Shape数组，统一遍历计算总面积。注意：若父类方法不声明为抽象，则无需重写，但抽象方法强制子类提供实现，更规范。

  abstract class Shape {
      abstract double calcArea();
  }
  class Circle extends Shape {
      private double radius;
      public Circle(double r) { radius = r; }
      @Override
      double calcArea() { return Math.PI * radius * radius; }
  }
  class Rectangle extends Shape {
      private double width, height;
      public Rectangle(double w, double h) { width = w; height = h; }
      @Override
      double calcArea() { return width * height; }
  }
  // 使用多态
  public class Main {
      public static void printArea(Shape s) {
          System.out.println("Area: " + s.calcArea());
      }
      public static void main(String[] args) {
          Shape circle = new Circle(5);
          Shape rect = new Rectangle(4, 6);
          printArea(circle); // 动态绑定到Circle
          printArea(rect);   // 动态绑定到Rectangle
      }
  }

• 继承如何导致紧耦合？优先使用组合而非继承——举例说明。
  好回答应覆盖

  • 继承破坏封装，子类依赖父类实现细节
  • 父类修改可能导致所有子类需要调整
  • 组合通过接口引用实现松耦合
  • 例子：交通工具的引擎行为，使用组合而非继承

  查看范例答案

  继承会导致紧耦合，因为子类通常依赖父类的内部实现细节。例如，若父类修改了某个方法的逻辑或添加了新的私有字段，所有子类可能受影响。此外，继承在编译时确定，难以在运行时改变行为。优先使用组合的原则是：通过将对象作为成员变量，委托其完成工作，而不是通过继承获取能力。例如，设计一个Car类，如果让Car继承Engine类，则改变引擎类型需要修改继承关系；更好的方式是Car类包含一个Engine接口的引用，在运行时可以注入不同的引擎实现（如ElectricEngine、GasEngine）。组合使得类更独立、易于测试和扩展。常见的“优先使用组合而非继承”实际是指，当存在“has-a”关系时用组合，而“is-a”关系时才考虑继承。滥用继承是设计坏味道，应尽量避免。

• 编写代码演示如何实现策略模式来计算运费。
  好回答应覆盖

  • 策略模式定义一系列算法，封装它们，使它们可以互相替换
  • 策略模式让算法独立于使用它的客户端
  • 运费计算示例：不同运输方式（快递、标准、海运）
  • 上下文（ShippingCostCalculator）持有运费策略接口引用

  查看范例答案

  策略模式将不同的算法封装成独立的策略类，并使它们可以互换。在运费计算场景中，定义ShippingStrategy接口包含calculate(double weight)方法，然后实现ExpressShipping、StandardShipping、SeaShipping等策略类。上下文类ShippingCalculator持有ShippingStrategy引用，并在calculate方法中委托给策略对象。客户端可以运行时设置不同策略，例如根据用户选择设置。这遵循开闭原则，增加新运费计算方式只需添加新策略类，无需修改现有代码。注意：策略模式会增加类的数量，且客户端需要了解不同策略的区别。实现时，策略通常是无状态的，可以复用。

  // 策略接口
  interface ShippingStrategy {
      double calculate(double weight);
  }
  // 具体策略
  class ExpressShipping implements ShippingStrategy {
      public double calculate(double weight) {
          return weight * 10.0; // 每公斤10元
      }
  }
  class StandardShipping implements ShippingStrategy {
      public double calculate(double weight) {
          return weight * 5.0; // 每公斤5元
      }
  }
  // 上下文
  class ShippingCalculator {
      private ShippingStrategy strategy;
      public void setStrategy(ShippingStrategy s) { this.strategy = s; }
      public double calculate(double weight) {
          return strategy.calculate(weight);
      }
  }
  // 客户端使用
  public class Client {
      public static void main(String[] args) {
          ShippingCalculator calc = new ShippingCalculator();
          calc.setStrategy(new ExpressShipping());
          System.out.println("Express cost: " + calc.calculate(2.5));
          calc.setStrategy(new StandardShipping());
          System.out.println("Standard cost: " + calc.calculate(2.5));
      }
  }

• 什么是里氏替换原则？给出一个违反该原则的代码示例。
  好回答应覆盖

  • LSP要求子类对象可以替换父类对象，程序行为不变
  • 违反LSP：重写方法时改变前提或后置条件
  • 经典例子：正方形继承矩形，改变宽度时高度也随之改变

  查看范例答案

  里氏替换原则（LSP）由Barbara Liskov提出，核心思想是：如果S是T的子类型，那么T类型的对象可以被S类型的对象替换，而不会影响程序的正确性。通俗讲，子类应该可以替代父类使用。违反该原则的典型例子是让正方形继承矩形。矩形有宽度和高度属性，设置宽度不影响高度。但正方形为了维持边长相等，重写setWidth方法时同时修改了高度，导致客户端代码期望只改变宽度却意外改变了高度。例如，计算矩形面积的代码：rect.setWidth(5); rect.setHeight(10); 期望面积是50，但若rect是正方形对象，setWidth(5)后高度也被改为5，再setHeight(10)又改宽度为10，最终面积100，违反了期望。正确做法是不要滥用继承，或者使用抽象类/接口让矩形和正方形都实现Shape接口，各自维护自己的状态。

  // 违反LSP的例子
  class Rectangle {
      protected int width, height;
      public void setWidth(int w) { width = w; }
      public void setHeight(int h) { height = h; }
      public int getArea() { return width * height; }
  }
  class Square extends Rectangle {
      @Override
      public void setWidth(int w) {
          super.setWidth(w);
          super.setHeight(w); // 维持正方形
      }
      @Override
      public void setHeight(int h) {
          super.setHeight(h);
          super.setWidth(h);
      }
  }
  // 测试
  public class Test {
      public static void main(String[] args) {
          Rectangle r = new Square();
          r.setWidth(5);
          r.setHeight(10);
          System.out.println(r.getArea()); // 期望50，实际100
      }
  }

• 设计一个餐厅订单系统，包含 MenuItem、Order 和 Payment 类，确保良好的 OOP 设计。
  好回答应覆盖

  • 系统包含MenuItem（名称、价格）、Order（订单项列表、总价）、Payment（支付处理）
  • 使用组合而非继承：Order包含MenuItem列表
  • 多态：不同支付方式（信用卡、现金、移动支付）
  • 封装：每个类保护自己的数据
  • 开闭原则：新增支付方式无需修改现有代码

  查看范例答案

  餐厅订单系统设计应遵循单一职责原则：MenuItem表示菜单项（名称、价格），Order管理订单项（添加菜品、计算总价），Payment处理支付。Order与MenuItem是组合关系，Order包含一个List<MenuItem>。支付方式使用策略模式，定义PaymentStrategy接口，包含pay(double amount)方法，实现类如CreditCardPayment、CashPayment。Order类包含计算总价方法，并接受PaymentStrategy进行支付。这样，新增支付方式只需添加新策略类。MenuItem是不可变对象更安全。考虑多线程场景，订单处理可能并发，需注意线程安全（例如使用不可变对象或同步）。另外，可添加OrderItem类包装MenuItem和数量，而非直接使用MenuItem列表。整体设计体现了封装、多态和组合优先于继承的原则。

  class MenuItem {
      private String name;
      private double price;
      // constructor, getters
  }
  interface PaymentStrategy {
      void pay(double amount);
  }
  class CreditCardPayment implements PaymentStrategy {
      public void pay(double amount) { /* 信用卡支付逻辑 */ }
  }
  class Order {
      private List<MenuItem> items = new ArrayList<>();
      public void addItem(MenuItem item) { items.add(item); }
      public double getTotal() {
          return items.stream().mapToDouble(MenuItem::getPrice).sum();
      }
      public void checkout(PaymentStrategy payment) {
          payment.pay(getTotal());
      }
  }
  // 使用示例
  Order order = new Order();
  order.addItem(new MenuItem("Burger", 8.99));
  order.addItem(new MenuItem("Fries", 3.49));
  order.checkout(new CreditCardPayment());

如何准备

• 掌握每个 OOP 原则的定义和示例；准备用类比解释。
• 在白板或代码编辑器上练习设计系统，关注类的职责和关系。
• 复习常见设计模式，并能在你的语言中从头实现它们。
• 理解权衡：继承与组合、紧耦合与松耦合，以及何时使用抽象类与接口。
• 为动手编码做好准备：编写小型 OOP 程序，并自如地解释你的设计选择。

常见问题