Глубоко клонируйте служебную [закрытую] рекомендацию

Все подходы для копирования объектов в Java имеют серьезные дефекты:

Клон

1. клон () метод защищен, таким образом, Вы не можете назвать его непосредственно, если рассматриваемый класс не переопределяет его с открытым методом.
2. клон () не вызывает конструктора. Любой конструктор. Это выделит память, присвоит внутреннее class поле (который можно считать через getClass()), и скопируйте поля оригинала.

Для большего количества проблем с клоном (), посмотрите объект 11 из книги Joshua Bloch" Эффективный Java, Второй Выпуск "

Сериализирует

, Сериализируют, еще хуже; это имеет многие дефекты clone() и затем некоторые. У Joshua есть целая глава с четырьмя объектами для одной только этой темы.

Мое Решение

, которое Мое решение, добавляет новый интерфейс к моим проектам:

public interface Copyable<T> {
    T copy ();
    T createForCopy ();
    void copyTo (T dest);
}

код похож на это:

class Demo implements Copyable<Demo> {
    public Demo copy () {
        Demo copy = createForCopy ();
        copyTo (copy);
        return copy;
    }
    public Demo createForCopy () {
        return new Demo ();
    }
    public void copyTo (Demo dest)
        super.copyTo (dest);
        ...copy fields of Demo here...
    }
}

, К сожалению, я должен скопировать этот код во все свои объекты, но это всегда - тот же код, таким образом, я могу использовать редактора Eclipse шаблон. Преимущества:

1. я могу решить, какого конструктора назвать и как инициализировать который поле.
2. Инициализация, оказывается, в детерминированном порядке (корневой класс инстанцирует класс)
3. , я могу снова использовать существующие объекты и перезаписать их
4. Безопасный с точки зрения типов
5. , Одиночные элементы остаются одиночные элементы

Для стандартных типов Java (как наборы, и т.д.), я использую служебный класс, который может скопировать их. Методы имеют флаги и обратные вызовы, таким образом, я могу управлять, как глубоко копия должна быть.

Один общий путь к глубокому клону произвольный набор должен сериализировать его к потоку, затем считать его назад в новый набор. Вы будете повторно гидратировать абсолютно новые объекты, которые не имеют никаких отношений к старым кроме того, чтобы быть идентичными копиями.

Выезд ответ Bruno для ссылки на Apache классы утилиты сериализации палаты общин , который будет очень полезен, если это будет маршрутом, Вы решаете взять.

Одна возможность состоит в том, чтобы использовать сериализация :

Apache палата общин обеспечивает SerializationUtils

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

Поверхностное клонирование коллекции легко, но если вы хотите глубокое клонирование, библиотека, вероятно, подойдет вам лучше, чем ручное кодирование (поскольку вы хотите клонировать элементы внутри ] коллекцию).

Так же, как этот ответ , я использовал библиотеку Cloner и, в частности, протестировал ее производительность против XStream (который может «клонировать» путем сериализации, затем десериализация) и двоичная сериализация. Хотя XStream очень быстро сериализует в / из xml, Cloner намного быстрее при клонировании:

0,0851 мс: xstream (клонирование путем сериализации / десериализации)
0,0223 мс: двоичная сериализация (клонирование путем сериализации / десериализации)
0,0017 мс: клонер
* среднее время клонирования простого объекта (два поля) без открытого конструктора по умолчанию. Выполнить 10 000 раз.

Помимо скорости, есть еще несколько причин выбрать клонер:

1. выполняет глубокое клонирование любого объекта (даже тех, которые вы не пишете самостоятельно)
2. вам не нужно постоянно обновляйте свой метод clone () каждый раз, когда вы добавляете поле
3. , вы можете клонировать объекты, у которых нет открытого конструктора по умолчанию
4. работает с Spring
5. (оптимизация) не клонирует известно неизменяемые объекты (например, Integer, String и т. д.)

6. просты в использовании. Пример:

   cloner.deepClone (anyObject);

Я создатель библиотеки клонирования, которую представил Брэд. Это решение для клонирования объектов без необходимости писать дополнительный код (нет необходимости в сериализуемых объектах или методе impl clone ())

Это довольно быстро, как сказал Брэд, и недавно я загрузил версию, которая еще быстрее. Обратите внимание, что ручная реализация метода clone () будет быстрее, чем clone lib, но опять же, вам нужно будет написать много кода.

Cloner lib у меня работал довольно хорошо, так как я использую его в реализации кеширования для сайта с очень большой посещаемостью (~ 1 млн запросов / день). Кэш должен клонировать примерно 10 объектов на запрос. Достаточно надежный и стабильный. Но имейте в виду, что клонирование сопряжено с риском. Библиотека может быть настроена для печати каждого экземпляра класса, который она клонирует во время разработки. Таким образом вы можете проверить, клонирует ли он то, что, по вашему мнению, следует клонировать - графы объектов могут быть очень глубокими и содержать ссылки на удивительно большое количество объектов. С помощью clone lib вы можете указать ему не клонировать ненужные вам объекты, то есть одиночные объекты.