クラスとメソッドをできるだけ小さくしますか？
数日前、私はソフトウェアエンジニアリングの博士号取得候補者と話していました。
クラスとメソッドをできるだけ小さくしてください
そして、これは常に良い習慣だと思います。
たとえば、属性が2つしかないクラスを作成することは価値がありますか？たとえば、一部のメソッドでは、使用する整数のペアが必要です。 「PairOfIntgers」クラスを作成する必要がありますか？
この考え方では、コードを分割しすぎてしまうでしょうか。
そのアドバイスには真実の粒がありますが、私見はそれがあまりよく表現されていないので、誤解しやすく、および/または愚かな極端に取るのは簡単です。とにかく、これは厳しい法則ではなく、経験則である必要があります。そして、あなたは常にそのようなルールに節 "合理的な範囲内"または "を暗示するべきですが、常識を使うことを忘れないでください":-)
実際には、クラスとメソッドは常に縮小ではなく、本質的に成長する傾向があります。ここでのバグ修正、小さな機能拡張、特別なケースの処理...そして出来上がり、かつてのきちんとした小さなクラスが膨らみ始めました。時間の経過とともに、コードはほぼ必然的にスパゲッティの巨大な混乱になる傾向があります- refactoring を介して積極的にこの傾向と戦わない限り。ほとんどの場合、リファクタリングは、いくつかの大きなクラスから多くの小さなクラス/メソッドを生成します。しかしもちろん、小型化には賢明な限界があります。 リファクタリングのポイントは、クラスやメソッド自体を小さくすることではなく、コードをよりクリーンに、理解しやすく維持することです。ある時点で、メソッド/クラスを小さくすると、読みやすさが増すのではなく、読みやすさが低下し始めます。その最適を目指します。ぼやけて動いているターゲット領域なので、ぶつかる必要はありません。ただ コードに問題があることに気づいたらコードを少し改善してください 。
ここで強調するより重要な問題は優れた抽象化の作成です。 スモールクラス疎結合で結合力が高い優れた抽象化の産物。
クラスに2つの整数をカプセル化することは、完全に意味がある場合があります。特に、これらの属性を操作する方法をカプセル化し、それらを変更するプログラムの他の部分から確実に保護するために、このクラスにメソッドを「アタッチ」したい場合。
この場合にクラスを作成するもう1つの利点は、マップやリストのような低レベルのデータ構造と言うよりも、クラスがはるかによく/より良く進化できることです。
第3に、優れた抽象化により、読みやすさが大幅に向上します。 SRPに準拠しているクラスは、通常、従わないクラスよりも人間が理解しやすいものです。
そして最後のメモとして...あなたがどんなに優秀な学生であっても... OOPと優れた抽象概念を理解し、いつ使用するかには、経験が必要です。書く必要があります。悪いコードとそれを維持するための苦痛を経験します。「良い」ものと将来の問題となるものについての知識を構築するために他の人が良いコードを書くのを見る必要があります...すぐに取得しないでください。
The God Object anti-pattern は、おそらく彼女がほのめかしていたものです。クラスの説明に「and」がある場合、2つのクラスが必要だと思いがちです。メソッド/関数に10行を超えるコードがある場合は、分割する必要があります。海賊コードとして、それらはルールよりもガイドラインです。
オブジェクト指向プログラミングでは、単一の責任の原則は、すべてのオブジェクトが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べています。通常、クラスが大きくなりすぎると、複数のことを実行します。あなたの場合、クラスは完全に大丈夫なデータを保持する単なるデータクラスです。クラスにPairOfIntegerという名前を付けることはできません。整数は何を表していますか？シナリオによっては、タプル（C＃など）でも十分な場合があります。また、クラスではなくストラットについて考えることもできます。
少人数制のクラスにしてください。そして、メソッドはさらに小さくなります。たぶん10行？！？現在、私はクラスを小さく保つのに役立つように見えるフロー設計とイベントベースのコンポーネントを使用しようとしています。最初はたくさんのクラスに行くのが心配でしたが、本当にうまくいきました!!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspxhttp：// geekswithblogs.net/theArchitectsNapkin/archive/2011/03/20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx
物事を可能な限り単純にしますが、単純にはしません。それが私が通ろうとしている規則です。時には、クラスが厳密に言えば複数のものに相当することを行うことは実際に意味がありますそれらがいくつかの共通のテーマに関連している場合。 .NETを見てください。多数のインターフェースを実装するクラスがたくさんあり、それぞれに必要なメンバーの独自のリストがあります。メソッドは、すべてが相互接続されており、したがって、さらなるリファクタリングにあまり役立たない多数の中間ステップで複雑な何かを行う場合、やや長くなる必要があるかもしれません。 （メソッドを短く保つためのリファクタリングは、最終的には可読性と保守性に関するものでなければなりません。長いメソッドの方が短いメソッドよりも可読性や保守性に優れている場合は、他のすべてが同じであれば、いつでも長いメソッドを使用します。）
「クラスとメソッドをできるだけ小さくする」ことだけは、私の意見では誤解されています。本当の課題は、@ c_makerが指摘するように、優れた抽象化を提供することです。 2つの数値をグループ化する例は、たとえば、複素数演算の実装で作業している場合や、Unixシステムでユーザー/グループコンテキストを参照する必要がある場合に適しています。数値が、たとえば請求書IDとその請求書に追加される製品IDを表す場合、ほとんど意味がありません。
これは問題ありませんが、多少インテリジェントに実装する必要があります。絶対に盲目的には従わないでください。
コードを見ると、メソッドが大きすぎるかどうかがわかります。実行が多すぎて読みにくい場合は、リファクタリングの時間です。
ここに良い例があります：ループがあり、そのメソッドにはおそらく60行のコードがあります。その場合は、おそらくそのメソッドでやりすぎているため、リファクタリングするときです。
しかし、それは厳格な規則ではありません。それはあなたが行うことによって学ぶことができるものだけです。そして、あなたが一緒に作業している他の開発者はいつも同意するわけではなく、コードレビューなどであなたを呼ぶかもしれません。
ボブおじさんは、メソッドをリファクタリング/分割/抽出する必要があると言っていますメソッドを小さくすることが不可能になるまで。これは通常、それぞれ3行または4行の複数のメソッドを持つことで終わります。メソッドが多すぎる場合は、さらに多くのクラスを作成する必要があります。
SRPおよびメソッドごとに1レベルの抽象化に従うことを試みた場合、これらのルールは役立ちます。少なくとも彼らは私によく役立ちます。 「できるだけ小さい」を目指すことは、私が通常目的を達成できないので、私に合理的な小さい方法を与えます。
また、小さいクラスを理解する方が常に簡単です。 「クリーンコード」を読んでください