我需要添加一個方法來計算工人工資和他的高級工資的加權和。我想這樣的事情：我應該在哪裏放置我的第一個方法
class CompanyFinanse
{
public decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior)
{
return WorkerA.Salary + Superior.Salary * 2;
}
}
這是一個很好的設計，或者我應該把這個方法放在別的地方嗎？我只是盯着設計項目，並想到一個好的，面向對象的組織方法的方法。所以我想從OOP開始。最佳實踐需要！
所以它可能無法爲您提供關於「最佳實踐」一個完整的答案不知道更多關於你的域名，但我可以告訴你，你可以自己設置通過早期考慮實施細節來解決災難。
如果你和我一樣，那麼你就會被教導，很好的OOD/OOP是非常詳細的，涉及到BDUF。直到後來我的職業生涯中，我發現這是的原因，許多項目後來變得非常難以維護。假設是關於項目如何工作的，而不是讓設計自然地從代碼的實際使用中出現。
你最終會得到什麼，你確實需要什麼，什麼都不需要（大部分時間）。您獲得了全面測試覆蓋的額外好處，因此您可以在以後重構而不用擔心打破東西:)
我知道我沒有給你任何代碼，但那是因爲我給你的任何東西可能會出錯，然後你會被卡住。只有你知道代碼是如何被使用的，你應該以這種方式編寫代碼。 TDD專注於代碼的外觀，然後您可以隨時填寫實施細節。
對此的完整解釋超出了本文的範圍，但網上有大量資源可供使用，並且有許多書籍是開始TDD實踐的絕佳資源。這兩個人應該讓你有一個好的開始。
爲了讓您的設計成爲面向對象，您應該首先考慮整個應用程序的目的。如果您的應用程序中只有一種方法（加權總和），那麼沒有太多設計要繼續。
如果這是一個財務應用程序，也許你可以有一個Salary類，其中包含一個工人的薪水和一些實用功能。
對於您指出的方法，如果Worker類具有對其Superior的引用，那麼可以使此方法成爲Worker類的一部分。
沒有關於應用程序目的的更多信息，很難提供良好的指導。
我會把它放在工人類中，或者在財務庫中有一個靜態函數。我不認爲一個財務對象真的有意義，我認爲它更像是一組業務規則，而不是任何事情，所以它將是靜態的。
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; }
}
由布賴恩回答跟進，我建議看CRC cards（類 - 職責 - 協作）的做法。有很多信息來源，包括：
瞭解哪個類應該「擁有」特定行爲（和/或哪些類應該在實現給定用例時進行協作），通常是由您的總體設計驅動的自頂向下的討論系統正在爲其用戶服務。
很容易找出你的代碼是否需要改進。代碼中有代碼異味。你應該解決這個問題。
這是很好，你有非常說明性的名稱的方法。但它太長了。聽起來好像你在這個類中保留這個方法是不可避免的，你必須使用方法名中的所有單詞來了解該方法的意圖。
它基本上意味着這種方法可能不屬於這個類。
解決此代碼異味的一種方法是查看如果我們在其他類上有方法可以獲得較短的方法名稱。我看你有Worker和Salary類。
假設這些是唯一剩下的班級，而且您不想添加更多班級，我會將其放在Salary上。 Salary知道如何計算加權工資給予另一個工資（在這種情況下爲高級工資）作爲輸入。現在，您不需要兩個以上的單詞作爲方法名稱。
@ Shawn的回答是解決這種代碼異味的一種變體。 （我認爲你可以稱之爲'長方法名'代碼味道）
它的拼寫爲「金融」 – StingyJack 2008-12-29 17:14:52