I'm struggling to point a finger into the right design pattern.

I have a web site which user can register and interact with the system. I want to add the following abilities to a user:

  1. Each user will be in a stage. Let's say that we have 5 stages. when user is register, he will be in the 1-st stage.

  2. User will be able to climb to the next stage. To do so, he will need to complete X tasks. (There will be 20 tasks in the system).

  3. In each stage, the user will be able to buy benefits with the points that he gain in each task that he completed.

What's the appropriate design pattern to use here?


  • Perhaps you're more interested in which architectural approach to use instead of which design patterns to use? – MetaFight Jul 3 '14 at 10:06
  • any approach will be helpful – lolo Jul 3 '14 at 12:51

"I'm trying to do X, which design pattern should I use?" is usually the wrong question to ask.

A design pattern is a proven solution to a recurring problem, but its value as a pattern lies largely in its name: once you've solved similar requirements in similar ways several times, you can more easily remember the combination of classes and relationships that did the job, and you can more easily communicate the decision to other practitioners who also know the name and the pattern.

But when you don't know what to do for a set of requirements, simply being told the name of a pattern will do almost nothing for you. You will have to follow the details of the situation, understand the pressures involved and why one decision is preferable to another in order to take away any benefit from learning the pattern. It's almost always better to attempt your own solution to understand the trade-offs involved, and then compare your code to the example code given in the pattern literature. Then, either you will have reinvented a pattern - congratulations, you've added a useful tool to your tool kit. Or you might suddenly "see the light" and understand why this other arrangement of classes and methods works better - congratulations, you've acquired a new tool and found a solution to your task. (Or you might find that your own solution actually works better. Double congratulations! You've succeeded better than others, and perhaps you can eventually extend it a new pattern of your own.)

In any case, you usually do better by writing code for your problem and then comparing it to example solutions than by choosing a design pattern and recreating it for your use case simply because it's a well-known pattern. You don't know whether or not a pattern is a good fit for your situation until you've had a go at it and understand what makes it tricky. Immediately seeing "Ah, I need to construct a Bridge for this" only works when you already know both your problem and the design pattern from experience.

So far, you haven't described anything that would require a complicated arrangement of cooperating classes at all. Users can solve tasks and advance through stages, and they can buy benefits. That doesn't sound like anything more complicated than an entity with three attributes, or maybe n:m relations for tasks and benefits. What's giving you trouble so that you think the straightforward implementation won't work?

  • I think that you didn't get to the deepness of the question. It's not a mattgemmell.com/what-have-you-tried question. The answer can be a C&P from other posts... The question is about to get a bigger understanding of the design to use here. And if there is a conceptual design solution. This requirement can raise in each game application that have stages/levels/rounds which the user can buy benefits/rewards/Equipments. – lolo Jul 2 '14 at 9:59
  • 1
    I think I understand what he meant. He meant to say that your question is too specific to your problem that it is not a 'recurring and common' problem, and thus there is no 'design pattern' for it. What he suggests is that you go do it without any 'design pattern' in mind first. – InformedA Jul 2 '14 at 10:37

You can't really decide on a specific design pattern at this stage. Your description is too high level.

To be able to get to deciding on a design pattern you should first construct a doman model which shows the main entities in your system, and associated cardinalities.

From reading your description there are three main entities that jump out :

User, Task, Stage

And to a lesser extent, which may require some clarification :

Point, Benefit

Once you have a domain model (which is basically a UML class model), you can start to analyze interactions, and if you like create some sequence diagrams.

Only after this analysis can you really start to look at whether or not you need a strategy pattern, command pattern, bridge pattern etc etc...


You could be interested in State design pattern, which allows encapsulating varying behavior of an object based on its internal state.

If you're using MVC architectural pattern to build the web application you could think using it in the controller of the web application.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.