ハードウェア デバイスを通過する一種のデータは特別な形式を使用します。最初の段落が ID で、後の段落がデータです。
前の段落は、A、B、C などのデータのタイプを表しています。
前のタイプに従って、次の数字の一部を取得します。たとえば、タイプ A の場合はデータの 1 ～ 3 桁が必要で、タイプ B の場合は 20 桁目と 22 桁目が必要です。
今設計するときはカテゴリaとbだけを受け付ければよいのですが、将来的にはカテゴリc、カテゴリdなども受け入れたいとデータに対する操作も異なります。カテゴリ a は 1 ～ 3 桁を受け入れる必要があります。すべてが 2 倍され、タイプ b の 20 桁目に 1 が追加され、22 桁目は変更されません z
問題は、将来の拡張を容易にするためにどのように設計すべきかということです。たとえば、コードを書き直さずにクラス d をサポートしたい....
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
複雑でない場合は、戦略パターンを使用します。複雑でない場合は、直接 OO 継承を使用します。異なる種類のメッセージは異なるサブクラスで処理されます。
データ プロトコルの形式は明確に定義する必要があります。たとえば、上位 3 桁はタイプを表し、中央の 2 桁はプロトコルのバージョンを表し、最後の桁はデータを表します。
プロトコルを規定した後、テンプレートメソッドで処理し、具体的な解析をサブクラスに、一般的な解析を親クラスに配置します。
このように、拡張するときに元のコードを変更する必要はなく、新しい実装を記述するだけで済みます。
デザインパターンを使用する必要はまったくなく、従来の継承で十分であり、各サブクラスは異なるフィールドを取ることができます。
デザインパターンを使用する必要がある場合は、戦略パターン
を検討できます後続のユーザーも判断する必要があります。実際、重要なのは 6 つの原則に従う必要はありません。ニーズに応じてコードは徐々に進化し、最終的には自然に特定のパターンに従うことも、複数のパターンの組み合わせになることもあります。