設計パターンにこれほど多くのクラスが必要なのはなぜですか？

私はシニアのジュニア開発者であり、彼らの思考や推論を理解することに苦労しています。

私はドメイン駆動設計（DDD）を読んでいますが、なぜこれほど多くのクラスを作成する必要があるのか​​理解できません。ソフトウェアを設計するその方法に従えば、最大で2つのファイルと3〜4の関数で置き換えることができる20〜30のクラスになります。はい、これは面倒な場合がありますが、ずっと保守しやすく読みやすいです。

ある種のEntityTransformationServiceImpl機能を確認したいときはいつでも、多くのクラス、インターフェース、それらの関数呼び出し、コンストラクター、それらの作成などに従う必要があります。

簡単な数学：

• 60行のダミーコードと10クラスX 10（このようなロジックはまったく異なるとしましょう）= 600行の乱雑なコードと100クラス+ラップして管理するためのその他のコード。依存性注入を追加することを忘れないでください。
• 乱雑なコードの600行を読み取る= 1日
• 100クラス= 1週間

誰もが簡単にメンテナンスできると言っていますが、何のためですか？新しい機能を追加するたびに、ファクトリ、エンティティ、サービス、および値を持つ5つのクラスを追加します。この種のコードの移動は、乱雑なコードよりもずっと遅いように感じます。

たとえば、1か月で50KのLOC乱雑なコードを記述する場合、DDDには多くのレビューと変更が必要です（どちらの場合もテストは気にしません）。1つ追加するだけで1週間以上かかる場合があります。

1年で多くの乱雑なコードを作成し、何度も書き換えることもできますが、DDDスタイルでは、乱雑なコードと競合するための十分な機能がまだありません。

説明してください。このDDDスタイルと多くのパターンが必要なのはなぜですか？

UPD 1：たくさんの素晴らしい回答を受け取りました。どこかにコメントを追加したり、リストを読むためのリンクを使って回答を編集してください（DDD、デザインパターン、UML、コード完了、リファクタリング、実用的） ..非常に多くの優れた書籍）、もちろんシーケンスを使用して、理解を開始し、一部の皆さんと同じようにシニアになることもできます。

これは最適化の問題です

優れたエンジニアは、最適化の問題はターゲットがなければ意味がないことを理解しています。最適化するだけでなく、何かのために最適化する必要があります。たとえば、コンパイラオプションには、速度の最適化とコードサイズの最適化が含まれます。これらは時には反対の目標です。

私は自分の机が追加用に最適化されていることを妻に伝えたい。それは単なる山であり、ものを追加するのは非常に簡単です。妻が検索用に最適化した場合、つまり物を見つけることができるように私のものを少し整理した場合、妻はそれを好むでしょう。これにより、もちろん追加が難しくなります。

ソフトウェアも同じ方法です。確かに製品の作成を最適化できます。整理を心配することなく、可能な限り迅速に大量のモノリシックコードを生成できます。既にお気付きのように、これは非常に高速です。代替策は、メンテナンスのために最適化することです。作成をより難しくしますが、変更を簡単にするか、リスクを減らします。それが構造化コードの目的です。

成功するソフトウェア製品は一度だけ作成され、何度も何度も修正されることをお勧めします。経験豊富なエンジニアは、非構造化コードベースが独自のライフスタイルを引き継ぎ、大きなリスクを伴うことなく小さな変更を加えることさえ非常に困難になるまで、サイズと複雑さを増して製品になることを見てきました。コードが構造化されていれば、リスクを抑えることができます。それが、私たちがこのすべての問題に取り組む理由です。

複雑さは要素ではなく関係に由来する

分析では、コードの量、クラスの数などの量を調べていることに気付きます。これらは一種の興味深いものですが、実際の影響は要素間の関係から生じ、組み合わせで爆発します。たとえば、10個の関数があり、どれに依存するかわからない場合、90の可能な関係（依存関係）があり、心配する必要があります-10個の関数はそれぞれ、9個の他の関数のいずれかに依存し、9 x 10 =90。どの関数がどの変数またはデータの受け渡し方法を変更するのかわからない場合があるため、コーダーは特定の問題を解決する際に心配することがたくさんあります。対照的に、30のクラスがあり、それらが巧妙に配置されている場合、それらは29のリレーションを持つことができます。例えば、それらが階層化またはスタックに配置される場合です。

