Click here to Skip to main content
15,922,007 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hello,

I'm not sure if this is the right place to post, but given that I am coding in C# I thought I'd give it a go. I have a list of contacts, each of which must exist on there own, but could also have other optional behaviour. I've established the base class should be a pure contact class that has name, list of addresses etc. Each of these contacts could then be a tenant, a guarantor, a landlord etc, each of which has different behaviours. I thought either a Decorator or Visitor pattern would be appropriate, however they seem to alter behaviour defined on the base class (i.e. Contact) rather than adding new behaviour. Can anyone advise on whether I'm going in the right direction, or point me in the right direction.

I know its odd on here, but please don't give the direct implementation as I want to actually learn how to do this properly rather than getting it given on a plate!

Thanks
Posted
Comments
John C Rayan 16-Mar-15 9:23am    
How do you mean by "alter behaviour defined in the base class". To me Visitor class is better for you. If you want a behaviour unaltered in your base class then you don't have to override it in the derived classes.
Sergey Alexandrovich Kryukov 16-Mar-15 9:37am    
True. I would not advise any pattern before it is clearly decided and explained. Another important factor is the set of roles. Is is fixed during runtime or not? It can be a fixed set of classes coded in each version of the software, or it can come from data (configuration, settings...).
—SA
Simon Davidson 16-Mar-15 9:40am    
The roles would be defined at compile time. I think you're right, I'm overcomplicating it, and a fixed set of subclasses would do just fine.
Sergey Alexandrovich Kryukov 16-Mar-15 10:26am    
Then make them derived classes and just use OOP.
The alternative is to model those classes as data. First step I do in such consideration is: to classify entities (in fact, knowledge) into code-like and data-like. Data-like behavior can be more convenient to model instead of hard-coding. Then you would use some fewer universal classes (say, one) instead of all the semantic ones.
—SA
Simon Davidson 16-Mar-15 9:39am    
OK, so I'm thinking the base contact class would have methods like, addAddress, addEmail, which would be common among all subclasses. The next simple step would be to subclass for things like Tenant, which would add methods such as addRentalAgreement. Other types of contacts could add different behaviour, but I don't want to have ContactWithTenancy, ContactWithTenancyAndGuarantor etc.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900