2

7 つの潜在的な入力を考慮して、重要な値を導出する必要があります。ボブおじさんは、それほど多くのパラメーターを持つ関数を避けるように私に促したので、クラスを抽出しました。すべてのパラメーターがプロパティになりました。引数のない計算方法が残っています。

「あれ」は、「プロパティかもしれないが、慣用的な C# かどうかはわからない」と思います。

最終結果をプロパティとして、または引数なしのメソッドとして公開する必要がありますか? 平均的な C# プログラマーは、プロパティを混乱させたり不快に感じたりするでしょうか? Alt.Net クラウドはどうですか?

decimal consumption = calculator.GetConsumption(); // obviously derived
decimal consumption = calculator.Consumption; // not so obvious

後者の場合:中間結果を [private] properties として宣言する必要がありますか? 重いメソッド抽出のおかげで、いくつかの中間結果が得られました。これらの多くは、パブリック API の一部であってはなりません。ただし、それらのいくつかは興味深いものになる可能性があり、それらにプロパティとしてアクセスできれば、私の式はよりきれいに見えます。

decimal interim2 = this.ImportantInterimValue * otherval;

ハッピー実験部：

VS2008 で自分のコードをデバッグしているときに、中間結果を計算するメソッド呼び出しの上にマウスを置いたままにして、戻り値が表示されることを期待していることに気付きました。すべてのメソッドをプロパティに変換した後、中間結果をプロパティとして公開すると、デバッグに非常に役立つことがわかりました。私はそれで十分満足していますが、可読性について長引く懸念があります。

暫定的な値の宣言はより乱雑に見えます。ただし、式は括弧なしで読みやすくなります。メソッド名を動詞で始める必要はもうありません。対照的に：

// Clean method declaration; compulsive verby name; callers need
// parenthesis despite lack of any arguments.
decimal DetermineImportantInterimValue() {
    return this.DetermineOtherInterimValue() * this.SomeProperty;
}

// Messier property declaration; clean name; clean access syntax
decimal ImportantInterimValue {
    get {
        return this.OtherInterimValue * this.SomeProperty;
    }
}

おそらく、私は 10 年間 Python でコーディングしてきたことを説明する必要があります。私は、自分のコードを書くよりも呼び出しやすくするために余分な時間を費やす傾向にありました。ただし、Python コミュニティがこのプロパティ指向のスタイルを受け入れ可能な「Pythonic」と見なすかどうかはわかりません。

def determineImportantInterimValue(self):
    "The usual way of doing it."
    return self.determineOtherInterimValue() * self.someAttribute

importantInterimValue = property(
    lambda self => self.otherInterimValue * self.someAttribute, 
    doc = "I'm not sure if this is Pythonic...")
4

5 に答える 5

5

ここでの重要な質問は次のようです。

長期的に見て、より読みやすく保守しやすいコードを生成するのはどれですか?

私の個人的な意見では、個々の計算をプロパティとして分離することには、単一のモノリシックなメソッド呼び出しよりもいくつかの明確な利点があります。

  • 現在のクラス メソッドに関係なく、デバッガで実行される計算を確認できます。これは、クラスのデバッグ中の生産性に恩恵をもたらします。

  • 計算が離散的である場合、プロパティは非常に迅速に実行されます。つまり、(私の意見では) プロパティ設計のルールに従っています。デザインのガイドラインを拘束具として扱うべきだと考えるのはばかげています。注意:特効薬はありません。

  • 計算がプライベートまたは内部としてマークされている場合、クラスのコンシューマーに不要な複雑さを追加することはありません。

  • すべてのプロパティが十分に離散的である場合、コンパイラのインライン化によってパフォーマンスの問題が解決される場合があります。

  • 最後に、最終的な計算を返す final メソッドが、それを読むことができるため、保守と理解がはるかに簡単である場合、それ自体が非常に説得力のある議論です。

あなたにできる最善のことの 1 つは、自分で考え、同業者や前任者の先入観であるフリーサイズの概念にあえて挑戦することです。すべての規則には例外があります。今回の件もその一つかもしれません。

追記: ほとんどの場合、標準的なプロパティ デザインを放棄する必要はないと思います。しかし、The Standard(TM) からの逸脱が求められる場合があります。そうすることが理にかなっているからです。

于 2009-07-17T02:51:20.647 に答える
0

7 つの入力から値を導出し、入力ごとに 1 つずつ、7 つのプロパティを実装し、結果のプロパティ ゲッターがあるとします。あなたが考慮したいかもしれないいくつかのことは次のとおりです。

  • 呼び出し元が 7 つの「入力」プロパティの 1 つまたは複数の設定に失敗した場合はどうなりますか? 結果はまだ意味がありますか？例外がスローされますか (ゼロ除算など)?

  • 場合によっては、API が見つけにくくなることがあります。7 つのパラメーターを受け取るメソッドを呼び出さなければならない場合、結果を得るには 7 つのパラメーターすべてを指定する必要があることがわかっています。また、パラメーターの一部が省略可能である場合は、メソッドのさまざまなオーバーロードにより、どのパラメーターかが明確になります。

    対照的に、"result" プロパティにアクセスする前に 7 つのプロパティを設定する必要があるほど明確ではなく、そのうちの 1 つを忘れがちです。

  • 複数のパラメーターを持つメソッドがある場合、より簡単に充実した検証を行うことができます。たとえば、「パラメーター A とパラメーター B の両方が null である」場合、ArgumentException をスローできます。

    入力にプロパティを使用する場合、各プロパティは個別に設定されるため、入力が設定されているときは検証を実行できません。結果のプロパティが逆参照されているときのみ、直感的ではない可能性があります。

于 2009-07-17T06:30:54.853 に答える
0

メソッドを使用して、オブジェクトに対するアクション、またはオブジェクトの状態を変更するアクションを示します。したがって、この場合、他のプロパティから値を計算する関数の名前を CalculateConsumption() とします。

于 2009-07-17T03:00:01.817 に答える