これはチームのスループットにどのように影響しますか？さて、依存関係は少なく、問題ははるかに扱いやすいです。コーダーは、変更を加えるたびに頭の中で無数のことをやり直す必要はありません。そのため、依存関係を最小限に抑えることで、問題を適切に判断する能力が大幅に向上します。これが、物事をクラスまたはモジュールに分割し、変数をできるだけ厳密にスコープし、SOLID原則を使用する理由です。

まあ、まず第一に、読みやすさと保守性は多くの場合、見る人の目にあります。

あなたが読むことができるのはあなたの隣人ではないかもしれません。

保守性は、発見可能性（コードベースで発見された動作や概念がどれほど簡単か）に要約されることが多く、発見可能性は別の主観的なものです。

DDD

DDDが開発者のチームを支援する方法の1つは、コードの概念と動作を整理する特定の（まだ主観的な）方法を提案することです。この規則により、発見が容易になり、アプリケーションの保守が容易になります。

• ドメインの概念は、エンティティと集計としてエンコードされます
• ドメインの動作はエンティティまたはドメインサービスにあります
• 集約ルートにより一貫性が確保されます
• 永続性の懸念はリポジトリによって処理されます

この配置は、客観的に維持するのが簡単ではありません。ただし、DDDコンテキストで動作していることを全員が理解している場合は、保守がかなり容易になります。

クラス

クラスはよく知られた慣習であるため、保守性、可読性、発見可能性などに役立ちます。

オブジェクト指向設定では、通常、クラスは密接に関連する動作をグループ化し、慎重に制御する必要がある状態をカプセル化するために使用されます。

それは非常に抽象的に聞こえますが、次のように考えることができます。

クラスを使用すると、必ずしもクラス内のコードがどのように機能するかを知る必要はありません。クラスが何を担当しているのかを知る必要があります。

クラスを使用すると、明確に定義されたコンポーネント間の相互作用の観点からアプリケーションについて推論できます。

これにより、アプリケーションの動作を推論する際の認知的負担が軽減されます。600行のコードが達成することを覚えておく代わりに、30個のコンポーネントがどのように相互作用するかを考えることができます。

そして、これらの30個のコンポーネントはおそらくアプリケーションの3つの層にまたがることを考慮すると、一度に約10個のコンポーネントについて推論する必要があるのはおそらくすべてです。

それはかなり管理しやすいようです。

概要

基本的に、上級開発者が行うことは次のとおりです。

彼らは、アプリケーションをクラスについて推論しやすいものに分解しています。

次に、これらをレイヤーについて簡単に推論できるように整理しています。

彼らがこれを行っているのは、アプリケーションが成長するにつれて、全体としてそれについて推論することがますます難しくなることを知っているからです。それをレイヤーとクラスに分解すると、アプリケーション全体について推論する必要がなくなります。彼らはその小さなサブセットについて推論する必要があるだけです。

なぜこのDDDスタイル、たくさんのパターンが必要なのか教えてください。

まず、注意：DDDの重要な部分はパターンではなく、開発努力とビジネスの調整です。グレッグヤングはブルーブックの章の順番が間違っていると言った。

ただし、特定の質問：（a）ドメインの動作と配管を区別するための努力が行われているため、および（b）概念を確保するために余分な努力が行われているため、予想よりも多くのクラスが存在する傾向がありますドメインモデルでは、明示的に表現されます。

率直に言って、ドメイン内に2つの異なる概念がある場合、それらがメモリ表現で同じものを共有している場合でも、モデル内で区別する必要があります。

実際には、ビジネスの言語でモデルを記述するドメイン固有の言語を構築しているので、ドメインの専門家はモデルを見てエラーを見つけることができます。

