I have some classes like so
class User{
Preferences
List<Participants>
BlueFontParticipants
PropertyThatComputesFromAListOfParticipants<Participants>
}
class Preferences{
PrefersBlueFont //really only applicable if you have a bluefontparticipant
PlayAudioAutomatically //only applicable if you have a audioparticipant
}
class BlueFontParticipants: IList<BlueFontParticipant>{
PropertyThatNeedsAListToCompute
}
class BlueFontParticipant{
CommonParticipantProperty
BlueFontSpecificProperty
}
class AudioParticipant{
CommonParticipantProperty
AudioSpecificProperty
}
I split preferences and participants up weird to compare and contrast. You could also do a list of preferences and split them up based on that.
I have a user who will login and will get a list of participants attached (potentially none) and what type of participant gets added to that list depends on if they meet certain conditions. I could have done something similar for notification but wanted to show another option of doing this which is just directly added the unique properties for each type. So if you have a BlueFontParticipant the BlueFontPreference is going to be used.
If one or more BlueFontParticipant gets added you are going to want to use the PropertyThatNeedsAListToCompute BlueFontParticipants. The audio participant is used to show that you could have n amount of participant types but they always have this same property in common.
I need the list of Participants but I also want the list BlueFontParticipants and potentially n amount of participant types.
Is it good design to have a class like this?
class User{
Preferences
List<Participants>
BlueFontParticipants //seems like I need to filter by typeof and create this list
}
Where list of participant is a property and each added participant type will more than likely require another property to be added?
So for audio participants
class User{
Preferences
List<Participants>
BlueFontParticipants
AudioParticipants
NewParticipantListType
}