SOLID 原则详解：SRP、OCP、LSP 等设计模式，提升代码可维护性与灵活性

solid-principles by thebushidocollective/han

167 周安装量

130 GitHub Stars

GitHub

安装命令

npx skills add https://github.com/thebushidocollective/han --skill solid-principles

方法论软件工程代码规范

🇨🇳中文介绍

SOLID 原则

应用 SOLID 设计原则，构建可维护、灵活的代码架构。

五项原则

1. 单一职责原则 (SRP)

一个模块应该仅有一个改变的理由

Elixir 模式

# 不好 - 多重职责
defmodule UserManager do
  def create_user(attrs) do
    # 创建用户
    # 发送欢迎邮件
    # 记录分析数据
    # 更新缓存
  end
end

# 好 - 单一职责
defmodule User do
  def create(attrs), do: Repo.insert(changeset(attrs))
end

defmodule UserNotifier do
  def send_welcome_email(user), do: # 邮件逻辑
end

defmodule UserAnalytics do
  def track_signup(user), do: # 分析逻辑
end

TypeScript 模式

// 不好 - 多重职责
class UserComponent {
  render() { /* UI */ }
  fetchData() { /* API */ }
  formatDate() { /* 格式化 */ }
  validateInput() { /* 验证 */ }
}

// 好 - 单一职责
function UserProfile({ user }: Props) {
  return <View>{/* 仅 UI */}</View>;
}

function useUserData(id: string) {
  // 仅数据获取
}

function formatUserDate(date: Date): string {
  // 仅格式化
}

自问： "这个模块做的唯一一件事是什么？"

2. 开闭原则 (OCP)

软件实体应对扩展开放，对修改关闭。

广告位招租

在这里展示您的产品或服务

触达数万 AI 开发者，精准高效

联系我们

Elixir 模式 (Behaviours)

# 定义接口
defmodule PaymentProvider do
  @callback process_payment(amount :: Money.t(), token :: String.t()) ::
    {:ok, transaction :: map()} | {:error, reason :: String.t()}
end

# 实现可以扩展而无需修改
defmodule StripeProvider do
  @behaviour PaymentProvider
  def process_payment(amount, token), do: # Stripe 逻辑
end

defmodule PayPalProvider do
  @behaviour PaymentProvider
  def process_payment(amount, token), do: # PayPal 逻辑
end

# 使用 - 添加新提供商无需更改此代码
def charge(provider_module, amount, token) do
  provider_module.process_payment(amount, token)
end

TypeScript 模式 (组合)

// 不好 - 添加新类型需要修改
function renderItem(item: Item) {
  if (item.type === 'gig') {
    return <TaskCard />;
  } else if (item.type === 'shift') {
    return <WorkPeriodCard />;
  }
  // 必须修改此函数以支持新类型
}

// 好 - 通过属性扩展
interface CardRenderer {
  (item: Item): ReactElement;
}

const renderers: Record<string, CardRenderer> = {
  gig: (item) => <TaskCard gig={item} />,
  shift: (item) => <WorkPeriodCard shift={item} />,
  // 在此添加新类型，无需修改 renderItem
};

function renderItem(item: Item) {
  const renderer = renderers[item.type];
  return renderer ? renderer(item) : <DefaultCard item={item} />;
}

自问： "我能否在不更改现有代码的情况下添加新功能？"

3. 里氏替换原则 (LSP)

子类型必须能够替换其基类型

# 不好 - 违反 LSP (基类型会返回时却引发异常)
defmodule PaymentCalculator do
  def calculate_total(items) when length(items) > 0 do
    Enum.sum(items)
  end
  # 缺少子句 - 空列表会引发异常
end

# 好 - 遵守契约
defmodule PaymentCalculator do
  def calculate_total(items) when is_list(items) do
    Enum.sum(items)  # 空列表返回 0
  end
end

TypeScript 模式 (LSP)

// 不好 - 违反 LSP
class Bird {
  fly(): void { /* 飞翔 */ }
}

class Penguin extends Bird {
  fly(): void {
    throw new Error('Penguins cannot fly');  // 破坏契约
  }
}

// 好 - 正确的抽象
interface Bird {
  move(): void;
}

class FlyingBird implements Bird {
  move(): void { this.fly(); }
  private fly(): void { /* 飞翔 */ }
}

class SwimmingBird implements Bird {
  move(): void { this.swim(); }
  private swim(): void { /* 游泳 */ }
}

自问： "我能否用其父类/接口替换此对象而不破坏行为？"

4. 接口隔离原则 (ISP)

