別の一般的な言語は、Java / Java EEと同様の複雑さを管理しながら、ファクトリパターンを使用する必要をどのように回避しますか？

ファクトリー・パターン（または少なくともの使用FactoryFactory..）は、次のような多くのジョークのお尻です。

RequestProcessorFactoryFactory.RequestProcessorFactoryのような詳細で「創造的な」名前の他に、Java / C ++でプログラミングする必要があり、Abstract_factory_patternのユースケースがある場合、ファクトリパターンに根本的な問題はありますか？

他の一般的な言語（RubyやScalaなど）を使用して、同様の複雑さを管理する必要はありませんか？

私が尋ねる理由は、Java / Java EEエコシステムのコンテキストで言及されている工場の批判がほとんど見られますが、他の言語/フレームワークがそれらをどのように解決するかについては説明しません。

あなたの質問には「Java」というタグが付けられています。Factoryパターンがwhy笑されている理由を尋ねているのは驚くことではありません。

たとえば、ファイルからXMLドキュメントを読み込んで、それに対してXPathクエリを実行してみてください。ファクトリーとビルダーをセットアップするには、10行のコードのようなものが必要です。

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder(); 

Document xmlDocument = builder.parse(new FileInputStream("c:\\employees.xml"));
XPath xPath =  XPathFactory.newInstance().newXPath();

xPath.compile(expression).evaluate(xmlDocument);

このAPIを設計している人たちが開発者として働いたことがあるのか​​、それとも本を読んで物を投げただけなのか、疑問に思います。パーサーを自分で書きたくなくて、タスクを他の人に任せただけだと理解していますが、それでもい実装になります。

ここでは、C＃でXMLファイルをロードする代替手段を尋ねているため、

XDocument xml = XDocument.Load("c:\\employees.xml");
var nodes = xml.XPathSelectElements(expression);

新しくhatch化したJava開発者はFactoryの狂気を見て、それをしても大丈夫だと思います-Javaを自分で構築した天才がそれをそれほど使用しているなら。

Factoryおよびその他のパタ​​ーンは、それぞれ特定のジョブに適したツールです。それらをジョブに適用すると、theyいコードに縛られてしまいます。

よくあることですが、人々は何が起こっているのかを誤解しています（そしてそれには多くの笑いが含まれます）。
多くの人（おそらくほとんどの人）が使用するのと同じくらい悪いのは、工場のパターンそのものではありません。

そして、それは間違いなくプログラミング（およびパターン）の教え方に由来します。学童（多くの場合、「学生」と呼ばれます）は「パターンYを使用してXを作成する」ように言われます。
それで、彼らは学校で好きな特定のパターンを、それが適切かどうかにかかわらず、あらゆるものに対して適用し始めます。

そして、悲しいことに、ソフトウェア設計に関する本を書く大学教授も含まれます。
これの最高潮は、私がそのような人によって作成されたものを維持しなければならないという明確な不満を持っていたシステムでした（彼は彼の名前にオブジェクト指向のデザインに関するいくつかの本を持っていて、主要な大学のCS部門での指導職）。
これは3層パターンに基づいており、各層自体が3層システムです（分離する必要があります...）。両側の各層セット間のインターフェースには、他の層にデータを転送するオブジェクトを生成するファクトリーと、受信したオブジェクトを受信層に属するオブジェクトに変換するオブジェクトを生成するファクトリーがありました。
各ファクトリーには抽象ファクトリーがありました（そのファクトリーを変更する必要があるかもしれないので、呼び出しコードを変更する必要はありません...）。
そして、その混乱全体はもちろん完全に文書化されていませんでした。

システムには、第5正規形に正規化されたデータベースがありました（私はあなたが子供ではない）。

着信ドキュメントと発信ドキュメントを記録および追跡するために使用できるアドレス帳に本質的に近いシステムで、C ++で100 MBのコードベースと50を超えるデータベーステーブルがありました。ソフトウェアを実行しているコンピューターに直接接続されたプリンターを使用して、500の定型書簡を印刷するには72時間もかかります。

それが人々がパターンをpatterns笑する理由であり、特に人々は単一の特定のパターンにひたむきに焦点を合わせています。

工場には、状況によってはエレガントなアプリケーション設計を可能にする多くの利点があります。1つは、後で作成するオブジェクトのプロパティを、ファクトリを作成して1か所で設定し、そのファクトリを渡すことができることです。しかし、多くの場合、実際にそれを行う必要はありません。その場合、Factoryを使用すると、実際に見返りを与えることなく、複雑さが追加されます。たとえば、このファクトリーを見てみましょう。

