ICloneable против сильно типизированной функции против ленивости - PullRequest
2 голосов
/ 10 сентября 2010

Привет, ребята. Мне нужно глубоко клонировать некоторые пользовательские объекты, которые ссылаются на другие пользовательские объекты, и они могут ссылаться на другие объекты ... и так далее, вы поймете идею.

Я просто в документации и концепциисцена на данный момент, так что не поймите это правильно.

Q1.Зачем реализовывать ICloneable и возвращать объект, когда можно написать строго типизированную пользовательскую функцию, которая возвращает клонированный правильный тип объекта?

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

Любые мысли, мнения и размышления приветствуются.

Ответы [ 3 ]

1 голос
/ 10 сентября 2010

См. 536349 по причинам, не позволяющим реализовать ICloneable; в основном вы можете определить свой собственный (строго типизированный) интерфейс и использовать его, я не вижу никаких проблем с ним, если он правильно документирует, что создает глубокие копии.

0 голосов
/ 17 октября 2010

Наличие интерфейса для указания того, что объект является клонируемым, может быть полезным, если набор производных типов включает клонируемые и не клонируемые версии. Если возможно, что производные типа могут не поддерживать клонирование, методы клонирования этого типа должны быть защищены; клонируемая версия типа должна быть получена из него, но другие типы должны быть производными от не клонируемых версий.

Например, можно иметь виджет типа с производными типами, включая CloneableWidget и SuperWidget (который не может быть клонирован). SuperWidget может иметь производный тип CloneableSuperWidget (наряду с некоторыми другими, которые могут быть повреждены при клонировании). Если кто-то хочет работать со всеми клонируемыми производными типа Widget, он должен проверить, что объект является производным от Widget и что он клонируемый. Добавление iCloneable к клонируемым производным позволит проверить такой объект.

0 голосов
/ 17 октября 2010

Цель интерфейса - позволить людям оперировать объектами, которые поддерживают интерфейс, не беспокоясь о том, что это за объекты на самом деле. Не зная, что iCloneable.Clone на самом деле собирается делать с любым конкретным объектом, просто знать, что объект поддерживает iCloneable, довольно бесполезно.

Было бы полезно, чтобы типы коллекций имели защищенный метод BaseClone, и чтобы у них был производный тип, который сделал бы его общедоступным (выполнение таких действий позволило бы получать клонируемые и неклонируемые типы из коллекций ). Имея что-то вроде словаря, поддерживающего метод Clone, было бы лучше, чем включать конструктор копирования, поскольку аргументом конструктора копирования мог быть тип, производный от Dictionary, но существенно отличающийся внутри.

Чтобы интерфейс клонирования был полезен, он должен включать свойство, с помощью которого элементы могли бы сказать, что они думают о клонировании (например, -1 - тип является неизменным и не нуждается в клонировании; -2 - клонирование типа скорее всего сломает его; тип поддерживает «клонирование» и определит, что операция DeepClone проверит все объекты, чтобы убедиться, что они не против клонирования, и в этом случае клонирует все вложенные изменяемые объекты. К сожалению, ничего подобного не существует в рамках.

...