Статический / строгий контроль типов и рефакторинг
Поскольку файлы temperature содержат бесплатные функции, вам больше ничего не нужно делать. Вы можете просто вызывать функции C из классов Objective-C. Если вы хотите сделать из них класс, вы тоже можете это сделать. Он не должен наследовать от NSObject, но это может быть полезно, потому что он позволяет вам вызывать различные NSObject методы для него, такие как -respondsToSelector:, -isKindOfClass: или -performSelector:.
5 ответов
Я думаю, вы смешиваете, когда проверяются типы, с тем, как они проверяются. Типизация во время выполнения не обязательно является слабой.
Главное преимущество статических типов в том, что вы говорите: они исчерпывающие. Вы можете быть уверены, что все сайты вызовов соответствуют типу, просто позволив компилятору сделать это.
Основное ограничение статических типов состоит в том, что они ограничены в ограничениях, которые они могут выразить. Это зависит от языка: большинство языков имеют относительно простые системы типов (c, java), а другие - чрезвычайно мощные системы типов (haskell, cayenne).
Из-за этого ограничения типов самих по себе недостаточно. Например, в java типы более или менее ограничены проверкой совпадения имен типов. Это означает, что значение любого ограничения, которое вы хотите проверить, должно быть закодировано в какую-то схему именования, отсюда и множество косвенных указаний и шаблонов, общих для кода Java. C ++ немного лучше в том, что шаблоны дают немного больше выразительности, но не приближаются к тому, что вы можете делать с зависимыми типами. Я не уверен, каковы недостатки более мощных систем типов, хотя очевидно, что некоторые или больше людей будут использовать их в промышленности.
Даже если вы используете статическую типизацию, скорее всего, она недостаточно выразительна чтобы проверить все, что вам небезразлично, поэтому вам тоже придется писать тесты. Экономит ли статическая типизация больше усилий, чем требуется при использовании шаблона, - это споры, которые ведутся веками, и я не думаю, что у них есть простой ответ для всех ситуаций.
Что касается вашего второго вопроса:
Как мы можем безопасно повторно использовать типизированный язык среды выполнения?
Ответ - тесты. Ваши тесты должны охватывать все важные случаи. Инструменты могут помочь вам оценить, насколько исчерпывающими являются ваши тесты. Инструменты проверки покрытия позволяют узнать, покрыты ли строки кода тестами или нет. Инструменты мутации тестов (шут, шутка) могут сообщить вам, если ваши тесты логически неполны. Приемочные тесты позволяют узнать, что написанное вами соответствует требованиям, и, наконец, регрессионные тесты и тесты производительности гарантируют, что каждая новая версия продукта сохраняет качество последней.
Одна из замечательных особенностей проведения надлежащего тестирования и использования при обходе сложных типов отладка становится намного проще. При запуске тестов вы получаете определенные неудачные утверждения в тестах, которые четко выражают то, что они делают, а не тупые заявления об ошибках компилятора (подумайте об ошибках шаблона С ++).
Какие бы инструменты вы ни использовали: написание кода, в котором вы уверены, потребует усилий. Скорее всего, это потребует написания множества тестов. Если штраф за ошибки очень высок, например, в аэрокосмическом или медицинском программном обеспечении, вам может потребоваться использовать формальные математические методы для подтверждения поведения вашего программного обеспечения, что делает такую разработку чрезвычайно дорогой.
Я бы сказал, что рефакторинг выходит за рамки того, что компилятор может проверить, даже в статически типизированных языках. Рефакторинг - это просто изменение внутренней структуры программы без влияния на внешнее поведение. Даже в динамических языках есть вещи, которые вы можете ожидать и протестировать, вы просто потеряете небольшую помощь со стороны компилятора.
Я полностью согласен с вашим мнением. Именно гибкость, которой должны быть хороши языки с динамической типизацией, на самом деле делает код очень сложным в сопровождении. В самом деле, существует ли такая вещь, как программа, которая продолжает работать, если типы данных изменяются нетривиальным образом без фактического изменения кода?
Между тем, вы можете проверить тип передаваемой переменной, и как-то потерпеть неудачу, если это не ожидаемый тип. Вам все равно придется запускать свой код, чтобы искоренить эти случаи, но, по крайней мере, что-то вам скажет.
Я думаю, что внутренние инструменты Google действительно выполняют компиляцию и, вероятно, проверку типов в своем Javascript. Хотел бы я иметь эти инструменты.
Начнем с того, что я программист на Perl, поэтому, с одной стороны, я никогда не программировал с использованием сети статических типов. OTOH Я никогда не программировал с ними, поэтому не могу говорить об их преимуществах. Я могу сказать, каково это - рефакторинг.
Я не считаю отсутствие статических типов проблемой при рефакторинге. Я считаю проблемой отсутствие рефакторинга браузера . Проблема динамических языков состоит в том, что вы не знаете, что код действительно будет делать, пока вы его не запустите. В Perl этого больше, чем у большинства. У Perl есть дополнительная проблема, связанная с очень сложным, почти неразборчивым синтаксисом. Результат: никаких инструментов рефакторинга (хотя над этим работают очень быстро ). В конечном итоге мне нужно провести рефакторинг вручную. И вот что приводит к ошибкам.
У меня есть тесты, чтобы их поймать ... обычно. Я действительно часто оказываюсь перед кипящей грудой непроверенного и почти непроверенного кода с проблемой курицы / яйца, связанной с необходимостью рефакторинга кода, чтобы проверить его, но с необходимостью тестирования, чтобы рефакторинг. Ик. На этом этапе я должен написать несколько очень тупых, высокоуровневых тестов типа "выводит ли программа то же, что и раньше", чтобы убедиться, что я что-то не сломал.
Статические типы, как это предусмотрено в Java или C ++ или C # действительно решают лишь небольшой класс проблем программирования. Они гарантируют, что в ваши интерфейсы передаются биты данных с правильной меткой. Но то, что вы получаете Collection, не означает, что Collection содержит данные, которые, как вы думаете, содержат. То, что вы получили целое число, не означает, что вы получили правильное целое число. Ваш метод принимает объект User, но зарегистрирован ли этот пользователь?
Классический пример: public static double sqrt (double a) - это подпись для функции квадратного корня Java . Квадратный корень не работает с отрицательными числами. Где это написано в подписи? Это не так. Хуже того, где говорится, что эта функция вообще делает? Подпись только говорит, какие типы она принимает и что возвращает. Он ничего не говорит о том, что происходит между ними и где живет интересный код. Некоторые люди пытались захватить полный API, используя дизайн по контракту , который в широком смысле можно описать как встраивание тестов времени выполнения для входных и выходных данных вашей функции и побочных эффектов (или их отсутствия) ... но это еще одно шоу.
API - это гораздо больше, чем просто сигнатуры функций (если бы это было не так, вы бы не мне нужна вся эта описательная проза в документации Javadocs), а рефакторинг - это гораздо больше, чем просто изменение API.
Самое большое преимущество рефакторинга, которое дает вам статически типизированный, статически скомпилированный, нединамический язык, - это возможность писать инструменты рефакторинга для делать за вас довольно сложные рефакторинги, потому что он знает, где находятся все вызовы ваших методов. Я очень завидую IntelliJ IDEA .
Одно из преимуществ использования var в C # 3.0 состоит в том, что вы можете часто изменять тип без нарушения кода. Тип должен по-прежнему выглядеть одинаково - свойства с одинаковыми именами должны существовать, методы с такой же или похожей сигнатурой должны существовать. Но вы действительно можете перейти на совершенно другой тип, даже не используя что-то вроде ReSharper.