客户端不应被迫依赖其不使用的接口。

# 不好 - 臃肿的接口
defmodule User do
  @callback work() :: :ok
  @callback take_break() :: :ok
  @callback eat_lunch() :: :ok
  @callback clock_in() :: :ok
  @callback clock_out() :: :ok
  # 并非所有用户都需要所有这些
end

# 好 - 隔离的接口
defmodule Workable do
  @callback work() :: :ok
end

defmodule Breakable do
  @callback take_break() :: :ok
end

defmodule TimeTrackable do
  @callback clock_in() :: :ok
  @callback clock_out() :: :ok
end

# 仅实现所需部分
defmodule ContractUser do
  @behaviour Workable
  def work(), do: :ok
  # 不需要时间追踪
end

TypeScript 模式 (ISP)

// 不好 - 臃肿的接口
interface User {
  work(): void;
  takeBreak(): void;
  clockIn(): void;
  clockOut(): void;
  receiveBenefits(): void;
  // 并非所有用户都需要所有方法
}

// 好 - 隔离的接口
interface Workable {
  work(): void;
}

interface TimeTrackable {
  clockIn(): void;
  clockOut(): void;
}

interface BenefitsEligible {
  receiveBenefits(): void;
}

// 仅组合所需部分
type FullTimeUser = Workable & TimeTrackable & BenefitsEligible;
type ContractUser = Workable & TimeTrackable;
type TaskUser = Workable;

自问： "这个接口是否强制实现类定义未使用的方法？"

5. 依赖倒置原则 (DIP)

依赖抽象，而非具体实现

# 不好 - 直接依赖具体实现
defmodule UserService do
  def create_user(attrs) do
    PostgresRepo.insert(attrs)  # 紧耦合
  end
end

# 好 - 依赖抽象
defmodule UserService do
  def create_user(attrs, repo \\ YourApp.Repo) do
    repo.insert(attrs)  # 可以注入任何 Repo 实现
  end
end

# 更好 - 使用 behaviour
defmodule UserService do
  @callback create_user(attrs :: map()) :: {:ok, User.t()} | {:error, term()}
end

defmodule PostgresUserService do
  @behaviour UserService
  def create_user(attrs), do: Repo.insert(User.changeset(attrs))
end

# 应用配置决定实现
config :yourapp, :user_service, PostgresUserService

TypeScript 模式 (DIP)

// 不好 - 直接依赖
class UserManager {
  private api = new StripeAPI();  // 紧耦合

  async processPayment(amount: number) {
    return this.api.charge(amount);
  }
}

// 好 - 依赖抽象
interface PaymentAPI {
  charge(amount: number): Promise<Transaction>;
}

class UserManager {
  constructor(private paymentAPI: PaymentAPI) {}  // 注入

  async processPayment(amount: number) {
    return this.paymentAPI.charge(amount);
  }
}

// 使用
const stripeAPI: PaymentAPI = new StripeAPI();
const manager = new UserManager(stripeAPI);

自问： "我能否在不更改依赖代码的情况下替换实现？"

识别单一职责
为扩展点设计（behaviours、接口）
先定义抽象，再实现
保持接口最小化和专注

每个模块仅有一个改变的理由 (SRP)
新功能扩展，而非修改 (OCP)
实现遵守契约 (LSP)
接口最小化 (ISP)
依赖可注入/可配置 (DIP)

职责是否清晰分离？
能否在不修改现有代码的情况下添加功能？
所有实现是否都履行了其契约？
接口是否专注且最小化？
依赖是否被抽象化？

代码库中的常见违规

包含业务逻辑的 GraphQL 解析器（应使用命令处理器）
既获取数据又渲染的组件（应使用钩子 + 展示组件）

针对类型的长 if/else 或 case 语句（应使用 behaviours/多态）
硬编码的提供商逻辑（应使用依赖注入）

在基类会返回 nil/错误元组时，实现中引发异常
不同实现间改变返回类型

要求所有字段的臃肿 GraphQL 类型（应使用片段）
庞大的组件属性（应拆分为专注的接口）

直接调用外部服务（应包装在 behaviours 中）
硬编码的 Repo 调用（应注入仓库）

与现有技能的集成

可与以下协同工作

boy-scout-rule: 改进代码时应用 SOLID
test-driven-development: 为每个职责编写测试
elixir-code-quality-enforcer: Credo 强制执行部分 SOLID 原则
typescript-code-quality-enforcer: TypeScript 接口支持 ISP/DIP

