Customer : Entity와 같은 자체 참조 일반 상속을 사용해야합니까? <Customer>

Question

자체 참조 일반 상속을 사용하는 것이 좋습니다?

public abstract class Entity<T> { 
    public Guid Id {get; set;} 
    public int Version {get; set;} 

    public T Clone() { 
     ... 
     // clone routine 
     ... 
     return T; 
    } 
} 

public class Customer : Entity<Customer> { 
    public string CustomerName {get; set;} 
    ... 
} 

어떻게 고객을 기본 Entity 클래스로 변환합니까? "고객 : 법인"은 어떤 이점을 제공합니까? NHibernate 도메인 모델링을 보여주는 예제에서 이런 종류의 상속을 봅니다.

"고객 : 엔티티"를 제네릭없이 사용하는 것이 더 좋습니까?

Answer 1

필요할 때 사용할 수 있기 때문에 필요할 때 사용해야합니다. 위의 예에서는 Clone()을 구현하는 것이 좋습니다. 그러나 올바르게 지적하면 엔티티 클래스는 실제로 공통 기본 클래스를 가지지 않을 것이며 엔티티 클래스에 실제로 공통된 속성에 액세스 할 수 없다는 것을 의미합니다. 이 처리하는 올바른 방법은 일반 및 제네릭이 아닌 부분을 분할하는 것입니다

public abstract class Entity { 
    public Guid Id {get; set;} 
    public int Version {get; set;} 
} 

public abstract class Entity<T> : Entity where T : Entity<T> { 
    public T Clone() { 
     ... 
     // clone routine 
     ... 
     return T; 
    } 
} 

을 또한, 나는 Entity<T>의 선언에 추가 한 where 부분을 참고 -이 클래스 만 사용할 수 있도록 보장 이 재귀 패턴의 일부로

Answer 2

내가 일하는 회사에서 일하는 프로젝트는 이런 종류의 트릭을 많이 사용합니다. 사실 코드에서 패턴으로 승격되기도합니다. 따라서 나는 경험에서 말할 수있다 : 그것을 사용하지 말라.

자기 참조 구현이 훨씬 간단하고 효율적이며 읽기 쉬울 수 있지만 이러한 경우는 발생하지 않았습니다. 이를 많이 사용하면 코드 관리가 악몽이되며 대부분의 경우 정상적인 상속과 필요한 경우 메서드 결과의 형 변환만으로 피할 수 있습니다. 파생 클래스에 대한 캐스팅의 성능 비용은 코드 유지 관리 비용에 비해 무시할 수 있습니다.

그래서 자체 참조 일반 상속을 사용하는 것이 바람직한 희귀 예제를 찾으면 계속 진행하십시오. 그러나 아마 그것을하는 더 좋은 방법이 있기 때문에 두 번 미리 생각하십시오.