Когда стоит определить статический класс ruby?

Question

Существуют ли какие-то руководящие правила, когда имеет смысл определять статический класс, а не класс, для которого создается экземпляр?

Все еще озадачивается идиоматической инициализацией ruby ​​по сравнению с определением статического класса.

Из того, что я нашел.

Статические классы кажутся очень эффективными.

1. ruby ​​- это и функциональный, и объектно-ориентированный язык.очень возможно написать оба стиля.функциональный стиль очень полезен для «функциональных» вещей.
2. Я регулярно наблюдаю, как классы переходят от статических к экземплярам, ​​а затем очень быстро раздуваются.«Теперь у нас есть все эти вещи ... почему бы не сделать больше ?!».я вижу, что экземпляры классов имеют естественную тенденцию к расширению обязанностей.
3. я вижу, что когда класс переходит от статического к экземпляру, мы получаем меньше уверенности в модульном тестировании, поскольку во время выполнения вещи могут измениться в отношении памятивыделение / назначение (как, например, кто-то мог случайно попасть между созданием экземпляра и вызовом).
4. Я считаю, что статические классы легче читать, потому что нам не нужно жонглировать потенциальными соображениями об изменении состояния.меньше мутаций = меньше сложности.

Для меня.Большие проблемы:

1. Классы делают больше, чем одно.
2. Нестабильность в шаблонах на больших старых базах кода ruby.

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

Static

Serializer.transform(fruit:)

Создан

Serializer.new(fruit:).transform

Что заставляет вас работать в рубине статично?

Answer 1

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

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

Кроме того, я бы не стал воспринимать это как статический по сравнению с созданным экземпляром.Вы действительно спрашиваете о чистом функционале против ОО подхода.И, наконец, не приравнивайте ОО к «мутации».Вы можете использовать неизменяемые значения в ruby, и я рекомендую их.Возможно, вы захотите проверить экосистему dry-rb на предмет дисциплинированного подхода, который защищает чисто функциональные концепции таким образом, который гармонирует с естественной поддержкой объектов ruby.

Answer 2

Хм.Руководящие принципы?

Когда писать статический класс ruby:

• , когда это необходимо для инкапсуляции простого кусочка логики с небольшим количеством входов.такие вещи, как "сериализация модели" или принятие "бизнес-решения" с одним параметром.
• , когда масштаб управления памятью является критической проблемой.

Когда писать класс ruby, которыйпредназначен для инициализации:

• , когда требуется постоянство.(например, активные модели записи)
• , когда это обычный фрагмент кода (с несколькими параметрами), который часто является инъекцией.
• , когда это логика «оркестровки или маршрутизации» с внедренными зависимостями.

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

Answer 3

Другой ответ скопирован с коллеги [CH].

Мне всегда нравится сравнивать некоторые из этих решений:

require 'benchmark'

class ClassMethod
  def self.do_work
    1_000_000 * 1_000_000
  end
end

class InstanceMethod
  def do_work
    1_000_000 * 1_000_000
  end
end

class InstanceMethodHiddenByClassMethod
  def self.do_work
    new.do_work
  end

  def do_work
    1_000_000 * 1_000_000
  end
end

iterations = 10_000_000

Benchmark.bm do |x|
  x.report("class method") do
    iterations.times do
      ClassMethod.do_work
    end
  end

  x.report("instance method") do
    iterations.times do
      InstanceMethod.new.do_work
    end
  end

  x.report("class hiding instance pattern") do
    iterations.times do
      InstanceMethodHiddenByClassMethod.do_work
    end
  end
end

Результаты

user                           system     total      real
class method                   0.520000   0.010000   0.530000 (  0.531997)
instance method                1.130000   0.000000   1.130000 (  1.131185)
class hiding instance pattern  1.270000   0.010000   1.280000 (  1.282921)