React の SOLID 原則: 保守可能なコンポーネントを作成するための鍵

React アプリケーションが成長すると、コンポーネントが肥大化したり、コードの保守が困難になったり、予期せぬバグが発生したりして、状況が急速に混乱する可能性があります。ここで SOLID 原則が役に立ちます。もともとオブジェクト指向プログラミングのために開発されたこれらの原則は、クリーンで柔軟、スケーラブルなコードを作成するのに役立ちます。この記事では、SOLID の各原則を詳しく説明し、React でそれらの原則を使用してコンポーネントを整理し、コードの保守を容易にし、アプリを拡張できる状態に保つ方法を示します。

SOLID は、クリーンで保守可能、スケーラブルなコードを書くことを目的とした 5 つの設計原則を表す頭字語で、本来はオブジェクト指向プログラミング用ですが、React にも適用できます。

S: 単一責任の原則: コンポーネントは1つの仕事または責任を持つ必要があります。

O: オープン/クローズ原則: コンポーネントは 拡張機能 ** (簡単に強化またはカスタマイズできる) に対してオープンである必要がありますが、 ** 変更に対してクローズされている必要があります (コア コードは必要ありません)変更)。

L: リスコフ置換原則: コンポーネントは、アプリの動作を損なうことなく子コンポーネントで置き換え可能である必要があります。

I: インターフェース分離の原則: コンポーネントは、未使用の機能に強制的に依存すべきではありません。

D: 依存関係逆転の原則: コンポーネントは、具体的な実装ではなく、抽象化に依存する必要があります。

単一責任原則 (SRP)

次のように考えてください。歩くなど、1 つの仕事しかできないおもちゃのロボットがあると想像してください。歩くことに集中するはずなので、会話などの 2 番目のことを要求すると、混乱してしまいます。別の仕事が必要な場合は、2 台目のロボットを購入してください。

React では、コンポーネントは 1 つのことだけを行う必要があります。データの取得、フォーム入力の処理、UI の表示などを一度に実行しすぎると、煩雑になり管理が困難になります。

const UserCard = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then(response => response.json())
      .then(data => setUser(data));
  }, []);

  return user ? ( <div>
      <h2 id="user-name">{user.name}</h2>
      <p>{user.email}</p>
    </div> ) : <p>Loading...</p>;
};

ここでは、UserCard がデータの取得と UI のレンダリングの両方を担当しており、単一責任の原則を破っています。

const useFetchUser = (fetchUser) => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, [fetchUser]);

  return user;
};

const UserCard = ({ fetchUser }) => {
  const user = useFetchUser(fetchUser);

  return user ? (
    <div>
      <h2 id="user-name">{user.name}</h2>
      <p>{user.email}</p>
    </div>
  ) : (
    <p>Loading...</p>
  );
};

ここでは、データ取得ロジックがカスタム フック (useFetchUser) に移動されていますが、UserCard は UI のレンダリングと SRP の維持 のみに焦点を当てています。

オープン/クローズ原則 (OCP)

ビデオゲームのキャラクターを思い浮かべてください。コア能力 (修正) を変更せずに、キャラクターに新しいスキル (拡張機能) を追加できます。それが OCP の目的であり、既存のものを変更することなくコードを成長させ、適応させることができます。

const Alert = ({ type, message }) => {
  if (type === 'success') {
    return <div classname="alert-success">{message}</div>;
  }
  if (type === 'error') {
    return <div classname="alert-error">{message}</div>;
  }
  return <div>{message}</div>;
};

ここでは、新しいアラート タイプが必要になるたびに、アラート コンポーネントを変更する必要があるため、OCP が壊れます。コンポーネントに条件付きレンダリングを追加したり、ケース レンダリングを切り替えたりすると、そのコンポーネントの保守性が低下することになります。そのため、機能にさらに条件を追加し、OCP を破壊するコンポーネントのコア コードを変更する必要があるためです。

const Alert = ({ className, message }) => (
  <div classname="{className}">{message}</div>
);

const SuccessAlert = ({ message }) => (
  <alert classname="alert-success" message="{message}"></alert>
);

const ErrorAlert = ({ message }) => (
  <alert classname="alert-error" message="{message}"></alert>
);

現在、Alert コンポーネントは (SuccessAlert、ErrorAlert などの追加による) 拡張のためにオープンですが、コアの Alert コンポーネントに触れる必要がないため、変更のためにクローズされています新しいアラート タイプを追加します。

