- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
public object Clone()
{
using (MemoryStream stream = new MemoryStream())
{
BinaryFormatter formatter = new BinaryFormatter();
formatter.Serialize(stream, this);
stream.Position = 0;
ColLink result = (ColLink)formatter.Deserialize(stream);
result.Id = IdentityManager.GetId();
result.GUID = Guid.NewGuid();
result.setEdited();
result.setCreated();
return result;
}
}
Ну и расширить ещё:
А для того чтобы не загружать сеть направить его через loopback.
Именно этот код следует публиковать как ГК.
В противном случае если-бы он делал полный клон, то его стоило-бы назвать DeepClone.
А полный клон, ага, лучше делать через бинарную сериализацию.
В таком случае хоть код и будет красивый, но вот с производительностью будет не очень...
Соответственно, если копировать по полям, то можно пропустить исключение валидации в пропертях.
Ну и лучше чем:
И так ещё 100500 свойств...
Клонирование оно и есть клонирование.
Для поверхностного копирования (shallow copy) есть специальный метод - MemberwiseClone. А все велосипеды идут на юх.
Все велосипедисты идут читать документацию.
Кстати, бинарная сериализация жутко тормозит на этапе десериализации. На больших графах получалось даже, что сериализаторы WCF начинали выигрывать, если складывать время выполнения пары операций.
Ну, можно вязть на примере (живом):
Есть некое звено, которое использует источник данных:
Данные используются на других узлах. Затем, другая комманда сказала:
- Мы себе тоже хотим себе такие данные при определённом событии.
Замечательно, другая комманда написала сервис:
Если делать так:
То при добавлении пропертей в InputData и/или в OutputData мы получим 3 места за которым придётся следить ручками (входящий набор, исходящий набор и копирование).
Теперь вопрос: А оно надо? :)
ОП - нуп. Плюсаторы - ламеры.
Чет такое про яву читал. Только в фитоне у лохов deepcopy() есть.