Где я должен поставить свой первый метод

Question

Мне нужно добавить метод, который будет рассчитывать взвешенную сумму заработной платы работника и его более высокой заработной платы. Я хотел бы что-то вроде этого:

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

Это хороший дизайн или я должен поместить этот метод в другом месте? Я только начинаю проектирование проекта и думаю о хорошем, объектно-ориентированном способе организации методов в классах. Поэтому я хотел бы начать с ООП в уме. Нужна лучшая практика!

Answer 1

Я бы поместил его в рабочий класс или имел статическую функцию в финансовой библиотеке. Я не думаю, что объект «Финансы» действительно имеет смысл, я думаю, что это будет скорее набор бизнес-правил, чем что-либо, поэтому он будет статичным.

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; }
}

Answer 2

Чтобы ваш дизайн был объектно-ориентированным, вы должны начать думать о цели всего приложения. Если в вашем приложении есть только один метод (взвешенная сумма), то разработка не слишком сложна.

Если это финансовое приложение, возможно, у вас может быть класс Salary, содержащий зарплату работника и некоторые вспомогательные функции.

Для указанного вами метода, если класс Worker имеет ссылку на его Superior, вы можете сделать этот метод частью класса Worker.

Без дополнительной информации о цели применения трудно дать хорошее руководство.

Answer 3

Так что может быть невозможно дать вам полный ответ о «лучших методах», не зная больше о вашем домене, но я могу вам сказать, что вы можете настраивать себя на случай катастрофы, подумав о деталях внедрения на ранней стадии. 1001 *

Если вы похожи на меня, то вас учили, что хороший OOD / OOP тщательно детализирован и включает в себя BDUF . Только позже в моей карьере я узнал, что это - причина , так что многие проекты становятся вопиюще неосуществимыми позже в будущем. Делаются предположения о том, как проект может работать, вместо того, чтобы позволить дизайну возникать естественным образом из того, как на самом деле будет использоваться код.

Проще говоря: вам нужно делать BDD / TDD (Поведение / разработка через тестирование).

1. Начните с наброска приблизительной модели предметной области, но избегайте слишком большого количества деталей.
2. Выберите функциональную область, с которой вы хотите начать. Предпочтительно в верхней части модели или с той, с которой пользователь будет взаимодействовать.
3. Мозговой штурм ожидаемой функциональности, которая должна быть у устройства, и составление списка.
4. Запустите цикл TDD на этом устройстве, а затем активно проводите рефакторинг.

То, что вы в итоге получите, это именно то, что вам нужно, и ничего, что вам не нужно (большую часть времени). Вы получаете дополнительное преимущество, имея полное покрытие тестами, поэтому вы можете проводить рефакторинг в будущем, не беспокоясь о поломках:)

Я знаю, что здесь я не дал вам никакого кода, но это потому, что все, что я вам даю, вероятно, будет неверным, и тогда вы застрянете с этим. Только вы знаете, как на самом деле будет использоваться код, и вам следует начать с написания кода таким образом. TDD фокусируется на том, как должен выглядеть код, а затем вы можете по мере необходимости заполнять детали реализации.

Полное объяснение этого выходит за рамки данного поста, но в Интернете доступно множество ресурсов, а также множество книг, которые являются отличными источниками для начала практики TDD. Эти два парня должны дать вам хорошее начало.

• Мартин Фаулер
• Кент Бек

Answer 4

Легко узнать, нуждается ли ваш код в улучшении. В вашем фрагменте кодовый запах . Вы должны обратиться к этому.

Хорошо, что у вас есть очень декларативное имя для метода. Но это слишком долго. Похоже, если вы сохраните этот метод в этом Finanse классе, то неизбежно, что вам придется использовать все эти слова в имени метода, чтобы понять, для чего предназначен этот метод.

Это в основном означает, что этот метод может не принадлежать этому классу.

Один из способов устранения этого запаха кода - посмотреть, сможете ли вы получить более короткое имя метода, если у нас есть метод в другом классе. Я вижу, у вас есть Worker и Salary классы.

Предполагая, что это единственные оставшиеся классы, и вы не хотите добавлять дополнительные классы, я бы поставил это на Salary. Salary знает, как рассчитать взвешенную зарплату, учитывая другую зарплату (в данном случае выше зарплату) в качестве входных данных. Вам не нужно больше двух слов для названия метода.

@ Ответ Шона - один из вариантов устранения этого запаха кода. (Я думаю, вы можете назвать это «запахом кода с длинным именем метода»)

Answer 5

В ответ на ответ Брайена я предлагаю взглянуть на практику CRC-карт (Class-Responsibility-Collaboration). Существует много источников информации, в том числе:

• этот урок от Cal Poly,
• эта ориентация на веб-сайте Agile Modeling и
• Книжная книга CRC , в которой обсуждается практика и ее использование на нескольких языках.

Понимание того, какой класс должен «владеть» определенным поведением (и / или какие классы должны сотрудничать при реализации конкретного варианта использования), в общем, является нисходящим видом обсуждения, обусловленным общим дизайном того, что делает ваша система для своих пользователей.