I am fairly new to using patterns and although I understand some of them to a point I find it difficult to work out which one(s) to use in a particular situation.

I am trying to wrap up an existing db schema into a number of objects and am not sure if I should simply be using inheritance or a mixture some patterns

I have an options table, holding the base properties for an item thus:


These options also has availability - stored in another table

id (from option table)

and prices in another table

id (from option table)

and lastly a booked table this time keyed on the option id and the person who has booked it

id (from option table)

Just to add more into the mix, there are also a couple of particular option types which have additional properties that are unique to them. Thinking maybe I should use inheritance for the most part - as the price/availability bits are used for ALL option types and then decorate the unique options with these extra bits in those particular cases.

So in different circumstances this data will need to be loaded into various objects I wonder if its best to inherit from the base option - making an AvailabilityOption and a PricedOption etc and extending the base option like that or decorating the base option with the extended properties.

Not sure if there is enough information here to answer that. I wonder if someone could explain the benefits and pitfalls of each so I don't end up getting myself into a cul de sac?


Never use a pattern when you are unsure whether to use it.

Design patterns are codifications of things that advanced practitioners have done often, and finally published under a canonical name. They are often useful to solve a recurring problem, but only if that is in fact the problem you are having. If you're not sure whether that is the case, implementing a pattern increases the difficulty of your work, because in addition to getting the details of your requirements right, you also have to get the details of the pattern right.

Applying pattern can make work easier, but in my opinion that only happens when you have already understood the pattern (not necessarily as well as its author, but certainly well enough that you could recreate the published description of problem/forces/solution/class structure etc. without having to look it up). Usually this is because you have also solved or at least encountered the same problem as the original author before. Then, when you read the pattern description and realise that it solves exactly the problem you're having, it is relatively easy to apply it, and (in my opinion) it then becomes quite easy to recognize other problems that call for exactly this pattern.

In other words, I think profiting from patters requires that you go through the same process of learning by doing, recognizing and mentally "bundling" the solution into a recognizable element of your thinking as the inventor did. Simply copying a class structure from a book and calling it a "Bridge" or whatever has little value except as quick documentation for others who will read your code.

  • thanks for the reply, so get reading basically you are saying? I would like to use them more so I can save re-inventing the wheel (badly I expect) – nat Dec 18 '13 at 10:35
  • I think it's almost always better to learn the pattern you need for your work right now and learn it well than reading an entire book and get passing knowledge of two dozen patterns by forcing yourself to do exercises. For this problem, inheritance seems like a good choice - maybe no patterns are required at all! Representing related classes in a db can be tricky, but that's a question of what your ORM can do for you and probably not design-pattern related. – Kilian Foth Dec 18 '13 at 10:48
  • 2
    You make a good point when learning object oriented design on your own. However, a major reason we have named design patterns is to be able to succinctly communicate a design between programmers. There's nothing wrong with asking someone more experienced to recommend a design pattern for a specific situation. Just make sure you don't blindly copy it, but that you understand the reasons behind it, so you can implement and adapt it properly. – Karl Bielefeldt Dec 18 '13 at 13:53
  • guess its a bit chicken and egg. not sure which one(s) to use so ask, but cant really have that answered blindly. appreciate that. but until I (you) use them a bit, its hard to work it out – nat Dec 18 '13 at 15:03

When you have to access a data model which was not designed with some object- or inheritance structure in mind, IMHO it is best to avoid any artifical "objectification" afterwards. The risk is high that with the next version of the DB model, the changes will collide with the object structure you have added. Even without a change of the DB schema, the real-world data may not conform to the additional constraints your class hierarchy induces on the system.

So keep it simple and stupid and create one class per table, one attribute per db column, avoid to use inheritance and try how far you can get with this approach.

Things are quite different when the DB design was made from class model, with an ORM in mind. Then the documentation of the ORM should suggest how the mapping from tables to classes may be and which options you have.

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.