OCP が必要ですか?継承より合成を優先

リスコフ置換原理 (LSP)

あなたは電話を持っていて、その後新しいスマートフォンを手に入れたと想像してください。通常の電話と同じように、スマートフォンでも電話をかけることが期待されます。スマートフォンが通話できなくなったら、それは悪い代替品になりますよね？それが LSP の目的です。新しいコンポーネントや子コンポーネントは、機能を壊すことなく、元のコンポーネントと同じように動作する必要があります。

const Button = ({ onClick, children }) => (
  <button onclick="{onClick}">{children}</button>
);

const IconButton = ({ onClick, icon }) => (
  <button onclick="{onClick}">
    <i classname="{icon}"></i>
  </button>
);

ここで、Button を IconButton と交換すると、ラベルが失われ、動作と期待が損なわれます。

const Button = ({ onClick, children }) => (
  <button onclick="{onClick}">{children}</button>
);

const IconButton = ({ onClick, icon, label }) => (
  <button onclick="{onClick}">
    <i classname="{icon}"></i> {label}
  </button>
);

// IconButton now behaves like Button, supporting both icon and label

IconButton は Button の動作を適切に拡張し、アイコンとラベルの両方をサポートするため、機能を損なうことなくアイコンとラベルを交換できます。これは、子 (IconButton) が親 (Button) を何の驚きもなく置き換えることができるため、リスコフ置換原則に従います。

B コンポーネントが A コンポーネントを拡張する場合、A コンポーネントを使用する場所であればどこでも、B コンポーネントを使用できるはずです。

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

リモコンを使用してテレビを見ていると想像してください。必要なのは電源、音量、チャンネルなどのいくつかのボタンだけです。リモコンに DVD プレーヤー、ラジオ、照明などの不要なボタンがたくさん付いていたら、使うのが面倒になるでしょう。

それを使用するコンポーネントがすべての props を必要としない場合でも、多くの props を受け取るデータ テーブル コンポーネントがあるとします。

const DataTable = ({ data, sortable, filterable, exportable }) => (
  <div>
    {/* Table rendering */}
    {sortable && <button>Sort</button>}
    {filterable && <input placeholder="Filter">}
    {exportable && <button>Export</button>}
  </div>
);

This component forces all consumers to think about sorting, filtering, and exporting—even if they only want a simple table.

You can split the functionality into smaller components based on what’s needed.

const DataTable = ({ data }) => (
  <div>
    {/* Table rendering */}
  </div>
);

const SortableTable = ({ data }) => (
  <div>
    <datatable data="{data}"></datatable>
    <button>Sort</button>
  </div>
);

const FilterableTable = ({ data }) => (
  <div>
    <datatable data="{data}"></datatable>
    <input placeholder="Filter">
  </div>
);

Now, each table only includes the functionality that’s needed, and you’re not forcing unnecessary props everywhere. This follows ISP, where components only depend on the parts they need.

Dependency Inversion Principle (DIP)

Imagine you're building with LEGO blocks. You have a robot built with specific pieces. But what if you want to swap out its arms or legs? You shouldn't have to rebuild the whole thing—just swap out the parts. The Dependency Inversion Principle (DIP) is like this: your robot (high-level) doesn't depend on specific parts (low-level); it depends on pieces that you can change easily.

const UserComponent = () => {
  useEffect(() => {
    fetch('/api/user').then(...);
  }, []);
  return <div>...</div>;
};

This directly depends on fetch—you can’t swap it easily.

const UserComponent = ({ fetchUser }) => {
  useEffect(() => {
    fetchUser().then(...);
  }, [fetchUser]);
  return <div>...</div>;
};

Now, the fetchUser function is passed in, and you can easily swap it with another implementation (e.g., mock API, or another data source), keeping everything flexible and testable.

Final Thoughts

Understanding and applying SOLID principles in React can drastically improve the quality of your code. These principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—help you write components that are more modular, flexible, and easier to maintain. By breaking down responsibilities, keeping code extensible, and making sure each part of your app interacts in predictable ways, you can create React applications that scale more easily and are simpler to debug. In short, SOLID principles lead to cleaner and more maintainable codebases.

以上がReact の SOLID 原則: 保守可能なコンポーネントを作成するための鍵の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。