さらに、関心の分離にもう少し注意を払っています。実装の詳細から一部の機能のコンシューマーを隔離するという概念。DL Parnasを参照してください。明確な境界線により、ソリューション全体に影響を与えることなく、実装を変更または拡張できます。

ここでの動機：ビジネスのコアコンピテンシーの一部であるアプリケーション（競争上の優位性を引き出す場所を意味する）の場合、ドメインの動作をより良いバリエーションで簡単かつ安価に置き換えることができます。実際には、急速に進化したい部分（時間の経過とともに状態がどのように進化するか）と、ゆっくりと変化させたい他の部分（状態を保存する方法）があります。抽象化の余分な層は、一方が他方に不注意に結合するのを防ぎます。

公平に：その一部はオブジェクト指向脳損傷でもあります。Evansが最初に説明したパターンは、彼が15年以上前に参加したJavaプロジェクトに基づいています。状態と動作はそのスタイルで緊密に結合されており、これは回避したい合併症につながります。Stuart HallowayによるPerception and Action、またはJohn CarmackによるInlining Codeを参照してください。

使用する言語に関係なく、機能的なスタイルのプログラミングには利点があります。都合が良いときはいつでもそれをすべきであり、都合が悪いときは決断について一生懸命に考えるべきです。 カーマック、2012

他の回答には多くの良い点がありますが、あなたが犯す重要な概念上の間違いを見逃したり、強調したりしないと思います。

完全なプログラムを理解する努力を比較しています。

これは、ほとんどのプログラムで現実的なタスクではありません。単純なプログラムでさえ、非常に多くのコードで構成されているため、いつでもすべてを管理することは不可能です。あなたの唯一のチャンスは、目前のタスクに関連するプログラムの部分を見つけて（バグの修正、新機能の実装）、それで作業することです。

プログラムが巨大な関数/メソッド/クラスで構成されている場合、これはほとんど不可能です。このコードチャンクが問題に関連しているかどうかを判断するために、数百行のコードを理解する必要があります。あなたが与えた見積もりにより、作業に必要なコードを見つけるためだけに1週間を費やすことが容易になります。

それを、パッケージ/名前空間に名前を付けて整理した小さな関数/メソッド/クラスを含むコードベースと比較して、特定のロジックをどこで見つけ/置くかを明確にします。多くの場合、正しく実行すると、問題を解決するための正しい場所にジャンプするか、少なくともデバッガーを起動して数ホップで正しい場所に移動できる場所にジャンプできます。

私は両方の種類のシステムで働いてきました。違いは、匹敵するタスクと匹敵するシステムサイズのパフォーマンスの2桁の差です。

これが他のアクティビティに与える影響：

• テストは小さなユニットではるかに簡単になります
• 2人の開発者が同じコードで作業する機会が少ないため、マージの競合が少なくなります。
• ピースを再利用する（そして最初にピースを見つける）方が簡単だからです。

コードのテストはコードを書くよりも難しいため

開発者の観点からは、多くの回答が正当な理由を与えています-そもそもコードを書くのに手間がかかりますが、メンテナンスを減らすことができるということです。

ただし、考慮すべき別の側面があります。テストは、元のコードとしてのみきめ細かくすることができます。

すべてをモノリスで書く場合、書くことができる唯一の効果的なテストは「これらの入力が与えられた場合、出力は正しいですか？」です。これは、見つかったバグが「その巨大なコードの山のどこか」にスコープされていることを意味します。

もちろん、開発者にデバッガーを用意してもらい、問題が発生した場所を正確に見つけて修正に取り組むことができます。これには多くのリソースが必要であり、開発者の時間の悪用です。マイナーなバグがあるとしたら、開発者はプログラム全体を再度デバッグする必要があります。

解決策：特定の潜在的な障害をそれぞれ特定する多数の小規模なテスト。

これらの小さなテスト（ユニットテストなど）には、コードベースの特定の領域をチェックし、限られた範囲内でエラーを見つけるのに役立つという利点があります。これは、テストが失敗したときのデバッグを高速化するだけでなく、すべての小さなテストが失敗した場合に、より大きなテストでより簡単に失敗を見つけることができることを意味しますそれらの間の）。

