메서드를 상속 ICloneable하고 구현 해야하는 이유를 설명해 주 Clone()시겠습니까?
딥 카피를하고 싶다면 그냥 내 메서드를 구현하면 안 되나요? 말해 보자 MyClone()?
나는 왜 물려 받아야 ICloneable합니까? 장점은 무엇입니까? 코드를 “더 읽기 쉽게”만드는 문제입니까?
답변
해서는 안됩니다. 메서드가 “깊은”복제를 수행 ICloneable하는지 Clone“얕은”복제를 수행 하는지 인터페이스에서 명확한 표시가 없기 때문에 구현 하지 않는 것이 좋습니다 .
자세한 내용 은 2003 (!)의 Brad Abrams의이 블로그 게시물 을 참조하십시오.
답변
ICloneable인터페이스 자체는 그 객체가 그것에 대해 아무것도 모른 채 복제 가능한 것을 알고 있으면 유용 어디 정말 많은 상황이 아니라는 것을 말하고, 이는 매우 유용하지 않습니다. 이것은 예 IEnumerable또는 IDisposable; 와는 매우 다른 상황입니다 . IEnumerable열거하는 방법 외에 다른 것을 알지 못한 채 를 받아들이는 것이 유용한 상황이 많이 있습니다 .
한편, 다른 ICloneable제약과 함께 일반 제약으로 적용될 때 유용 할 수 있습니다. 예를 들어, 기본 클래스는 여러 파생물을 유용하게 지원할 수 있으며, 그중 일부는 유용하게 복제 될 수 있고 일부는 불가능합니다. 기본 유형 자체가 공용 복제 인터페이스를 노출 한 경우 복제 할 수없는 파생 유형은 Liskov 대체 원칙을 위반하게됩니다. 이 문제를 피하는 방법은 기본 유형이 Protected 메서드를 사용하여 복제를 지원하도록하고 파생 유형이 적합하다고 판단되는대로 공용 복제 인터페이스를 구현하도록 허용하는 것입니다.
이 작업이 완료되면 WonderfulBase유형 의 객체를 허용하고 이를 복제 할 수 있어야하는 메서드는 복제를 지원하는 WonderfulBase 객체를 허용하도록 코딩 할 수 있습니다 (기본 유형 및 ICloneable제약 조건이 있는 일반 유형 매개 변수 사용 ). . 있지만 ICloneable인터페이스 자체가 깊은 또는 얕은 복제 표시하지 않을에 대한 문서는 WonderfulBase복제 가능 여부를 나타냅니다 WonderfulBase딥 또는 얕은 복제해야합니다. 기본적으로 ICloneable인터페이스는 ICloneableWonderfulBase복제 가능한 모든 기본 클래스에 대해 다른 이름을 정의 할 필요가 없다는 점을 제외하고를 정의하여 수행 할 수없는 작업을 수행하지 않습니다 .
답변
ICloneable논란이 된 BCL의 인공물 중 하나입니다. IMHO가 그것을 구현할 실제 이유가 없습니다. 그것으로 나는 복제 방법을 만들려고하면 그때는 어떻게 구현합니까 말했다 ICloneable, 나는 내 자신의 강한 입력 된 버전을 제공합니다 Clone.
문제 는 매우 다른 것들 인 얕은 또는 깊은 사본 ICloneable인지 결코 나타내지 않는다는 Clone것입니다. ICloneable<T>ICloneable에 대한 Microsoft의 생각에 대한 징후 가 없다는 사실은
답변
Matt가 맞습니다. 사용하지 마십시오. 고유 한 Copy()메서드 (또는 유사한 이름)를 만들고 메서드가 객체의 딥 사본 또는 얕은 사본을 생성하는지 여부를 공용 API에서 완벽하게 명확하게 합니다.
답변
