5

私は 1 年生のコンピューター サイエンスの学生です。私たちは現在 Java でプログラミングを行っており、メイン メソッドのロジックが可能な限り疑似コードに近いものを読み取れるように、よく名前の付いたメソッドにプログラムを分解しようとします。

私が見つけた問題は、やり過ぎかもしれないと感じるほど多くの小さなプライベート メソッドを書くことになることがよくあるということです。問題をさらに分解するかどうかを決定する際に考慮すべき経験則やスタイル上の考慮事項はありますか?

4

5 に答える 5

13

経験則は、単一責任の原則です。コードの各ユニットは、 1 つのことだけを担当する必要があります。これは、クラスだけでなくメソッドにも当てはまります。多くのプライベート メソッドのそれぞれに、単純で簡潔な名前を付けることができれば、それで問題ありません。それをより大きな操作の「一部」としてしか説明できない場合は、おそらく別の方法にするべきではありません。

しかし、あなたの質問から、あなたはすでにそれを正しく行っているように思えます。

于 2010-08-16T12:31:15.130 に答える
10

ほとんどの新しい開発者は、多くの責任を持つ巨大な機能という逆の方向に進んでいます。あなたの状況はこれよりもはるかに好ましいです！

たくさんの小さなメソッドを作成することのマイナス面はほとんどなく、多くの利点があります!

短い方法は次のとおりです。

  • 再利用が容易
  • テストしやすい
  • 読みやすく理解しやすい
  • デバッグが容易

これを考慮して、複製を容赦なく小さなメソッドにリファクタリングすることをお勧めします。IDE は、これを高速化するための抽出メソッドのリファクタリングを提供します。

また、ある種の読み取り可能な擬似コードに対する aspring の目的は、一般的には良いことだと思います。目にするコードの多くはこのようには書かれていませんが、読みやすさと「コードはドキュメントである」という概念を実際に助けることができます。

メソッド呼び出しのパフォーマンス オーバーヘッドについて話す人もいますが、それが問題になるのは非常にまれなケースだけです。

編集 - 他のポスターは、単一責任の原則について言及しています。これは良いガイドラインですが、個人的にはこれよりもさらに進んでいると思います。明確に定義された 1 つの責任を持つ一部のコード フラグメントでさえ、再利用と読みやすさのために分解される可能性があります。

于 2010-08-16T12:32:55.857 に答える
4

コードを分割する上で最も重要な部分は、 Single Responsibility Principle (SRP)だと思います。すべてのオブジェクトには単一の責任があり、その責任はクラスによって完全にカプセル化されている必要があります

于 2010-08-16T12:31:11.873 に答える
2

私の哲学は、コードを原子的で論理的な単一の作業単位に分割することです。通常、何かに名前を付けることができます-そして、その作業をメソッドに入れ、その名前を付けます。

于 2010-08-16T12:27:01.077 に答える
2

私の一般的なルールは、関数が 1 つの画面に収まらない場合 (古い 24 行 x 80 列の端末を考えてください)、正当な理由がある方がよいというものです。時々あります。一般に、関数を読む人はすべてを理解する必要があることを覚えておく必要があります。長いとそれが難しくなります。

そうは言っても、2 行または 3 行の関数はあまり追加されません。多くの場合、それらは単独で理解するのが非常に簡単であり、それらに付けた名前は、より長い関数に埋め込まれたときにコード自体ほど多くの情報を伝えません。

例外は常にあります。正しい方法はありません。あなたの仕事は経験によって向上します。

于 2010-08-16T13:15:33.160 に答える