2011-11-20 2 views
7

필자는 날짜 필드를 포함하고 추적을 통해 수정 된 많은 Azure 클래스를 보유하고 있습니다. 다음 내 데이터 클래스에 대한상속 된 클래스를 단순화하는 유효한 방법입니까?

public class TableServiceEntityRowInfo : TableServiceEntity 
{ 
    [DisplayName("Created By")] 
    public string CreatedBy { get; set; } 
    [DisplayName("Modified By")] 
    public string ModifiedBy { get; set; } 
} 

대신 그들을 TableServiceEntity I에서 상속 갖는 등 필드 :이 이러한 등을 포함하는 클래스를 만드는 것을 고려 그래서

[DisplayName("Created By")] 
public string CreatedBy { get; set; } 
[DisplayName("Modified By")] 
public string ModifiedBy { get; set; } 

나는 반복을 피하려고

public class MyClass : TableServiceEntityRowInfo 
{ 

} 

필드에 정보를 추가하는 것은 유효하고 합리적인 방법입니다. 제가 여기서 요구하는 이유는 많은 수업을 듣기 위해이 일을 계획하고 있기 때문에 제가 옳은 일을하고 있는지 확인하기 위해서입니다.

+0

나는 100 세가 아니지만 일반적으로 부모의 클래스가 "IS A"인 경우 상속을 시도합니다. 귀하의 경우에는 "HAS A"처럼 들릴 수 있습니다.이 경우 관련 속성을 별도의 클래스로 그룹화하고 해당 기능을 필요로하는 클래스에 해당 속성을 표시 할 수 있습니다. MyClass에는 ModifiedBy, CreatedBy 속성이 포함 된 EntityRowInfo라는 속성이 있습니다. – dreza

답변

8

예, 유효하고 현명한 내용입니다.

하늘빛 특정 관심사가있는 경우, 나는 그것에 대해 말할 수 없습니다.

"IS A"vs "HAS A"에 대한 의견은 여기에서 무시해도 안전하다고 생각합니다. 정말, 그것은 거의 스타일을 명명하기 위해 온다. 기본 클래스 이름이 TableServiceEntityRowInfo 인 이유는 TableServiceEntity이고 행 정보입니다. 감사 할 필드가 있기 때문에 AuditableTableServiceEntity 대신 호출하면 어떻게 될까요? 이제는 정확히 동일하지만 상속 클래스 인 각각 "IS A"AuditableTableServiceEntity이라고 주장 할 수 있습니다.

abstract으로 기본 클래스를 표시하면 인스턴스화하면 안되며 상속 될 수 있음을 명확히 할 수 있습니다.

+0

나는 명명법을 아주 좋아하고 추상적에 대한 논평을 좋아합니다. 고마워. –

+0

클래스가 상속하는 TableServiceEntity가 RowKey, PartitionKey 및 Timestamp 속성이있는 매우 기본적인 클래스이므로 Azure에서 정상적으로 작동합니다. – knightpfhor