SOLID 是关于管理依赖和职责，而不是创建更多代码。

良好的设计源于务实而非教条地应用这些原则。

🇺🇸English

SOLID Principles

Apply SOLID design principles for maintainable, flexible code architecture.

The Five Principles

1. Single Responsibility Principle (SRP)

A module should have one, and only one, reason to change

Elixir Pattern

# BAD - Multiple responsibilities
defmodule UserManager do
  def create_user(attrs) do
    # Creates user
    # Sends welcome email
    # Logs to analytics
    # Updates cache
  end
end

# GOOD - Single responsibility
defmodule User do
  def create(attrs), do: Repo.insert(changeset(attrs))
end

defmodule UserNotifier do
  def send_welcome_email(user), do: # email logic
end

defmodule UserAnalytics do
  def track_signup(user), do: # analytics logic
end

TypeScript Pattern

// BAD - Multiple responsibilities
class UserComponent {
  render() { /* UI */ }
  fetchData() { /* API */ }
  formatDate() { /* Formatting */ }
  validateInput() { /* Validation */ }
}

// GOOD - Single responsibility
function UserProfile({ user }: Props) {
  return <View>{/* UI only */}</View>;
}

function useUserData(id: string) {
  // Data fetching only
}

function formatUserDate(date: Date): string {
  // Formatting only
}

Ask yourself: "What is the ONE thing this module does?"

2. Open/Closed Principle (OCP)

Software entities should be open for extension, closed for modification.

Elixir Pattern (Behaviours)

# Define interface
defmodule PaymentProvider do
  @callback process_payment(amount :: Money.t(), token :: String.t()) ::
    {:ok, transaction :: map()} | {:error, reason :: String.t()}
end

# Implementations extend without modifying
defmodule StripeProvider do
  @behaviour PaymentProvider
  def process_payment(amount, token), do: # Stripe logic
end

defmodule PayPalProvider do
  @behaviour PaymentProvider
  def process_payment(amount, token), do: # PayPal logic
end

# Usage - add new providers without changing this code
def charge(provider_module, amount, token) do
  provider_module.process_payment(amount, token)
end

TypeScript Pattern (Composition)

// BAD - Requires modification for new types
function renderItem(item: Item) {
  if (item.type === 'gig') {
    return <TaskCard />;
  } else if (item.type === 'shift') {
    return <WorkPeriodCard />;
  }
  // Have to modify this function for new types
}

// GOOD - Extension through props
interface CardRenderer {
  (item: Item): ReactElement;
}

const renderers: Record<string, CardRenderer> = {
  gig: (item) => <TaskCard gig={item} />,
  shift: (item) => <WorkPeriodCard shift={item} />,
  // Add new types here without modifying renderItem
};

function renderItem(item: Item) {
  const renderer = renderers[item.type];
  return renderer ? renderer(item) : <DefaultCard item={item} />;
}

Ask yourself: "Can I add new functionality without changing existing code?"

3. Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types

Elixir Pattern (LSP)

# BAD - Violates LSP (raises when base type would return)
defmodule PaymentCalculator do
  def calculate_total(items) when length(items) > 0 do
    Enum.sum(items)
  end
  # Missing clause - raises on empty list
end

# GOOD - Honors contract
defmodule PaymentCalculator do
  def calculate_total(items) when is_list(items) do
    Enum.sum(items)  # Returns 0 for empty list
  end
end

TypeScript Pattern (LSP)

// BAD - Violates LSP
class Bird {
  fly(): void { /* flies */ }
}

class Penguin extends Bird {
  fly(): void {
    throw new Error('Penguins cannot fly');  // Breaks contract
  }
}

// GOOD - Correct abstraction
interface Bird {
  move(): void;
}

class FlyingBird implements Bird {
  move(): void { this.fly(); }
  private fly(): void { /* flies */ }
}

class SwimmingBird implements Bird {
  move(): void { this.swim(); }
  private swim(): void { /* swims */ }
}

Ask yourself: "Can I replace this with its parent/interface without breaking behavior?"

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they don't use.

Elixir Pattern (ISP)

# BAD - Fat interface
defmodule User do
  @callback work() :: :ok
  @callback take_break() :: :ok
  @callback eat_lunch() :: :ok
  @callback clock_in() :: :ok
  @callback clock_out() :: :ok
  # Not all users need all these
end

# GOOD - Segregated interfaces
defmodule Workable do
  @callback work() :: :ok
end

defmodule Breakable do
  @callback take_break() :: :ok
end

defmodule TimeTrackable do
  @callback clock_in() :: :ok
  @callback clock_out() :: :ok
