我需要添加一个方法来计算工人工资和他的高级工资的加权和。我想这样的事情：我应该在哪里放置我的第一个方法
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