我需要添加一个方法来计算工人工资和他的高薪的加权和。我想要这样的东西:
class CompanyFinanse
{
public decimal WeightedSumOfWorkerSalaryAndSuperior(Worker WorkerA, Worker Superior)
{
return WorkerA.Salary + Superior.Salary * 2;
}
}
这是一个好设计还是我应该把这个方法放在其他地方?我只是盯着设计项目并思考一种良好的,面向对象的方法来组织类中的方法。所以我想从头开始考虑OOP。需要最佳实践!
答案 0 :(得分:6)
我要么把它放在工人类中,要么在财务库中有静态功能。我不认为财务对象真的有意义,我认为它更像是一套业务规则而不是任何东西,所以它会是静态的。
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; }
}
答案 1 :(得分:5)
为了使您的设计成为面向对象,您应该首先考虑整个应用程序的目的。如果您的应用程序中只有一种方法(加权和),那么设计就不会太多了。
如果这是一个财务应用程序,也许您可以拥有一个包含工人工资和一些效用函数的Salary类。
对于您指出的方法,如果Worker类具有对其Superior的引用,则可以将此方法作为Worker类的一部分。
如果没有关于申请目的的更多信息,很难提供良好的指导。
答案 2 :(得分:2)
因此,在不了解您的域名的情况下,可能无法为您提供有关“最佳实践”的完整答案,但我可以告诉您,您可能会通过早期考虑实施细节来为自己做好准备。< / p>
如果你像我一样,那么你就会被告知,好的OOD / OOP是精心细致的,涉及BDUF。直到我职业生涯的后期才发现这是 的原因,以后很多项目在以后会变得非常难以维护。关于项目如何工作的假设,而不是允许设计自然地从代码的实际使用方式中出现。
简单说明:你需要做BDD / TDD(行为/测试驱动开发)。
你最终会得到的正是你所需要的,而你所做的一切都没有(大部分时间)。您可以获得全面测试覆盖的额外好处,这样您就可以在以后的路上进行重构,而不必担心破坏内容:)
我知道我这里没有给你任何代码,但那是因为我给你的任何东西都可能是错的,然后你会被它困住。只有你知道代码实际上是如何使用的,你应该首先以这种方式编写代码。 TDD侧重于代码的外观,然后您可以随时填写实现细节。
对此的完整解释超出了本文的范围,但在线提供了大量资源以及许多书籍,这些资源是开始TDD实践的绝佳资源。这两个家伙应该让你有一个良好的开端。
答案 3 :(得分:0)
跟随布里恩的回答,我建议看看CRC cards(阶级责任合作)的做法。有许多信息来源,包括:
了解哪个类应该“拥有”特定行为(和/或哪些类应该在实现给定用例时协作),这通常是由系统正在进行的整体设计驱动的自上而下的讨论类型为其用户。
答案 4 :(得分:0)
很容易发现您的代码是否需要改进。您的代码段中有代码异味。你应该解决这个问题。
这个方法的名称非常具体,这很好。但它太长了。听起来如果你在这个Finanse
类中保留该方法,你必须使用方法名称中的所有单词来了解该方法的用途。
它基本上意味着此方法可能不属于此类。
解决这种代码味道的一种方法是,如果我们在其他类上使用该方法,您是否可以获得更短的方法名称。我发现您有Worker
和Salary
个类。
假设这些是剩下的唯一类,并且您不想添加更多类,我会将其放在Salary
上。 Salary
知道如何计算另一个薪水(在这种情况下是高薪)作为输入的加权工资。现在,方法名称不需要两个以上的单词。
@ Shawn的答案是解决这种代码气味的一种变体。 (我认为你可以把它称为'长方法名'代码味道)