Объектные методы и статистика - лучший подход к объектно-ориентированному проектированию

Question

Мне нужно написать какой-нибудь метод экземпляра, что-то вроде этого (код в ruby):

def foo_bar(param)
  foo(param)
  if some_condition
    do_bar(param)
  else
    do_baz(param)
  end
end

Метод foo_bar является публичным API.Но я думаю, что переменная param здесь появляется слишком много раз.Может быть, было бы лучше создать личную переменную экземпляра и использовать ее в методах foo, do_bar и do_baz?Как здесь: (@param является переменной экземпляра в ruby, ее можно инициализировать в любое время)

def foo_bar(param)
  @param = param
  foo
  if some_condition
    do_bar
  else
    do_baz
  end
end

Какой код лучше?И почему?

Answer 1

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

Вторая причина, по которой предпочтение отдается первой версии кода, заключается в том, что он более функциональный и облегчает повторное использование. Скажем, что другой модуль или лямбда-функция реализуют do_bar лучше, чем текущий. Это не было бы закодировано, чтобы предположить некоторый родительский класс с определенной именованной переменной экземпляра. Для возможности многократного использования он будет ожидать, что любые переменные будут переданы в качестве параметров.

Функциональный подход - намного лучший подход ... даже в объектно-ориентированных языках.

Answer 2

Параметр заменяет часть состояния объекта?

Если параметр не изменяет состояние объекта , то было бы неправильно вводить неочевиднымсвязь между этими методами для удобства.

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

Если param напрямую устанавливает состояние объекта , тогда я бы изменил переменную экземпляра здесь, но только после проверки, что новое состояниене противоречит

Answer 3

Если вам не нужен param вне метода foo_bar, первая версия лучше. Более очевидно, какая информация передается, и вы делаете ее более дружественной к потокам.

И я также согласен с Младеном в приведенном выше комментарии: не добавляйте что-либо к состоянию объекта, которое там не принадлежит.