Это то, с чем я боролся последние несколько месяцев. У меня были люди, яростно утверждающие, что все, что нужно для строгой типизации, — это ложное утешение и много ненужной типизации. Но я был сильным. Я был не напуган. Я отрицаю это как сумасшедшую суету тех разработчиков JS, тех динамичных языковых людей, которые верят, что запутывание и компактность — это все, даже за счет ремонтопригодности. Я имею в виду, как мог язык, в котором вы даже не знали, что передавалось, каким-либо образом лучше, чем что-то, где API явны и мешают вам делать ошибки. Динамический язык может работать для одного разработчика, но определенно не для команды. Это был весь мой сердечный вывод.
Теперь я не уверен больше. Прошло 3 недели с тех пор, как наша команда сделала весь душевный переход. Это были розы и солнце? Нет. Но все оказалось не так плохо, как я ожидал. И для этого есть несколько причин. Но перед этим я изложу плюсы и минусы так, как я их вижу из своего (несомненно, очень ограниченного) опыта
Преимущества сильного набора текста:
- Ошибки / предупреждения в вашем редакторе
Проще говоря, это может быть просто самым большим преимуществом строгой типизации и единственной причиной, по которой большинство разработчиков Java (что вполне справедливо) никогда даже не решат оставить безопасность строгой типизации. Хотя поддержка компиляции не обязательно идет рука об руку со строгой типизацией, большинство людей склонны ассоциировать с ней Java, поэтому давайте поработаем с этим. Проще говоря, при строгой типизации ваш редактор может (и должен, я имею в виду, если вы не собираетесь получать немедленную обратную связь, какой смысл?) Дать вам немедленную обратную связь, когда вы что-то напутали. Используете ли вы неправильное имя переменной или пытаетесь вызвать метод, который либо не существует, либо с неправильными параметрами. Или если вы пытаетесь использовать неправильный тип объекта.Для разработчика Java среда IDE, такая как Eclipse или IntelliJ, является находкой, поскольку она сообщает вам, что не так в вашем мире, позволяет вам переходить к ним, дает вам предложения и исправления и в целом делает вашу жизнь настолько безболезненной, насколько это возможно. И это замечательно, я могу вам это сказать.
В Javascript (или любом другом динамическом языке) все хорошо и замечательно для первых 100 строк. После этого он становится страшно неуправляемым. Единственный способ обойти это, как я обнаружил, это быть супер параноиком и писать тесты для каждой отдельной строки кода. Если вы не можете этого сделать, держитесь подальше.
- Дженерики (но, на мой взгляд, это также негатив, к которому я вернусь ниже)
Идея дженериков заключается в том, что они дают разработчикам некоторые гарантии относительно типов в коллекции (или что бы вы ни генерировали). Таким образом, все операции являются типобезопасными, без необходимости преобразования в и из различных типов. И вы уверены, что вы не будете удивлены внезапно появлением другого типа объекта, когда вы меньше всего этого ожидаете. Но есть много вопросов, которые я расскажу во втором разделе. - Возможность проследить цепочку и выяснить, какой тип объекта требуется на каждом шаге.
Теперь это то, что я определенно пропускаю в таких языках, как Javascript и Python. Тот факт, что я могу отследить (в моей IDE, обратите внимание на эту часть), какой тип каждой переменной / метода вызывается в цепочке выражений, просто поразителен, особенно когда вы работаете с новой базой кода. Вам никогда не придется задумываться о типах параметров метода, который вы вызываете. Вам не нужно удивляться, какие методы доступны или видимы. Вы просто знаете эту информацию (опять же, если вы используете IDE. Если нет, то бог вам в помощь) - Рефакторинг
Однако, на мой взгляд, самое большое преимущество строгой типизации — это возможность создавать интегрированные среды разработки, которые упрощают рефакторинг. Переименование метода / переменной? Trivial. Перемещение или извлечение метода? Простая комбинация клавиш. Вещи, которые могут быть чрезвычайно утомительными, и онемение ума — за считанные минуты. (Хотите узнать больше об этих ярлыках? Проверьте ярлыки Eclipse). Это просто невозможно с такими языками, как Python и Javascript.
- Более сжатые и точные, менее типизируемые
динамические языки имеют тенденцию быть более плотными, и в 10 строк гораздо легче выполнить то, что может легко занять 50-100 в языке, подобном Java, что особенно многословно. Подумайте о том, чтобы попытаться передать кусок кода, который будет выполнен в конце функции как в Java, так и в JavaScript (это довольно часто встречается в веб-приложениях и исполнителях задач)
Java:
interface Function {
T execute(); // Optional parameters is not easy here 🙁
}
taskRunner.execute(taskArgument, new Function() {
String execute() {
return "Success";
}
});Javascript
taskRunner.execute(params, function() {response="Success"}); -
Нет плохо реализованных дженериков
Это в основном вина Java в том, что дженерики довольно сильно ошибаются. Идея дженериков звучит здраво, ее реализация ужасно нарушена. Вот несколько вещей, которые не подходят для этого:
Стирание типа : в основном это связано с тем фактом, что во время выполнения нет способа провести различие между скажем, List <String> и List <Integer>, если вы никогда не работали с отражением или Да ладно, тогда это может и не быть проблемой. Но это также боль с глубоко вложенными дженериками и подстановочными знаками. Я видел компиляцию кода, который взрывается во время выполнения, потому что он не может различить провайдера <? расширяет репозиторий> и поставщик <? расширяет Resource> и ни Resource, ни Repository не имеют ничего общего. Псих….Детальность : Карта <String, List <String >> myMap = new HashMap <String, List <String >> () ;. Сказал Энуфф.
Guice & Reflection : Дженерики и java.lang.reflect просто не смешиваются. Они просто нет. Стирание типа уничтожает всю информацию о типах, поэтому вы обязательно будете использовать такие вещи, как new Entity <?>, Которая полностью побеждает цель. И не заводите меня на Guice. В общем, нормальные привязки (неуниверсальные классы) выглядят следующим образом:
связывания (MyInterface.class) .toInstance (экземпляр);
При использовании Generics они теперь выглядят следующим образом:
bind (новый TypeLiteral <MyInterface <String >> () {}). toInstance (instance);
Что, черт возьми, только что произошло там ???
- Закрытия / Функции:
Замыкания — это форма анонимных внутренних функций, которые могут иметь собственную среду, включая переменные, связанные с областью действия функции. Внутренняя функция имеет доступ к локальным переменным внешней области видимости и может изменять состояние. Но он позволяет создавать функции, такие как обратные вызовы, или выполнять несколько небольших задач быстро, легко, быстро и довольно дешево. У Явы было несколько предложений по его добавлению (http://javac.info/). но он еще не прошел ревизионную комиссию. И, вероятно, не будет в течение следующих нескольких лет. Так что до тех пор, в Java вы застряли, создавая интерфейсы, создавая его реализацию во время выполнения, передавая переменные, к которым вам нужен доступ, в конструкторе или через какой-то другой механизм, и, как правило, испытывает большие трудности. Спасибо, но нет.