最近から、私は前週に遭遇した問題や新しいアイデアを記録するために、毎週少なくとも 2 つのブログを更新するという目標を設定しました。 、一方では、長い時間が経ってもすべて忘れないように、私が習得した知識を記録します。第二に、私のブログ記事はあまり良くありませんが、少数の読者に一定の影響を与える可能性があります。時間が経てば経つほど、オリジナルのブログ記事が増えて、レベルは確実に高くなって、深みも増していくと思います（笑）有名ブロガーさんは、プロ意識が高いだけでなく、知識だけでなく、優れたライティングスキルも持っています）非常に）。週に 2 つの記事では、記録したいことすべてを記録することはできません。今週と同様に、ログ システム、バイナリ データ キャッシュ (実際には、下位データベースと呼ぶ方が適切です) もあります。 QQwry.dat データの解釈と zip 圧縮ファイルの追加については、今後ゆっくりとブログに更新していきます。 さて、今回は別のモデルを紹介します。
実はこのモードもよく使われているので最初に紹介すべきなのですが、もっと多くのシングルトンモードに触れてきたので、最初にシングルトンモードを紹介します。シンプル ファクトリ パターン、まずその定義を見てください。デザイン パターンの種類に関して言えば、シンプル ファクトリ パターンは静的ファクトリ メソッド パターンとも呼ばれる作成パターンですが、23 の GOF デザイン パターンの 1 つではありません。単純なファクトリ パターンでは、ファクトリ オブジェクトを使用して、どの製品クラス インスタンスを作成するかを決定します。シンプル ファクトリ パターンは、ファクトリ パターン ファミリの中で最も単純かつ最も実用的なパターンであり、さまざまなファクトリ パターンの特別な実装として理解できます。
プロジェクトにおけるシンプルなファクトリーパターンの利点は何ですか?彼には 2 つの利点があります:
1. 1 つ目は、新しいメソッドを使用してさまざまなクラスをインスタンス化するのではなく、単純なファクトリ パターンを使用してさまざまなパラメータに従ってさまざまなクラスをインスタンス化することで、ユーザーがより適切に管理できるようにします。
2. 次に、インスタンス化されるクラスが複数のファイルで使用されている場合、クラス名を変更するときに、クラスをインスタンス化するすべてのファイルを変更するのではなく、ファクトリ クラスのみを変更する必要があります (少し味気ない)。はまれです）。
最も古典的で最もよく理解されている単純な工場パターン、オペレーター操作の例を見てください:
単純なファクトリ パターンのファクトリ クラスは、通常、静的メソッドを使用して、異なるパラメータを受け入れることによって異なるオブジェクト インスタンスを返します。コードはハードコーディングされているため、コードを変更せずに拡張することはできず、OCP (拡張機能の開発、変更の場合) に違反します。 ）閉鎖原則）。
リーリーこれまでプロジェクトでシンプルなファクトリパターンしか触れたことがなかったのですが、この記事を書くために調べてみたところ、シンプルなファクトリパターン（静的ファクトリパターンとも呼ばれます）、ファクトリパターンの3つがあることがわかりました。 、そして抽象的なファクトリーパターンを読んだ後、それは単にOCPの原則に準拠しているだけであり、抽象的なプロダクトインターフェイスと抽象的なファクトリーインターフェイスに準拠する必要があるだけです。元のコードを変更せずに特定の製品とファクトリを拡張し、ファクトリ モードの長所と短所を要約します:
利点: まず、OCP 原則に準拠しており、スケーラビリティが向上します。次に、特定のファクトリ ロールを変更するときに、独自のファクトリ ロールを見つけるだけで済み、心配する必要がありません。他のファクトリーロールの実装への影響について。
欠点: コードが多すぎるため、各製品にはプロダクト クラスとファクトリー クラスが必要です。この欠点は、単純なファクトリ パターンとファクトリ パターンを組み合わせ、同様の製品クラスのファクトリ クラスを 1 つにマージすることで解決できます。
リーリーファクトリークラスは特定のプロジェクトで使用されたことがありません。それについて話すときはいつも少し奇妙に感じます。何か間違っている、または不適切な点がある場合は、専門家や先輩が指摘してくれることを願っています。
送ってください~
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
