Почему Cloneable Java является Интерфейсом, Не Универсальным?
4 ответа
Интерфейс Cloneable не содержит участников. Какова была бы точка создания его универсальный?
(Если бы Cloneable содержал клон () метод, это имело бы смысл - но это объявляется в java.lang. Объект.)
РЕДАКТИРОВАНИЕ: клон () находится в java.lang. Объект, поскольку это имеет реализацию (который делает копию поля полем). Лучший дизайн должен был бы иметь что-то как.NET MemberwiseClone () как защищенный метод в Объекте и затем общедоступный клон () метод в самом интерфейсе. Я не знаю, почему тот дизайн не был выбран.
(В.NET, ICloneable не универсален, потому что это существовало перед дженериками - различная природа дженериков.NET препятствует тому, чтобы ранее неуниверсальный тип стал универсальным.)
И в Java и в.NET, однако, "нормальное" клонирование API обычно рассматривается как плохая вещь, поскольку это ничего не говорит о том, какая глубина клонирования должна быть выполнена.
java.lang.Cloneable интерфейс маркера. Это только для цели так, чтобы Object.clone мог выдать исключение, чтобы сигнализировать, что класс не поддерживает клонирование при помощи, например
if(!(this instanceof Cloneable))
throw...;
Из документации:
клон метода для объекта класса выполняет определенную операцию клонирования. Во-первых, если класс этого объекта не реализует интерфейс Cloneable, то CloneNotSupportedException брошен.
Это не имеет никаких методов. При создании этого дженерик не будет никакого использования.
Это не рассматривает Ваш теоретический вопрос, но обрабатывает практический случай:
Java 5 имеет ковариантные возвращаемые значения и позволяет расширять доступ методов. Таким образом, Вы свободны изменить подпись для клона () соответственно в подклассах.
public class MyClass implements Cloneable {
public MyClass clone(){ /* do the right stuff */ }
}
MyClass.clone() корректное переопределение Object.clone(), и Вы не должны будете писать броскам.
Как полусвязанный вопрос для размышления: был бы, создавая интерфейс (назовите его ReallyCloneable), который выставляет клон () как общедоступный участник быть полезным?
Моя конкуренция - то, что не, это не было бы. Clonability глубоко связан с реализацией реального класса. Я не могу думать о единственном варианте использования, где я, вероятно, скажу, что "У меня есть произвольный объект, и я хочу копию его". Непосредственный вопрос был бы: почему Вы хотите ту копию?
И типичный ответ то, так, чтобы можно было изменить копию, не влияя на оригинал. Однако, чтобы сделать это необходимо ли знать, какой объект Вы держите, иначе как Вы знали бы, что звонить для изменения его? И если Вы знаете, что, будете знать, обеспечивает ли это общедоступный клон () метод.
, Но что, если Вы программируете к интерфейсу, такому как Список? Интеллектуальное (рекурсивное) клонирование (по сравнению с копией данных объектов уровня байта) было бы невероятно полезно с платформой Наборов. Но могут быть наборы (такие как поддержанные базой данных), который не может поддерживать такую операцию, таким образом, Вы не можете потребовать, чтобы Список выставил общедоступный клон (). Который управляет Вами к инстанцированию Вашей собственной конкретной Реализации списка для копирования содержания исходного Списка.