簡単なコーディング例で SOLID 設計原則を理解する

この記事では、SOLID 設計原則の明確かつ簡潔な概要を提供し、各概念を簡単に理解するのに役立つ簡単なコード例を示します。

SOLID は、ソフトウェア設計をより理解しやすく、柔軟に、保守しやすくすることを目的とした 5 つの設計原則のセットです。

目次

• S — 単一責任原則 (SRP)
• O — オープンクローズド原則 (OCP)
• L — リスコフ置換原理 (LSP)
• I — インターフェース分離原則 (ISP)
• D — 依存性反転原則 (DIP)

---

この原則はオブジェクト指向設計で特に役立ち、フロントエンドとバックエンドの開発に一般的に適用されます。 TypeScript のコード例を使用して、各 SOLID 原則の概要を次に示します。

S — 単一責任原則 (SRP)

クラスには変更する理由が 1 つだけある必要があります。つまり、クラスの仕事や責任は 1 つだけである必要があります。

この原則は、UI の一側面に対する変更や更新が無関係な部分に誤って影響を与えないように、集中的なアプローチを奨励します。

// UserProfile.tsx
import React from 'react';

interface UserProfileProps {
  username: string;
  email: string;
}

const UserProfile: React.FC<UserProfileProps> = ({ username, email }) => {
  return (
    <div>
      <h2>{username}</h2>
      <p>{email}</p>
    </div>
  );
};

export default UserProfile;

ここで、UserProfile はユーザー情報の表示のみを担当します。

---

O — オープンクローズド原則 (OCP)

ソフトウェア エンティティは拡張に対してオープンである必要がありますが、変更に対してはクローズされている必要があります。

このアプローチにより、コアコンポーネントが安定して変更されないことが保証され、新しい機能を追加する際の意図しない副作用のリスクが軽減されます。

// Alert.tsx
import React from 'react';

interface AlertProps {
  message: string;
}

const Alert: React.FC<AlertProps> = ({ message }) => {
  return <div className="alert">{message}</div>;
};

export default Alert;

// SuccessAlert.tsx
import React from 'react';
import Alert from './Alert';

const SuccessAlert: React.FC<{ message: string }> = ({ message }) => {
  return <Alert message={`Success: ${message}`} />;
};

export default SuccessAlert;

元の Alert コンポーネントを変更せずに、SuccessAlert によってアラートを拡張できます。

---

L — リスコフ置換原理 (LSP)

スーパークラスのオブジェクトは、プログラムの正確さに影響を与えることなく、そのサブクラスのオブジェクトと置き換え可能である必要があります。

簡単に言えば、基本コンポーネントまたはモジュールがある場合、予期しない問題を引き起こすことなく、派生コンポーネントを基本コンポーネントの代わりに使用できる必要があります。

// BaseButton.tsx
import React from 'react';

interface BaseButtonProps {
  onClick: () => void;
  label: string;
}

const BaseButton: React.FC<BaseButtonProps> = ({ onClick, label }) => {
  return <button onClick={onClick}>{label}</button>;
};

export default BaseButton;

// IconButton.tsx
import React from 'react';
import BaseButton from './BaseButton';

interface IconButtonProps extends BaseButtonProps {
  icon: string;
}

const IconButton: React.FC<IconButtonProps> = ({ onClick, label, icon }) => {
  return (
    <BaseButton onClick={onClick} label={<span><i className={icon}></i> {label}</span>} />
  );
};

export default IconButton;

IconButton は、アプリケーションの正確さに影響を与えることなく、BaseButton のどこでも使用できます。

---

I — インターフェース分離原則 (ISP)

クライアントは、使用しないメソッドに依存することを強制されるべきではありません。これは、特定のニーズに合わせて特定のインターフェイスを作成することを意味します。

言い換えれば、単一の大きなインターフェイスを作成するのではなく、個々のコンポーネントに合わせた、より小規模で焦点を絞ったインターフェイスに分割します。

// interfaces.ts
export interface Flyable {
  fly(): void;
}

export interface Swimmable {
  swim(): void;
}

// Bird.ts
import { Flyable } from './interfaces';

class Bird implements Flyable {
  fly() {
    console.log('Bird is flying');
  }
}

// Fish.ts
import { Swimmable } from './interfaces';

class Fish implements Swimmable {
  swim() {
    console.log('Fish is swimming');
  }
}

クラスが必要なものだけを実装することを保証するために、別個のインターフェイス Flyable と Swimmable が作成されます。

---

D — 依存性反転原則 (DIP)

高レベルのモジュールは、低レベルのモジュールではなく、抽象化に依存する必要があります。どちらも抽象化に依存する必要があります。

簡単に言うと、コンポーネントは互いに直接依存するのではなく、インターフェイスまたは抽象クラスに依存するため、コードが変更に適応しやすくなります。

// Logger.ts
export interface Logger {
  log(message: string): void;
}

export class ConsoleLogger implements Logger {
  log(message: string) {
    console.log(message);
  }
}

// UserService.ts
import { Logger } from './Logger';

class UserService {
  constructor(private logger: Logger) {}

  createUser(username: string) {
    this.logger.log(`User created: ${username}`);
  }
}

// App.ts
import { UserService } from './UserService';
import { ConsoleLogger } from './Logger';

const logger = new ConsoleLogger();
const userService = new UserService(logger);

userService.createUser('JohnDoe');

ここで、UserService は Logger 抽象化に依存しているため、UserService を変更せずにロギング メカニズムを柔軟に変更できます。

---

これらの SOLID 原則は、保守、拡張、リファクタリングが簡単なソフトウェアの作成に役立ちます。これは、堅牢なフロントエンドおよびバックエンド アプリケーションの開発に不可欠です。

以上が簡単なコーディング例で SOLID 設計原則を理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。