12.5 Заключение

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

Иногда эта упрощённая модель очень ценна, но иногда она кажется излишней.

Можно выделить два недостатка данной модели:(1) Несомненно, придётся заплатить за дополнительное управление памятью потерей производительности (хотя эта потеря незначительна), и всегда остаётся некоторый фактор неопределенности относительно времени выполнения программы (так как сборщик мусора может быть принужден действовать, когда памяти становится недостаточно). Для большинства приложений преимущества превышают недостатки, и некоторые части, требующие строгого контроля времени, могут быть реализованы с помощью native методов (см. Приложение А).(2) Обработка псевдонимов: иногда случайно получается две ссылки на один и тот же объект. Проблема возникает только тогда, когда обе ссылки предполагают доступ к одному "определенному" объекту. Эта проблема должна быть должным образом учтена, и следует стараться "клонировать" объект, чтобы предотвратить нежелательные изменения другого псевдонима. Кроме того, можно рассмотреть возможность создания "неизменяемых" объектов, которые могут вернуть новый объект того же типа или другого типа, что повышает эффективность выполнения программы. Но никогда не следует менять исходный объект таким образом, чтобы изменения были незаметны для других псевдонимов. Некоторые считают, что клонирование в Java — это нелепое занятие, поэтому они реализуют свои схемы клонирования (замечание ⑤), полностью отказываясь от вызова метода Object.clone(). Это позволяет избежать необходимости реализации интерфейса Cloneable и захвата исключения CloneNotSupportedException. Такой подход является обоснованным, а также безопасным, учитывая, что метод clone() мало используется в стандартной библиотеке Java. Таким образом, если вы не используете Object.clone(), вам не требуется реализовывать Cloneable или ловить исключение, что делает этот подход приемлемым.⑤: Дуг Лиа особенно отметил этот вопрос и порекомендовал мне использовать данный метод, сказав, что достаточно создать функцию с названием duplicate() для каждого класса.Один интересный ключевой слово в Java — это byValue, которое относится к тем "сохранённым, но ещё не реализованным" ключевым словам. После понимания проблем с псевдонимами и клонированием можно представить, как byValue может быть использовано в будущем Java для автоматического создания локальных копий. Это поможет решить более сложные проблемы с клонированием и сделать код в таких случаях проще и надёжнее.