Подтвердить что ты не робот

Почему рубокоп или рубиновый стиль предпочитают не использовать get_ или set_?

Я запускал rubocop в своем проекте и исправлял жалобы, которые он поднял.

Одна конкретная жалоба беспокоила меня

Do not prefix reader method names with get_

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

Я нашел этот фрагмент

    def bad_reader_name?(method_name, args)
      method_name.start_with?('get_') && args.to_a.empty?
    end

    def bad_writer_name?(method_name, args)
      method_name.start_with?('set_') && args.to_a.one?
    end

Итак, совет или соглашение таковы:

1) На самом деле они советуют нам не использовать get_, когда метод не имеет аргументов. в противном случае они позволяют получить _

2) И они советуют нам не использовать set_, когда метод имеет только один аргумент. В противном случае они разрешают set_

В чем причина этого соглашения или правила или совета?

4b9b3361

Ответ 1

Я думаю, что здесь суть ruby ​​devs предпочитают всегда думать о методах как getters, поскольку они что-то возвращают и используют равный "синтаксический сахар" (например, в def self.dog=(params), который позволяет вам делать Class.dog = something). По сути дела, я всегда видел, что get и set являются избыточными и многословными.

В противоположность этому вы получаете и устанавливаете с несколькими аргументами, которые похожи на методы поиска (особенно, узнайте об ActiveRecord where).

Имейте в виду, что "руководство по стилю" = чистое мнение. Согласованность - это более высокая цель руководства по стилю в целом, поэтому, если что-то не является ошибочным или трудночитаемым, ваша цель должна состоять в том, чтобы иметь все то же, что и для определенного типа. Вот почему rubocop позволяет вам отключить это.

Ответ 2

Еще один способ увидеть это: парадигма getter/setter была, насколько я могу судить, в значительной степени конкретным соглашением в Java/С++ и т.д.; по крайней мере, я знал довольно много кодовых баз Java в туманном прошлом, где Beans были завалены огромными количествами get_-getters и set_-seters. В то время частный атрибут, скорее всего, будет называться "name" с "set_name()" и "get_name()"; поскольку сам атрибут был назван "имя", геттер не мог быть "name()".

Следовательно, само существование "get_" и "set_" связано с (тривиальным) техническим недостатком языков, которые не позволяют "=" в именах методов.

В Ruby у нас есть совершенно другой набор возможностей:

  • Прежде всего, мы имеем name() и name=(), что сразу устраняет необходимость синтаксиса get_ и set_. Итак, у нас есть геттеры и сеттеры, мы просто называем их иначе, чем Java.

  • Кроме того, атрибут не является name, а @name, следовательно, также разрешает этот конфликт.

  • На самом деле, у вас нет атрибутов с простым синтаксисом "obj.name" вообще! Для eaxmple; в то время как Rails/ActiveRecord делает вид, что "person.name" является "атрибутом", на самом деле это просто пара автогенерированных getter name() и setter name=(). В общем случае вызывающий абонент не должен заботиться о том, что такое "имя" (атрибут или метод), это деталь реализации этого класса.

  • Он сохраняет 4 или 3 нажатия клавиш для каждого вызова. Это может показаться шуткой, но писать сжатый, но легко понятный код является товарным знаком Ruby.: -)