実際の開発ではどのシナリオでファクトリ パターンの使用が必要ですか?

ファクトリ メソッド パターンを使用すると、システムはファクトリの役割を変更せずに新しい製品を導入できます。

1. ファクトリーモード

2. シンプルファクトリーモード

3. 抽象的な工場パターン

実際の開発ではどのような場面で使われているのでしょうか？現在の開発ではこれらのデザイン パターンをほとんど使用しないように感じるのはなぜですか? 。 。

返信内容:

ファクトリ メソッド パターンを使用すると、システムはファクトリの役割を変更せずに新しい製品を導入できます。

1. ファクトリーモード

2. シンプルファクトリーモード

3. 抽象的な工場パターン

実際の開発ではどのような場面で使われているのでしょうか？現在の開発ではこれらのデザイン パターンをほとんど使用しないように感じるのはなぜですか? 。 。

最初に、ファクトリー パターンの使用例について説明します。

一般的なMVCフレームワークには、基本的なDBデータベースの基本操作クラスがあります
私はそれをDBクラスと呼びます、dbクラスを継承するbaseModelクラスがあります
baseModelはすべてのフレームワークモデルの基本クラスであり、baseModelを継承する必要があります
baseModelはすでにhas db BaseModel は実際にはデータベース ファクトリであり、さまざまなデータ テーブルを操作するためのオブジェクト インスタンスを持ちます。ファクトリと同様に、異なるテーブル名を渡すと、異なるオブジェクトが返されます。
これは私の理解です。間違いがある場合は、ご容赦ください。

ファクトリパターンは、オブジェクトをインスタンス化するために使用されるパターンであり、新しい操作をファクトリメソッドに置き換える方法です。ファクトリ モードは Java プロジェクトのどこにでもあります。たとえば、私たちのシステムでは、ロガー インスタンスの作成時に実行される初期化作業が長いコードになる場合、ログを保持する必要があるからです。 , 初期化、代入、データクエリなどが必要になる場合があり、コードが肥大化して見苦しくなります。

リーリー

ファクトリ パターンを理解したい場合は、単純なファクトリ パターンを知る必要があります。

リーリー

いいえ、これは単純な工場モデルです。これは非常に一般的ですか? 単純な工場モデルには、単一責任の原則に従っていますが、もう 1 つの非常に重要な原則である オープンとクローズの原則 に違反しています。新しい事務員のポジションが追加された場合、対応するコードを変更してケースを追加する必要があります。これは、書かれたコードを再度変更すると、未知の影響を引き起こす可能性があるため、非常に恐ろしいです。

ファクトリ モードは、単純なファクトリへのアップグレードです。ここでは、外部呼び出しを行うときに必要なテーブル名を選択するだけで、実際のデータベース処理メソッドが返されます。望む結果。

ファクトリ パターンであっても、その他の作成パターンであっても、それらはすべてオブジェクトを初期化するという 1 つの目的を持っています。言い換えれば、データ構造モデル (クラスとオブジェクト自体がカスタム データ構造です) を構築するためです。

それで、問題は、なぜこの方法でオブジェクトを作成し、デザインパターンを使用できるのかということです。基本的に、その理由は、上位レベルのユーザーがオブジェクトを初期化するために new を直接使用したくないからです。 new

これには多くの理由がありますが、そのほとんどは、

オブジェクト作成プロセスが上位レベルのユーザーから分離されている、または オブジェクト作成プロセスが複雑でユーザーにとって習得が難しい、または オブジェクト作成が特定の条件を満たす必要があることです。条件 は、これらの条件がビジネス ニーズであれ、システムの制約であれ、上位レベルのユーザーがそれを習得して他のユーザーによる開発の難易度を高める必要はありません。

それで、ここまでで明確にしておく必要がありますが、それがファクトリーモードであれ、上記の同志が言及した開閉原理であれ、それはいくつかの複雑なプロセスを隔離して、これらの複雑なプロセスが外部に公開されないようにすることです。プロセスが公開され、ユーザーのトラブルが増加します。これはチームワークとも呼ばれます。

オブジェクト指向のカプセル化自体は、外部

を可能な限り単純にすることです。 API

例如，你定义了一个 Status字段，但这个字段因为某些业务原因，需要使用整数来表示状态。那么，如果数字少了还好办，如果数字多了，上层使用者就不一定能记清楚每个数字代表的状态（比如你要做语音通信系统，那么，语音设备是有很多状态数字的）。这时，如果使用 new来创建对象，然后再对 Status 进行赋值，不可避免的，可能要查阅开发文档，或者会不小心给出一个错误的值。这时，你就不妨使用工厂模式，或者其它合适的设计模式，来进行代码的建设。

比如，这样：

<code>public static class Factory
{
    public static Ixxxxxx CreateWithOpen()
    {
        var obj = new Obj();
        obj.Status = 1;
        return obj;
    }
    public static Ixxxxxx CreateWithClose()
    {
        var obj = new Obj();
        obj.Status = 2;
        return obj;
    }
}
</code>

当然，使用枚举也行，这个说白了，就是看设计者的意愿了。

所以，设计模式没有说必需在哪个场景中使用，更确切的说，应该是，当你使用了设计模式，能不能为你的团队成员带来方便，或者提升代码质量，避免一些错误。如果是，就用，如果仅仅带来了复杂，并没有益处，那还是算了。

一句话，没有该不该用，也没有哪些需要不需要用，用就要带来效益，无论是对团队还是产品质量或产品的可维护性。用不用，要以团队配合和产品为导向，这才是对一个软件设计师的基本要求。

工厂的职能就是你给它一个模型或者具体的样品需求，它给你一个成品。工厂模式也是这样的道理，比如，你入参是a，它就给你一个A对象，你入参b，它就给你生产一个B对象，这里a,b就是你让工厂生产的商品具体需求，如长宽高等。

工厂模式还是很常见的，你没用到可能是因为项目规模小，或者是类不够抽象。

工厂你可以理解为隐藏了内部细节，你调用工厂的生产API ，直接获得所描述的物体，具体怎么生产的，你不用去关注细节，因为有的东西简单，直接new出来就可以了，但有的很复杂，比如spring的注入链。要理解工厂模式，建议看看spring实现的factory。