0

労働者の給与と彼の上位給与の加重合計を計算するメソッドを追加する必要があります。私はこのようなものが欲しいです:

class CompanyFinanse
{
      public decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior)
      {
           return WorkerA.Salary + Superior.Salary * 2;
      }
}

これは良い設計ですか、それともこのメソッドを別の場所に配置する必要がありますか? 私はプロジェクトの設計を始めたばかりで、クラ​​ス内のメソッドを整理するための優れたオブジェクト指向の方法について考えています。ですから、OOP を念頭に置いて最初から始めたいと思います。ベストプラクティスが必要です!

4

5 に答える 5

6

私はそれをワーカークラスに入れるか、金融ライブラリに静的関数を入れます。Finance オブジェクトは本当に理にかなっているとは思いません。何よりも一連のビジネス ルールになると思うので、静的になります。

public class Worker {
     public Worker Superior {get;set;}
     public readonly decimal WeightedSalary {
         get {
              return (Superior.Salary * 2) + (this.Salary)
         }
     }
     public decimal Salary {get;set;}
}

また

public static class Finance {
     public static decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior) {
         return WorkerA.Salary + Superior.Salary * 2; }
}
于 2008-12-29T14:13:45.707 に答える
5

デザインをオブジェクト指向にするためには、アプリケーション全体の目的を考えることから始める必要があります。アプリケーションにメソッドが 1 つしかない場合 (加重合計)、続行する設計はそれほど多くありません。

これが金融アプリケーションの場合、従業員の給与といくつかのユーティリティ関数を含む Salary クラスを作成できます。

あなたが指摘したメソッドについては、Worker クラスが彼の上司への参照を持っている場合、このメソッドを Worker クラスの一部にすることができます。

アプリケーションの目的に関する詳細情報がなければ、適切なガイダンスを提供することは困難です。

于 2008-12-29T14:06:48.063 に答える
2

そのため、ドメインについて詳しく知らずに「ベスト プラクティス」について完全な回答を提供することは不可能かもしれませんが、実装の詳細についてこれほど早い段階で考えることで、災害に備えている可能性があると言えます。

あなたが私のような人なら、優れた OOD/OOP は細心の注意を払って詳細に説明され、 BDUF が含まれていると教えられました。これが非常に多くのプロジェクトが後になってひどく保守不能になる理由であることに気がついたのは、私のキャリアの後半になってからでした。コードが実際にどのように使用されるかから設計が自然に浮かび上がるのではなく、プロジェクトがどのように機能するかについて仮定が行われます。

簡単に言えば、 BDD / TDD（ビヘイビア/テスト駆動開発）を行う必要があります。

  1. 大まかなドメイン モデルをスケッチするところから始めますが、詳細になりすぎないようにします。
  2. 開始する機能領域を選択します。できれば、モデルの上部、またはユーザーが操作するモデルの上部に配置します。
  3. ユニットに期待される機能についてブレインストーミングし、リストを作成します。
  4. そのユニットで TDD サイクルを開始し、その後積極的にリファクタリングします。

最終的に得られるものはまさに必要なものであり、不要なものは何もありません (ほとんどの場合)。テストを完全にカバーするという追加の利点が得られるため、後で何かを壊すことを心配することなくリファクタリングできます:)

ここでコードを提供していないことはわかっていますが、それは、私が提供するものはおそらく間違っているため、あなたはそれで立ち往生するでしょう. コードが実際にどのように使用されるかを知っているのはあなただけであり、その方法でコードを書くことから始めるべきです。TDD は、コードがどのように見えるべきかということに焦点を当てており、その後、実装の詳細を入力していくことができます。

これについての完全な説明は、この投稿の範囲を超えていますが、オンラインで入手できるリソースは無数にあり、TDD の実践を開始するための優れたリソースである書籍も多数あります。この2人でいいスタートが切れるはずです。

于 2008-12-29T15:21:48.207 に答える
0

コードを改善する必要があるかどうかは簡単にわかります。スニペットにコードの匂いがあります。あなたはそれに対処する必要があります。

メソッドに非常に宣言的な名前を付けることは良いことです。しかし、長すぎます。そのメソッドをこのFinanseクラスに保持する場合、そのメソッドが何を意図しているのかを理解するために、メソッド名にこれらすべての単語を使用する必要があることは避けられないようです。

これは基本的に、このメソッドがこのクラスに属していない可能性があることを意味します。

このコードの臭いに対処する 1 つの方法は、他のクラスにメソッドがある場合に、より短いメソッド名を取得できるかどうかを確認することです。私はあなたがクラスを持っWorkerているのを見ます。Salary

それらが残っている唯一のクラスであり、これ以上クラスを追加したくないと仮定すると、これをSalary. Salary別の給与 (この場合は上級給与) を入力として加重給与を計算する方法を知っています。メソッド名に 2 つ以上の単語は必要ありません。

@Shawnの答えは、このコードの匂いに対処する1つのバリエーションです。（「長いメソッド名」のコード臭と呼んでもいいと思います）

于 2009-01-03T09:44:20.230 に答える
0

brien の回答に続いて、CRC カード(Class-Responsibility-Collaboration) の実践を検討することをお勧めします。次のような多くの情報源があります。

どのクラスが特定の動作を「所有」する必要があるか (および/または特定のユース ケースを実装するためにどのクラスが協力する必要があるか) を理解することは、一般に、システムがユーザーに対して行っていることの全体的な設計によって推進されるトップダウンの種類の議論です。 .

于 2008-12-29T17:12:18.873 に答える