WidgetFactory redWidgetFactory = new ColoredWidgetFactory(COLOR_RED);
Widget widget = redWidgetFactory.create();

Factoryパターンに代わるものの1つは、非常によく似たBuilderパターンです。主な違いは、Factoryが初期化されると、Factoryによって作成されたオブジェクトのプロパティが設定され、Builderはデフォルト状態で初期化され、その後すべてのプロパティが設定されることです。

WidgetBuilder widgetBuilder = new WidgetBuilder();
widgetBuilder.setColor(COLOR_RED);
Widget widget = widgetBuilder.create();

しかし、オーバーエンジニアリングが問題である場合、FactoryをBuilderに置き換えても、それほど改善されない可能性があります。

いずれかのパターンの最も簡単な置換は、もちろん、new演算子を使用した単純なコンストラクターでオブジェクトインスタンスを作成することです。

Widget widget = new ColoredWidget(COLOR_RED);

ただし、コンストラクターには、ほとんどのオブジェクト指向言語で重大な欠点があります。つまり、コンストラクターはその正確なクラスのオブジェクトを返す必要があり、サブタイプを返すことはできません。

実行時にサブタイプを選択する必要があるが、そのためにまったく新しいBuilderクラスまたはFactoryクラスを作成したくない場合は、代わりにfactory-methodを使用できます。これは、そのクラスまたはそのサブクラスの1つの新しいインスタンスを返すクラスの静的メソッドです。内部状態を保持しないファクトリは、多くの場合、次のようなファクトリメソッドに置き換えることができます。

 Widget widget = Widget.createColoredWidget(COLOR_RED); // returns an object of class RedColoredWidget

Java 8の新機能は、ステートレスファクトリで行うのと同じように、メソッドを渡すことができるメソッド参照です。便利なことに、メソッド参照を受け入れるものはすべて、同じ機能的なインターフェースを実装するオブジェクトも受け入れます。これは、内部状態を備えた本格的なファクトリーでもあります。

ある種の工場は、適切な状況下ではほとんどすべてのオブジェクト指向言語に見られます。文字列などの単純なパラメータに基づいて、作成するオブジェクトの種類を選択する方法が必要な場合があります。

一部の人々はそれを取りすぎて、ファクトリー内を除いてコンストラクターを呼び出す必要がないようにコードを設計しようとします。工場を持っていると物事はばかげているようになります。

Scalaを学び、Rubyを知らないが、同じように信じているのは、言語が十分に表現力があり、プログラマが常に「配管」作業を外部構成ファイルにプッシュしようとしないことです。 。Scalaでは、異なるファクトリーファクトリーを作成してクラスをさまざまな構成に結び付けるのではなく、特性が混在したオブジェクトを使用します。また、Javaで頻繁に過剰に設計されるタスク用の言語で簡単なDSLを作成することも比較的簡単です。

また、他のコメントと回答が指摘しているように、クロージャーとファーストクラス関数は多くのパターンの必要性を取り除きます。そのため、C ++ 11とJava 8が広く採用されるにつれて、アンチパターンの多くが消え始めると思います。

一般的に、Javaプログラムはひどく過剰に設計されているという傾向があります[要出典]。多くの工場を持つことは、オーバーエンジニアリングの最も一般的な症状の1つです。それが人々がそれらをからかう理由です。

特に、Javaの工場での問題は、Javaではa）コンストラクターが関数ではなく、b）関数がファーストクラスの市民ではないということです。

このようなものを書くことができると想像してください（JREのFunctionよく知られたインターフェースになりましょう）

// Framework code
public Node buildTree(Function<BranchNode, Node, Node> branchNodeFactory) {
    Node current = nextNode();
    while (hasNextNode()) {
        current = branchNodeFactory.call(current, nextNode());
    }
    return current
}

// MyDataNode.java
public class MyBranchNode implements BranchNode {

    public MyBranchNode(Node left, Node right) { ... }
}

// Client code
Node root = buildTree(MyBranchNode::new);

ファクトリインターフェースまたはクラスはありません。多くの動的言語には、一流の機能があります。残念ながら、これはJava 7以前では不可能です（同じことを工場で実装することは、読者への課題として残されています）。

そのため、代替案はそれほど「異なるパターンを使用する」のではなく、「より優れたオブジェクトモデルで言語を使用する」または「単純な問題を過度に設計しないでください」です。