明らかなように、より小さなテストを行うには、コードベースをより小さなテスト可能なチャンクに分割する必要があります。大規模な商用コードベースでそれを行う方法では、多くの場合、作業中のコードのように見えます。

補足として：これは、人々が物事を「あまりに」とらないと言うことではありません。しかし、コードベースをより小さく/接続されていない部分に分離する正当な理由があります-賢明に行われた場合。

なぜこのDDDスタイル、たくさんのパターンが必要なのか教えてください。

私たちの多く（ほとんど...）は本当にそれらを必要としません。理論家と非常に高度で経験豊富なプログラマーは、多くの研究とその深い経験の結果として、理論と方法論に関する本を書きます。

ジュニア開発者として、あなたの視点を広げ、特定の問題を認識させるためにあなたが言及したような本を読むことは良いことです。また、上級同僚がなじみのない用語を使用しているときに恥ずかしさや困惑を覚えることもありません。非常に難しいものを見つけて、意味をなさない、または役に立たないように思われる場合は、自分自身を殺さないでください。そのような概念またはアプローチがあることを頭に捨ててください。

日々の開発において、あなたがアカデミックでない限り、あなたの仕事は、実行可能で保守可能なソリューションを見つけることです。本で見つけたアイデアがあなたがその目標を達成するのに役立たない場合、あなたの仕事が満足であるとみなされる限り、今それについて心配しないでください。

読んだものの一部を使用できるが、最初はまったく「取得」しなかった、または使用しなかった可能性があることに気付くときが来るかもしれません。

あなたの質問は多くの前提で多くの分野をカバーしているので、私はあなたの質問の主題を選び出します：

設計パターンに非常に多くのクラスが必要な理由

私たちはしない。設計パターンには多くのクラスがなければならないと言う一般に受け入れられているルールはありません。

コードを配置する場所と、タスクを異なるコード単位に分割する方法を決定するための2つの重要なガイドがあります。

• 結束性：コードの任意のユニット（パッケージ、ファイル、クラス、またはメソッド）が属する必要があります。つまり、特定のメソッドには1つのタスクがあり、そのタスクを適切に実行する必要があります。どのクラスでも、1つの大きなトピック（それが何であれ）を担当する必要があります。高い凝集力が必要です。
• カップリング：コードの2つのユニットは、互いにできるだけ依存しないようにします-特に循環依存関係はありません。低結合が必要です。

なぜこれら2つが重要なのでしょうか？

• 結束性：多くのことを行う方法（たとえば、GUI、ロジック、DBアクセスなどを1つの長いコードですべて実行する昔ながらのCGIスクリプト）は扱いにくいものになります。この記事を書いている時点では、思考の列を長い方法にしたいだけです。これはうまく機能し、簡単にプレゼンテーションできますし、それで終わりです。後で問題が発生します。数か月後、自分がしたことを忘れることがあります。上部のコード行は、下部の行から数画面離れている場合があります。すべての詳細を忘れがちです。メソッド内の任意の場所での変更は、複雑な動作のあらゆる量を破壊する可能性があります。メソッドの一部をリファクタリングまたは再利用するのは非常に面倒です。等々。
• カップリング：コードのユニットを変更すると、それに依存する他のすべてのユニットが破損する可能性があります。Javaのような厳格な言語では、コンパイル時にヒント（つまり、パラメーター、宣言された例外など）が表示される場合があります。しかし、多くの変更はそのようなトリガー（行動の変更）ではなく、他のより動的な言語にはそのような可能性はありません。カップリングが高ければ高いほど、何かを変更するのが難しくなり、目標を達成するために完全な再書き込みが必要になる停止状態に陥る可能性があります。

これらの2つの側面は、プログラミング言語の「どこに何を置くか」、およびあらゆるパラダイム（OOだけでなく）を選択するための基本的な「ドライバー」です。誰もが明示的にそれらに気づいているわけではなく、これらがソフトウェアにどのように影響するかについて、本当に深く染み込んだ自動感覚を得るには、しばしば何年もかかります。

