Почему стандартные классы иногда имеют, казалось бы, несвязанные методы?

Question

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

Методы, о которых я говорю, это, например, Integer#getInteger, который извлекает значение некоторого «системного свойства» или System#arraycopy, цель которого четко определена его именем. Тем не менее, оба этих метода кажутся кажущимися неуместными, особенно первый, который по какой-то причине связывает работу с системными ресурсами с классом обертки примитивного типа.

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

Спасибо!

Update

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

Answer 1

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

В вашем случае я ожидаю, что ответ будет не слишком удачным. Причина, по которой они были сделаны, трудно сказать. Но оба класса существуют с JDK1.0. В то время качество программирования в целом (а также Java и OO в частности) было, возможно, ниже (что означает, что было меньше распространенных практик, разработчики библиотек должны были изобретать многие парадигмы). Кроме того, в те времена были и другие ограничения, такие как создание Object, являющееся дорогостоящим.

Многие из этих неловко разработанных методов и классов теперь имеют лучшую альтернативу. (См. Date и pacakge java.time) МассивCopy, который вы ожидаете добавить в класс Arrays, но, к сожалению, его там нет.

В идеале первоначальный метод будет устаревать ненадолго, а затем удален. Многие библиотеки следуют этой стратегии. Однако Java очень консервативен в этом отношении и только осуждает то, что действительно не должно использоваться (например, Thread.stop(). Я не думаю, что какой-либо метод когда-либо удалялся на Java из-за устаревания. Это означает, что довольно просто обновить программное обеспечение до более новая версия Java, но это связано с тем, что в библиотеках возникает некоторый беспорядок.

Тот факт, что Java настолько консервативен в отношении сохранения новых версий JDK/JRE, совместимых со старыми исходными кодами и двоичными файлами, любим и ненавидим . Для вашего проекта хобби или небольшого активно развитого проекта, до перехода на новую JVM, которая удаляет устаревшие функции через несколько лет, не является слишком сложной задачей.Но не забывайте, что многие проекты не активно развиваются, или разработчикам нелегко делать изменения безопасно, например, потому что они не имеют надлежащего теста регрессии. В этих проектах изменения в API-интерфейсах стоят много времени, чтобы соответствовать требованиям и запускать риск появления ошибок.

Также библиотеки часто пытаются поддерживать более старые версии Java, а также более новую версию, они будут иметь проблемы с этим, когда методы были удалены.

Answer 2

Целочисленный пример, вероятно, просто дизайнерское решение. Если вы хотите неявно интерпретировать свойство как Integer, используйте java.lang.Integer. В противном случае вам нужно будет предоставить метод getter для каждого java.lang-Type. Что-то вроде:

• System.getPropertyAsBoolean (String)
• System.getPropertyAsByte (String)
• System.getPropertyAsInteger (String) ...

И для каждого типа данных, вы 'd требуется один дополнительный метод для значения по умолчанию: - System.getPropertyAsBoolean (String, boolean) - System.getPropertyAsByte (строка, байт) ...

Так как у java.lang-Types уже есть некоторые способности броска (Integer.valueOf (String)), я не слишком удивлен, обнаружив здесь метод getProperty. Удобство в торговле за нарушение принципов немного.

Для System.arrayCopy, я думаю, это операция, которая зависит от операционной системы. Скорее всего, вы очень быстро копируете память из одного места в другое. Если я хотел бы, чтобы скопировать массив, как это, я бы искать его в java.lang.System

Answer 3

«Я предполагаю, что есть какая-то логика в принятии решения о размещении этих методов именно там, где они есть.»

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

Язык находится в постоянном развитии, со дня, когда кто-то предлагает новый язык в тот момент, когда он устарел. Между этими крайностями есть несколько этапов, которые проходят язык. Особенно, если кто-то тратит на нее деньги и хочет, чтобы люди пользовались им, очень часто возникает очень странная фаза, незадолго до или после первого выпуска:

«нам нужно, чтобы это работало вчера».

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

Итак, где мы можем добавить эту функцию? - ну, где это имеет смысл для конкретного программиста, задача которого - «заставить его работать вчера».

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

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

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