I say a decorator pattern will be useful since a person that will be employed can have additional skills other than c# and Sql-server as time goes...
I'd disagree. it's clear from the initial specification that a potential employee will have a collection of skills, so the initial design should reflect that, and there's absolutely no value in having a Decorator for that.
What is likely to change is that different employers might have different ways of evaluating the skills, weighting some over others. In which case there is a possible argument for using the Strategy pattern. And of course, when using the Strategy pattern
there is a distinct possibility that you will use the Decorator pattern to wrap/chain the different strategies.
But what you should argue with your teacher (I guess this is a homework example, or possibly an interview question) is that applying any patterns at this point is just overcomplicating the system. You're anticipating possible changes in the future, and so
it would make no sense in V1 to do any more than the bare minimum. Adding a ton of potential extensibility points, unless clearly required in the spec, is a waste of time and resource. If and when change is required, you can refactor to patterns depending
on the change.
Remember, if you add "patterns" to code, it increases complexity (in general) and you have to be able to justify that. Not only that, you have to test it and prove the design, which means coming up with concrete examples. So Patterns generally only make
sense either when you're deliberately setting out to write extensible code, or when the first change comes along.
DMW
All-Star
15943 Points
2353 Posts
Re: Using decorator pattern
Mar 15, 2012 02:25 PM|LINK
I'd disagree. it's clear from the initial specification that a potential employee will have a collection of skills, so the initial design should reflect that, and there's absolutely no value in having a Decorator for that.
What is likely to change is that different employers might have different ways of evaluating the skills, weighting some over others. In which case there is a possible argument for using the Strategy pattern. And of course, when using the Strategy pattern there is a distinct possibility that you will use the Decorator pattern to wrap/chain the different strategies.
But what you should argue with your teacher (I guess this is a homework example, or possibly an interview question) is that applying any patterns at this point is just overcomplicating the system. You're anticipating possible changes in the future, and so it would make no sense in V1 to do any more than the bare minimum. Adding a ton of potential extensibility points, unless clearly required in the spec, is a waste of time and resource. If and when change is required, you can refactor to patterns depending on the change.
Remember, if you add "patterns" to code, it increases complexity (in general) and you have to be able to justify that. Not only that, you have to test it and prove the design, which means coming up with concrete examples. So Patterns generally only make sense either when you're deliberately setting out to write extensible code, or when the first change comes along.
Dave