Где находится правильная параметрическая проверка типов в динамических языках? - PullRequest
Новая
       11

Где находится правильная параметрическая проверка типов в динамических языках?

0 голосов
/ 13 января 2009

Учтите следующее. (в псевдокоде). 

Class
{
    hello
    world

    public
    constructor(hello, world)
    {
        if (hello is not String)
        {
            throw Exception()
        }

        if (world is not Array)
        {
            throw Exception()
        }

        this.setHello(hello)
        this.setWorld(world)
    }

    protected
    setHello(hello)
    {
        if (hello is not String)
        {
            throw Exception()
        }

        this.hello = hello
    }

    private
    setWorld(world)
    {
        if (world is not Array)
        {
            throw Exception()
        }

        if (not this:isASafe(world))
        {
           throw Exception()
        }

        this.world = world
    }

    public
    static
    isASafe(world)
    {
        if (world is not Array)
        {
            return false
        }

        if (world.length < 1)
        {
            return false
        }

        if (world['sky'] is not 'blue')
        {
            return false
        }

        return true
    }
}

  1. Рекомендуется ли выполнять параметрическую проверку типа / достоверности в конструкторе, а затем снова в функции или только в одном из двух методов. (т.е. метод конструктора xor).

  2. Кроме того, изменяет ли область действия (общедоступный / защищенный / частный / и т. Д.) Указанного метода вышеуказанный ответ (1). Например, isASafe (world) является общедоступным статическим методом и используется только в классе для инкапсуляции логики.

  3. Должны ли конструкторы делать какие-либо проверки?

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

1 Ответ

1 голос
/ 13 января 2009

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

Не всегда возможно проверить действительность во всех случаях - вопрос о том, что является действительным или нет, например, небо == синий, может отличаться в контексте, к которому у вас нет доступа.

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

Это означает, что я предпочитаю провести некоторую проверку работоспособности параметров для большинства методов. Я часто буду обходиться без проверки определенных частных методов, хотя вы рискуете, что кто-то (может быть, вы) когда-нибудь сделает их защищенными или общедоступными, и вы также упускаете возможность обнаружить несоответствие данных на один шаг ближе к источнику.

...