среда, 17 июня 2015 г.

Методы, принимающие на вход Object

Возможно я буду уже 1000-ным (или 10000-ным) человеком, который это говорит, но я всё же повторю ещё раз.

Методы, у которых есть аргументы типа Object – это полнейший пиздец.

Примеры таких методов:
  • Object.equals(Object)
  • Objects.equals(Object, Object)
  • Collection.contains(Object)
  • Collection.remove(Object)
  • Map.containsKey(Object)
  • Map.containsValue(Object)
Почему это лютейший пиздец, я поясню на примере. Допустим, у вас в программе есть переменная типа Set<Integer> и где-то в коде есть проверка:
Integer x = ...;
if (set.contains(x)) {
  // Do something
}
Теперь в один прекрасный день вам нужно поменять тип множества, скажем, на Set<String>. Вы меняете, и... код компилируется! Но проверка теперь работает некорректно, т.к. вы проверяете, содержит ли ваше множество число, что всегда будет возвращать false. Вы сделали фатальную ошибку в программе, но компилятор вас об этом не предупредил!
Так жить нельзя. Java – это пример статического языка, который не является типобезопасным. Статически типизированный и нетипобезопасный язык – что это если не пиздец?
Есть ли решение у этой проблемы? Ну не знаю, equals(Object) навсегда вшит во все объекты. Так будет в Java 9, 10, 11 и в 20. Поменять сигнатуру метода невозможно, т.к. это нарушит обратную совместимость. Можно использовать typeclass-подход, который используется в functionaljava, но разве кто-нибудь так будет делать?
Остаётся надеяться на IDE и статические анализаторы, хотя это частичное решение, не полное.