こんにちは、Nosql データベースである DynamoDB を操作するために使用される、Amazon の PHP SDK の独自の高レベル API を作成しています。
エラー チェック、リクエストの作成、そしてもちろんコメントを含む、1 つの操作を実行する 1 つの関数に対して約 150 行のコードを書いていることに気付きました。このままだと、API クラスは簡単に 1000 行を超えてしまいます。
したがって、クラスをいくつかの小さなクラスに分割し、それぞれが一連の操作を処理することを考えています。テーブル操作、アイテム操作、バッチ操作などです。しかし、私はソフトウェア設計パターンの専門家ではないので、これは本当にモジュール化の良い方法でしょうか? または、準拠してコードを保守しやすくする必要がある設計パターンはありますか?
実際に達成しようとしていることを確認できるようにコードを提供していないため、質問は少し主観的です。
しかし、はい、クラスをより小さなコンポーネントに分割する必要があり、それぞれが独自の責任を負います。それを行う方法を正確に示す単一のパターンはありませんが、単一責任の原則は手始めとしては適切です。関心の分離についてです。
あなたが言った：
[...] エラーチェック、リクエスト構築を含む [...]
これで、エラー チェックをリクエスト構築から分離し、さらに小さなコンポーネントに分離して、それぞれが 1 つの責任しか持たなくなりました。各コンポーネントを変更する理由は 1 つだけにする必要があります。これらのドメイン オブジェクトごとに専用のサービスを使用して、明確なドメイン モデルを定義する必要があります。
たとえば、@teresko の回答は次のとおりです。
そのため、アプリケーションをレイヤーに分割する必要があることに注意してください。リクエストはプレゼンテーション層の一部です。最新のMVC に似たアプリケーションでは、特定の要求に対するプレゼンテーションを準備するために、モデル レイヤーと対話するコントローラー レイヤーとビュー レイヤーによって構成されます。
私はあなたと同じ船に乗っていると思います。目的が多すぎるクラスを維持する必要があります。http://www.dofactory.com/Patterns/Patterns.aspxという Web ページを参考にしてください。また、Google: SOLID (http://en.wikipedia.org/wiki/SOLID_%28object-directional_design%29)。これらは .NET およびオブジェクト指向プログラミングを対象としていますが、PHP にはクラスとオブジェクトがあることは知っています。