end

# Implement only what you need
defmodule ContractUser do
  @behaviour Workable
  def work(), do: :ok
  # No time tracking needed
end

TypeScript Pattern (ISP)

// BAD - Fat interface
interface User {
  work(): void;
  takeBreak(): void;
  clockIn(): void;
  clockOut(): void;
  receiveBenefits(): void;
  // Not all users need all methods
}

// GOOD - Segregated interfaces
interface Workable {
  work(): void;
}

interface TimeTrackable {
  clockIn(): void;
  clockOut(): void;
}

interface BenefitsEligible {
  receiveBenefits(): void;
}

// Compose only what you need
type FullTimeUser = Workable & TimeTrackable & BenefitsEligible;
type ContractUser = Workable & TimeTrackable;
type TaskUser = Workable;

Ask yourself: "Does this interface force implementations to define unused methods?"

5. Dependency Inversion Principle (DIP)

Depend on abstractions, not concretions

Elixir Pattern (DIP)

# BAD - Direct dependency on implementation
defmodule UserService do
  def create_user(attrs) do
    PostgresRepo.insert(attrs)  # Tightly coupled
  end
end

# GOOD - Depend on abstraction
defmodule UserService do
  def create_user(attrs, repo \\ YourApp.Repo) do
    repo.insert(attrs)  # Can inject any Repo implementation
  end
end

# Even better - use behaviour
defmodule UserService do
  @callback create_user(attrs :: map()) :: {:ok, User.t()} | {:error, term()}
end

defmodule PostgresUserService do
  @behaviour UserService
  def create_user(attrs), do: Repo.insert(User.changeset(attrs))
end

# Application config determines implementation
config :yourapp, :user_service, PostgresUserService

TypeScript Pattern (DIP)

// BAD - Direct dependency
class UserManager {
  private api = new StripeAPI();  // Tightly coupled

  async processPayment(amount: number) {
    return this.api.charge(amount);
  }
}

// GOOD - Depend on abstraction
interface PaymentAPI {
  charge(amount: number): Promise<Transaction>;
}

class UserManager {
  constructor(private paymentAPI: PaymentAPI) {}  // Injected

  async processPayment(amount: number) {
    return this.paymentAPI.charge(amount);
  }
}

// Usage
const stripeAPI: PaymentAPI = new StripeAPI();
const manager = new UserManager(stripeAPI);

Ask yourself: "Can I swap implementations without changing dependent code?"

Application Checklist

Before writing new code

Identify the single responsibility
Design for extension points (behaviours, interfaces)
Define abstractions before implementations
Keep interfaces minimal and focused

During implementation

Each module has ONE reason to change (SRP)
New features extend, don't modify (OCP)
Implementations honor contracts (LSP)
Interfaces are minimal (ISP)
Dependencies are injected/configurable (DIP)

During code review

Are responsibilities clearly separated?
Can we add features without modifying existing code?
Do all implementations fulfill their contracts?
Are interfaces focused and minimal?
Are dependencies abstracted?

Common Violations in Codebase

SRP Violation

GraphQL resolvers that also contain business logic (use command handlers)
Components that fetch data AND render (use hooks + presentation components)

OCP Violation

Long if/else or case statements for types (use behaviours/polymorphism)
Hardcoded provider logic (use dependency injection)

LSP Violation

Raising exceptions in implementations when base would return nil/error tuple
Changing return types between implementations

ISP Violation

Fat GraphQL types requiring all fields (use fragments)
Monolithic component props (split into focused interfaces)

DIP Violation

Direct calls to external services (wrap in behaviours)
Hardcoded Repo calls (inject repository)

Integration with Existing Skills

Works with

boy-scout-rule: Apply SOLID when improving code
test-driven-development: Write tests for each responsibility
elixir-code-quality-enforcer: Credo enforces some SOLID principles
typescript-code-quality-enforcer: TypeScript interfaces support ISP/DIP

Remember

SOLID is about managing dependencies and responsibilities, not about creating more code.

Good design emerges from applying these principles pragmatically, not dogmatically.

Weekly Installs

111

Repository

thebushidocollective/han

GitHub Stars

121

First Seen

Jan 22, 2026

Security Audits

Gen Agent Trust HubPass SocketPass SnykPass

Installed on

codex101

opencode101

gemini-cli100

github-copilot96

cursor91

amp85

冲刺回顾模板：敏捷团队回顾会议指南与模板（开始-停止-继续/愤怒-悲伤-高兴/4Ls）

10,400 周安装