明らかに、これらの2つの概念は、実際に何をすべきかについて何も教えてくれません。一部の人々は多すぎる側に誤り、他の人々は少なすぎる側に誤りがあります。一部の言語（ここではJavaを参照）は、言語自体の非常に静的で退屈な性質のために、多くのクラスを支持する傾向があります（これは値のステートメントではありませんが、そのとおりです）。これは、Rubyなどの動的で表現力の高い言語と比較すると特に顕著になります。

もう1つの側面は、一部の人々は、現在必要なコードのみを記述するアジャイルアプローチにサブスクライブし、必要に応じて後で大幅にリファクタリングすることです。このスタイルの開発では、interface実装クラスが1つしかない場合は作成しません。具象クラスを実装するだけです。後で、2番目のクラスが必要な場合は、リファクタリングします。

一部の人々は単にそのように動作しません。これらは、より一般的に使用できるものすべてのインターフェース（より一般的には抽象基本クラス）を作成します。これにより、クラスが急速に爆発します。

繰り返しますが、賛否両論がありますが、どちらを好むかは関係ありません。あなたは、ソフトウェア開発者としての生活の中で、長いスパゲッティ手法から、賢明で十分に大きなクラス設計まで、非常に過剰に設計された非常に爆破されたクラススキームまで、すべての極端に遭遇します。経験を積むにつれて、「建築」の役割にさらに成長し、希望する方向でこれに影響を与え始めることができます。あなたは自分のための黄金の真ん中を見つけます、そしてあなたはまだあなたが何をするにしても、多くの人々があなたに反対することを見つけるでしょう。

したがって、ここではオープンマインドを維持することが最も重要なビットであり、それはあなたへの私の第一のアドバイスです。

経験豊富なコーダーが学んだこと：

• これらの小規模なプログラムとクラス、特に成功したプログラムが成長し始めるためです。単純なレベルで機能する単純なパターンは、スケールしません。
• なぜなら、追加/変更ごとにいくつかのアーティファクトを追加/変更しなければならないのは面倒に思えるかもしれませんが、何を追加するかは知っているので、それは簡単です。3分間のタイピングは3時間の巧妙なコーディングに勝ります。
• オーバーヘッドが実際に良いアイデアである理由を理解していないという理由だけで、多くの小さなクラスは「面倒」ではありません
• ドメインの知識が追加されていない場合、「私にとって明らかな」コードは、多くの場合、チームメイトにとって不思議なものです。
• 部族の知識があると、プロジェクトをチームメンバーに簡単に追加するのが非常に難しくなり、チームメンバーが迅速に生産性を上げることが難しくなります。
• ネーミングは、コンピューティングにおける2つの困難な問題の1つであり、多くのクラスとメソッドは多くの場合、多くの人にとって大きなメリットとなるネーミングの激しい練習です。

これまでの回答は、すべてが良いもので、アスカーには何かが欠けているという合理的な仮定から始まっていましたが、アスカーもそれを認めています。質問者が基本的に正しいことも考えられ、この状況がどのように発生するかを議論する価値があります。

経験と実践は強力であり、物事をコントロールし続ける唯一の方法がたくさんある場合、高齢者が大規模で複雑なプロジェクトで経験を積んだ場合、EntityTransformationServiceImpl彼らは設計パターンとDDDの緊密な順守で迅速かつ快適になります。小規模なプログラムであっても、軽量のアプローチを使用すると、効果ははるかに低くなります。奇妙なものとして、あなたは適応する必要があり、それは素晴らしい学習体験になります。

しかし、適応しながら、単一のアプローチを深く学ぶことと、どこでも機能させることができる点との間のバランスのレッスンとしてそれを理解する必要があります。両方に利点があり、世界で両方が必要です。

用途に応じてより多くのクラスと機能を作成することは、将来問題を解決するのに役立つ特定の方法で問題を解決するための優れたアプローチです。

複数のクラスは、基本的な作業として識別するのに役立ち、どのクラスもいつでも呼び出すことができます。

ただし、取得可能な名前から多くのクラスと関数を呼び出すと、呼び出しと管理が簡単になります。これはクリーンコードと呼ばれます。