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

为了使您的设计是面向对象的，您应该从考虑整个应用程序的目的开始。如果您的应用程序中只有一种方法（加权和），那么就没有太多的设计可以继续了。

如果这是一个金融应用程序，也许你可以有一个 Salary 类，其中包含工人的薪水和一些实用函数。

对于您指出的方法，如果 Worker 类有对其上级的引用，您可以将此方法作为 Worker 类的一部分。

如果没有更多关于申请目的的信息，很难给出好的指导。

于 2008-12-29T14:06:48.063 回答
2

因此，在不了解您的域的更多信息的情况下，可能无法为您提供有关“最佳实践”的完整答案，但我可以告诉您，尽早考虑实施细节可能会让您陷入灾难。

如果您像我一样，那么您会被告知良好的 OOD/OOP 非常详细，并且涉及BDUF。直到在我职业生涯的后期，我才发现这就是许多项目在以后变得非常难以维护的原因。假设项目可能如何工作，而不是让设计从代码的实际使用方式中自然出现。

简单地说：你需要做BDD / TDD（行为/测试驱动开发）。

  1. 从勾勒出粗略的领域模型开始，但要避免过多的细节。
  2. 选择您想开始使用的功能区域。最好在模型的顶部，或者用户将与之交互的模型顶部。
  3. 集体讨论该单元应具有的预期功能并列出清单。
  4. 在该单元上启动 TDD 循环，然后在进行时积极重构。

你最终会得到的正是你所需要的，而不是你不需要的（大多数时候）。您获得了拥有完整测试覆盖率的额外好处，因此您可以在以后重构而不用担心破坏东西:)

我知道我在这里没有给你任何代码，但那是因为我给你的任何东西都可能是错误的，然后你就会被它困住。只有您知道代码实际上将如何被使用，并且您应该从以这种方式编写代码开始。TDD 专注于代码的外观，然后您可以随时填写实现细节。

对此的完整解释超出了本文的范围，但网上有无数可用资源以及许多书籍是开始 TDD 实践的极好资源。这两个家伙应该让你有一个好的开始。

于 2008-12-29T15:21:48.207 回答
0

跟进brien的回答，我建议查看CRC卡（Class-Responsibility-Collaboration）的实践。有许多信息来源，包括：

了解哪个类应该“拥有”特定行为（和/或哪些类应该协作实现给定的用例）通常是一种自上而下的讨论，由系统为其用户所做的整体设计驱动.

于 2008-12-29T17:12:18.873 回答
0

很容易找出您的代码是否需要改进。您的代码段中有代码气味。你应该解决这个问题。

最好为该方法提供非常明确的名称。但它太长了。听起来，如果您将该方法保留在此类中Finanse，则不可避免地必须在方法名称中使用所有这些词来了解该方法的用途。

它基本上意味着这个方法可能不属于这个类。

解决这种代码异味的一种方法是查看如果我们在其他类上有方法，是否可以获得更短的方法名称。我看到你有Worker和Salary课。

假设这些是剩下的唯一课程并且您不想添加更多课程，我会将其放在Salary. Salary知道如何在给定另一个工资（在这种情况下为高级工资）作为输入的情况下计算加权工资。现在，方法名称不需要超过两个单词。

@Shawn 的答案是解决此代码异味的一种变体。（我认为您可以将其称为“长方法名称”代码气味）

于 2009-01-03T09:44:20.230 回答