Использовать свойства или методы для представления бизнес-правил в C #?

Question

Я пишу класс для инкапсуляции некоторых бизнес-правил, каждое из которых представлено логическим значением. Класс будет использоваться при обработке формы InfoPath, поэтому правила получают текущее состояние программы путем поиска значений в глобальной структуре данных XML с использованием операций XPath. Каков наилучший (самый идиоматический) способ раскрытия этих правил для вызывающих абонентов - свойства или публичные методы?

Звоните, используя свойства

Rules rules = new Rules();
if ( rules.ProjectRequiresApproval ) {
    // get approval
} else {
    // skip approval
}

Вызов с использованием методов

Rules rules = new Rules();
if ( rules.ProjectRequiresApproval() ) {
    // get approval
} else {
    // skip approval
}

Класс правил, представляющий правила как свойства

public class Rules() {
    private int _amount;
    private int threshold = 100;

    public Rules()  {
        _amount = someExpensiveXpathOperation;
    }

    // rule property
    public bool ProjectRequiresApproval {
        get { return _amount > threshold }
    }
}

Класс правил, представляющий правила как методы

public class Rules() {
    private int _amount;
    private int threshold = 100;

    public Rules()  {
        _amount = someExpensiveXpathOperation;
    }

    // rule method
    public bool ProjectRequiresApproval() {
        return _amount > threshold;
    }
}

Каковы плюсы и минусы одного над другим?

Answer 1

Во-первых, вам нужно обернуть get {} вокруг логики свойств, и практическое правило (для меня, во всяком случае) должно заключаться в том, что метод может изменять содержимое класса или выполнять какую-то бизнес-логику, тогда как свойство предоставляет информацию о классе.

Для вашего использования я бы предложил свойство, поскольку значения уже существуют, а вы создаете так называемое производное свойство.

Кроме того, ваш код может быть изменен на

return _amount < threshold;

Answer 2

Все сводится к передаче семантики тому, кто потребляет эту бизнес-логику.

Свойство - это внутренняя стоимость определенного объекта. Rules в вашем примере представляет собой механизм бизнес-логики, поэтому любые свойства, которые он предоставляет, должны применяться к состоянию и поведению этого механизма, а не к данным, которые были обработаны им. Таким образом, ProjectRequiresApproval() - это действие, которое движок применяет к внешнему объекту.

Если, с другой стороны, существует метод Rules.GetProcess(), который возвращает объект Process, RequiresAproval может быть свойством этого объекта.

Answer 3

Я согласен с Энтони Кохом. Я использую методы, когда мне нужно выполнить сложное вычисление, которое изменяет состояние класса. Если для текущего состояния класса требуется простой расчет или извлечение данных, где данные уже существуют в этом состоянии и их не нужно изменять, свойство кажется более подходящим.

Answer 4

В соответствии с рекомендациями Свойства против методов для MSDN (правда, для более старой версии Visual Studio), кажется, что методы могут быть более подходящими, чем свойства в вашем случае (если правила становятся более сложными чем пороги).

Чуть больше возни с этим вопросом выявило следующее:

• отличный ответ от Кена Браунинга о свойствах и методах в целом
• A сообщение в блоге от Билла Вагнера (автор Effective C #) о том, какие условия должны быть выполнены для использования свойства
• Ссылки на несколько механизмов правил с открытым исходным кодом ( NxBRE и Drools.NET ), чтобы вы могли видеть альтернативы для реализации бизнес-правил.

Answer 5

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