Каковы преимущества и недостатки динамического типа в Ruby?

Question

Допустим, у меня есть класс с именем Tool:

class Tool
    def initialize( name, weight )
        @name = name
        @weight = weight
    end

    attr_reader :name, :weight
    attr_writer :name, :weight

    def to_s
        name + " " + weight
    end
end

Но этот Tool может быть человеком, если я хочу:

hammer = Tool.new( "Hammer", 14.5 )
pp = Tool.new( "first", "last" )

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

Answer 1

Ruby не печатается свободно.Наоборот, это очень сильно напечатано.Однако он также динамически типизирован (в отличие от статически типизированных, таких как C ++ и Java).Вы должны прочитать о различиях.PHP является примером слабо типизированного языка.

И, чтобы ответить на ваш вопрос, языки с динамической типизацией, такие как Ruby и Python, очень трудно писать с любой сложностью без использования тест-ориентированной разработки.Это значит, что вы стараетесь сначала написать тесты, чтобы объяснить ожидания и определить свои классы и API, чтобы люди знали, как их использовать, просто руководствуясь здравым смыслом.Если вы действительно беспокоитесь о том, что клиенты передают недопустимые типы вашим методам, вы всегда можете проверить тип и выбросить исключения, если типы неправильные.Однако это обычно не делается в масштабе всей системы.

Answer 2

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

Что касается надежности, как и нулевых указателей, ошибки типов обычно вызывают катастрофические сбои довольно быстро, поэтому они никогда не останутся незамеченными в течение длительного времени. Так что ИМХО класс ошибок, предотвращаемых статической типизацией, не так уж интересен. С другой стороны, любой мог написать Tool.new( "Hammer", -42 ), что было бы правильно при вводе, но отрицательный вес, вероятно, приведет к очень странному поведению без сбоев. Это потому, что роль этого аргумента - weight , который никогда не бывает отрицательным, и вы не можете выразить это простым числовым типом. Поэтому во время разработки действительно нужны не статические типы, а проверки или контракты, как в Eiffel.

Теперь рассмотрим непредвиденную эволюцию программного обеспечения: вы хотите интегрировать поддержку единиц СИ. Понимаете ли вы, почему проектное решение статической типизации этого параметра числом теперь выглядит преждевременным? В динамически типизированной системе проще создать новый объект, который знает арифметику, но учитывает преобразования единиц измерения, и использовать его непосредственно вместо чисел в существующем коде.

Конечно, статические типы имеют ценность для документации, а языки с динамической типизацией требуют некоторой дисциплины в этой области, а именно: четкое именование, хорошие тесты, хорошие комментарии ... но в любом случае ни один из них не является лишним со статической типизацией.

Answer 3

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

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

[править]

И чтобы пользователи не могли вводить неверные данные, вы можете изменить метод weight=, созданный вашим attr_writer, следующим образом:

def weight= value
 @weight = value.to_i # only store integers
end

Или проверьте, что введенная строка на самом деле является числом, и в противном случае выведите исключение.