Using decorator pattern

Hi guys Check my example below:

CrazyBitz is an employment agency specializing in matching IT staff with specific skill sets to the needs of prospective employers. An employer might need someone with a c# background and SQL-server experience, whore also qualified as a CCNA. They need an application that will automatically evaluate how well the skills of applicants match the needs of employers.

Outline arguing that this IS or IS NOT a suitable problem to address with the aid of the decorator pattern...

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...

What are your personal views about this example?

Re: Using decorator pattern

Anele
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.

Re: Using decorator pattern

DMW
make no sense in V1 to do any more than the bare minimum

Am confused by this line specialy V1. So there wont be any objects such as the skills mayneedto be decorated in future?

Re: Using decorator pattern

Anele
So there wont be any objects such as the skills mayneedto be decorated in future?

Firstly, how would you decorate a skill? it is what it is, a skill.

But let's play a game for a second.

Let's say that in V2 (V1 meant version 1, so V2 is the second version) the client decides that they want to "decorate" the skill, with, say, the length of time that the person has had that skill.

So in V1, the requirement was just "Must be able to code in C#". In version 2, it is "Must have three years experience in C#".

Hmm. Is that a decoration of the skill. I'm not sure that it is. But you could argue that it is a decoration around how we check for the skill.

So if in V1 we had a simple check for "Has skill xxx", we could now decorate that checker with "Has skill for appropriate period of time yyyy".

You will notice that this is what I meant when I said in my previous post

"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."

Now here's the really, really important bit.

You're guessing about what future requirements might be. You don't know. You're guessing.

So, should you in version 1 guess about what might come down the wire in version 2? Or version 3? Or version 4?

Some of the problems with this approach are as follows:

Allowing for future extensibility costs time and money. The business sponsor who wants version 1 might not be prepared to wait or pay for that.
In order to allow for extensibility increases complexity, and that complexity has to be tested and proven at the beginning.
If you guess, and you guess wrong, then you'll have added a ton of complexity to the code for no good reason.

Offsetting this is the fact that if change is an expected part of the requirements, and you intend to put this code into systems, especially those written by other teams where making future changes is difficult, then you might well need to design a system that has additional complexity up front. In essence, this is the challenge facing, say, the ASP.NET team, the WPF team and other teams on the .NET Framework, where they know that their code is going to be used and extended by millions of developers. They try really hard to develop extensiblity points into the code so that they can add new features, such as ASP.NET MVC for example, without having any negative impact on all existing ASP.NET applications.

But that costs BIG bucks to get right (well done the ASP.NET team, btw.)

The real development / design skill here is that you need to design and code just enough, and not more. And then when change happens, and it will, adapt the code in such a way that you can make further similar changes without having to completely re-engineer the code.

Hence, in v1 you probably wouldn't use the decorator pattern (there's no need), but that having a separated strategy makes sense both from a testing and an extensibility perspective; but in v2, when you analyse the changes that exist at the time, you might decide that the best approach is to then use a decorator around the existing matching strategy types.

Apologies for the length of the post, and I hope it helps.

Re: Using decorator pattern

Hehe...lov it,its more clear now. Thanx Dave