私は機能に取り組んでおり、メソッドの長さについて混乱しています。特定のポイントが読み取られますが、何が最適か標準かはわかりません
他にもポイントがあります。静的ヘルパー メソッドがあり、その長さが増加しているため、より多くの静的ヘルパー メソッドを作成し、それらのメソッドにタスクを分散するオプションがありますが、不要な静的メソッドを作成しているように見えます。
他のアプローチは、別のヘルパー クラスを作成し、一部の作業をヘルパー クラスで定義されたメソッドに委任することです。
これを行うための最良の方法/標準的な方法が何であるかわかりません。
一般に、これらの点はどちらも考慮すべき点です。すでに述べた主な理由の 1 つ: コードが読みやすくなり、消化しやすくなります。
メソッドを分割してヘルパー メソッドを作成することによるもう 1 つの利点は、すぐには現れないことです。代わりに、ある日、顧客であるユーザーがいるシステムで作業し、管理者ユーザー、ベンダー、またはその他の抽象的なバージョンの人物を作成する必要がある機能を実装する必要があります。 .
ベンダーの注文、またはベンダーの注文をデータベースに保存する方法について考えていることに気付くでしょう。注文を識別するために使用される何らかの形式を生成する必要があります。顧客に対してこれと同じアクションを実行するために作成したコードは、Customer オブジェクトと同様に Vendor オブジェクトでも機能することがわかります。
ただし、Customers に関連するすべてを処理する同じメソッドでそのコードのすべてが一緒に強力である場合は、カット アンド ペーストの再利用性と呼ばれるものを使用することになります。これには、以前に作成したコードを調べて、関連する部分をカット アンド ペーストし、ほとんど同じですが非常に微妙な違いがあるコピーを作成することが含まれます。(注: これは一般的に悪い習慣と考えられています。)
しかし、1 つのことだけを実行し、1 つのことを非常にうまく実行する小さくて簡潔なメソッドを作成すると、既に構築したビルディング ブロックを使用して、他のものを構築し、時間を節約し、節約できることがわかります。 QA 時間、および一般的にプロジェクトのメンテナンス コストを削減し、製品を前進させ、前進してよりクールな作業を実行できるようにします。
ただし、最後に 1 つ考慮すべき点は、それをやり過ぎたり、過剰に設計したりする可能性があるということです。長すぎることと短すぎることの間には微妙な境界線があり、メソッドを分割しすぎたくなるかもしれません。メソッドを分割すると作業が難しくなりすぎる場合は、少しやりすぎている可能性があると考えてください。幸運を！