子类公共代码封装到父类是否违反SOLID原则（含里氏替换）？如何合规？

这种实现算不算违反SOLID原则？ #

首先明确：这种写法没有严重违反里氏替换原则（LSP），但确实违背了「接口继承优于实现继承」的设计思想，同时也和依赖倒置原则（DIP）的精神相悖。

具体说：

• 「接口继承优于实现继承」的核心是让子类依赖抽象的行为约定，而非父类的具体实现。现在父类Serializer包含了format的具体代码，子类必须继承这个实现才能复用逻辑，等于把子类和父类的实现细节硬绑定在一起。如果以后有个子类不需要这个format逻辑，或者需要不同的格式化方式，要么被迫继承无用方法，要么重写，非常别扭。
• 里氏替换原则要求子类可以替换父类且不破坏程序正确性。虽然这里子类替换父类不会直接导致错误，但如果父类的format方法后续被修改（比如改成输出新的内容），所有子类的serialize行为都会跟着变，子类完全无法独立于父类变化，这其实间接违背了LSP“子类应独立于父类存在”的核心精神。

符合SOLID原则的改进方案 #

方案1：用组合代替继承（最推荐） #

把共用的格式化逻辑抽成独立的工具类/函数，让子类通过组合的方式使用，彻底解耦子类和父类的实现。

示例代码：

// 独立的格式化工具
const Formatter = {
  format: () => console.log("Formatting...")
};

// 纯抽象的序列化父类，只定义行为约定
class Serializer {
  serialize = () => { throw new Error("必须实现serialize方法"); };
}

class JSONSerializer extends Serializer {
  serialize = () => {
    Formatter.format();
    // JSON专属序列化逻辑
    console.log("序列化为JSON格式");
  };
}

class XMLSerializer extends Serializer {
  serialize = () => {
    Formatter.format();
    // XML专属序列化逻辑
    console.log("序列化为XML格式");
  };
}

这种方式完全符合依赖倒置原则——子类依赖的是独立的抽象工具，而非父类的具体实现；同时遵循「组合优于继承」的设计原则，子类可以自由选择是否使用Formatter，或者替换成其他格式化逻辑，灵活性拉满。

方案2：抽象父类+Mixin注入共用逻辑 #

如果想保留继承体系，可以把父类改成纯抽象接口，然后用Mixin的方式注入共用的格式化逻辑，避免父类包含具体实现。

示例代码：

// 纯抽象序列化父类，只定义必须实现的方法
class Serializer {
  serialize = () => { throw new Error("必须实现serialize方法"); };
}

// 格式化Mixin，封装共用逻辑
const FormatMixin = Base => class extends Base {
  format = () => console.log("Formatting...");
};

// 子类通过Mixin引入格式化能力
class JSONSerializer extends FormatMixin(Serializer) {
  serialize = () => {
    this.format();
    // JSON序列化逻辑
  };
}

class XMLSerializer extends FormatMixin(Serializer) {
  serialize = () => {
    this.format();
    // XML序列化逻辑
  };
}

这里父类只负责定义抽象行为，共用逻辑通过Mixin按需注入，子类可以灵活选择是否引入，完全符合「接口继承优先」的原则，也避免了实现继承带来的耦合。

方案3：策略模式彻底解耦 #

把格式化逻辑定义成可替换的策略，序列化器根据需要选择策略，进一步提升灵活性。

示例代码：

// 格式化策略：可以定义多种不同的格式化逻辑
const BasicFormatStrategy = {
  execute: () => console.log("Formatting...")
};

// 抽象序列化器，依赖格式化策略
class Serializer {
  constructor(formatStrategy) {
    this.formatStrategy = formatStrategy;
  }
  serialize = () => { throw new Error("必须实现serialize方法"); };
}

class JSONSerializer extends Serializer {
  constructor() {
    super(BasicFormatStrategy);
  }
  serialize = () => {
    this.formatStrategy.execute();
    // JSON序列化逻辑
    console.log("序列化为JSON格式");
  };
}

class XMLSerializer extends Serializer {
  constructor() {
    super(BasicFormatStrategy);
  }
  serialize = () => {
    this.formatStrategy.execute();
    // XML序列化逻辑
    console.log("序列化为XML格式");
  };
}

这种方式不仅复用了格式化逻辑，还允许动态替换策略——比如某个子类需要特殊格式化时，只需传入不同的策略对象即可，完全符合开闭原则（OCP），改动原有代码的成本极低。

内容的提问来源于stack exchange，提问作者Andrea Costanzo