Is this a legitimate way to simplify my inherited classes?

I have many Azure classes containing date fields and modified by tracking. Fields such as:

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

I want to avoid repetition, so I was thinking about creating a class that would contain them, for example:

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

For my data classes, instead of inheriting from TableServiceEntity, I would like to set them as follows:

 public class MyClass : TableServiceEntityRowInfo { } 

Is this the right and reasonable way to add additional information to the fields. The reason I ask here is because I plan to do this for many classes, and I want me to do the right thing.

+7
source share
1 answer

Yes, that’s really and wisely.

If there is any problem with Azure, I can't talk about it.

Regarding the commentary on "IS A" and "HAS A", I think that you can safely ignore it. In fact, it almost comes down to the name of the style. You named your base class TableServiceEntityRowInfo because it is a TableServiceEntity that contains TableServiceEntity information. What if you name it instead of AuditableTableServiceEntity because it has fields for auditing. Now this is exactly the same, but you can claim that each of the inheriting classes "IS A" AuditableTableServiceEntity .

You can also mark your base class as abstract , to make it clear that it should not be created, only inherited.

+8
source

All Articles