Pattern Design Help!

Question

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 16-Mar-15 3:02am

Simon Davidson

Add a Solution

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.

Sergey Alexandrovich Kryukov 16-Mar-15 9:29am

Wow! Just design your code first and only then think if it can be improved with some pattern. Sticking a pattern into your design is not your primary goal.

There is only one universal pattern: use your brain. Every other one may or may not be considered.
If you answer John's and my questions, we can continue this discussion.

But yes, this is a right place to ask the question.

—SA

John C Rayan 16-Mar-15 9:48am

SA is right, You don't have to use design pattern simply because they are there. They are only guidelines. Most of the time you will be just fine without them.

Chris Ross 2 16-Mar-15 11:15am

I can't say I'm anything like an expert on design patterns (wish I was, but that's another story). You might take a look at http://www.dofactory.com/net/decorator-design-pattern - which classifies the Visitor pattern and Decorator pattern as behavioural and structural, respectively. That may help you choose between them if you go the pattern route.

Principles I find that reliably guide me are cohesiveness and the Single Responsibility Principle - am I putting multiple distinct sets of behaviour into a single class? Which leads into an observation & question that you haven't quite asked for, but may be helpful:

As I look at the ideas you are working with (expressed tentatively as Contact, ContactWithTenancy, etc.) it occurs to me that you've put Contact first and foremost in your design problem (and the business relationship involving that is a secondary aspect of the model). Have you tried inverting that thought pattern? Landlord, Tenant, TenantWithGuarantor are, perhaps, the primary business objects - and contact information is just a property common to all business relationships in your model? If you need to, at times, treat Landlord, etc., as members of a common family, they could all implement an applicable interface.

If you've not yet explored design principles - I find http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 to be a useful starting point.

Rob Philpott 16-Mar-15 11:37am

My 2 cents - design patterns often complicate simple design. Sure they can be helpful, but for me its better to think about what the objects are and their relationships. Patterns then just emerge.

Subramanyam Shankar 16-Mar-15 12:18pm

Instead of directly trying to implement a design pattern code the functionality.You will get a better understanding of what all things can be refactor and what design pattern can be used. So you will be the best judge to use the right design pattern.

Sinisa Hajnal 17-Mar-15 3:31am

If there is small number of (fairly) fixed behaviours, I'd simply inherit contacts class and do whatevers needed for the particular type.

If they have totally different methods (not just different implementations of the same methods) I'd use decorator that could use contacts data (or even change it) for its particular decoration.

Not enough details to commit either way. Solve your problem first, then see if you can pretty it up :)

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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