Ok, I'm on the verge of overthinking this. Is there a way to combine interfaces and attributes such that an attributed property in the implementing class fulfills the interface contract?
In my app I'd like to show a list of activities, which is an aggregation of events in the system such as a new message, a new task being created/assigned/updated, etc. It's just a quick hand list of what's been going on.
I thought about using an IIsActivity interface to flag entities that need to be a part of this aggregation. I really only need to show an activity title, the date it occurred, and link to the relevant area in the application. I don't want to enforce additional properties in the inheriting classes that simply end up duplicating information though. For example, a Task has an AssignedOn (DateTime), and a Message has a CreatedOn (DateTime). Both of this would fulfill the date requirement to be considered an Activity. What I don't want is a separate property just for the activity date. Same thing can go for the title (Message has a Title property, Task has a Name property).
So, I basically want to be able to say, "Get me anything this is an IIsActivity. Within each of those implementors, I expect there to be a property marked with an ActivityTitle attribute, and one with an ActivityDate attribute."
Too much?