Posts Tagged: design patterns


5
Mar 09

Memory Palace method example: Strategy pattern

This post is a sequel of previous How to start using Design Patterns post, describing the Memory Palace memorization method. I recommend you to read it before starting to read this post.

For example, I can use my sitting room as a basis for the remembering path. In this room I have the following objects:
Table, big bright window, lamp, sofa, picture on the wall, small bookcase, CD rack, telephone, television, DVD player, chair, mirror, black and white photographs, etc.

I want to put all the units required for remembering the StrategyContext implementation in that room. I’ll start from window and will move to the door out of the room.

When I hear the word “strategy”, the first image comes to my mind is an ancient roman warrior with armors. “Context” associates with Jacuzzi for me(something that surrounds you). So I “see” the roman warrior sitting in the Jacuzzi(pay attention at bubbles and moist air in the room).

Here is an example implementation of the GoF Strategy pattern, main concept of which we want to remember:
I’ve taken it at Strategy PHP example from software pattern catalog:
Continue reading →


28
Feb 09

How to start using Design Patterns

I remember myself procrastinating in using of Design Pattern in production code, after reading the information about the GoF patterns.

On the paper everything looked very easy and understandable. But after you might fall in trap of fear of using this knowledge in production code, because:

  • You have a very limited time dedicated for the task. So you can’t find the time to do the things “in right way”
  • You haven’t enough experience of some particular Design pattern, so you don’t know how to exactly implement in real problem solving. So you spend more time and get out of time scope for task and schedule. So you decide to refuse “the hard right way”, and implement an easy and dirty “temporary” solution.

If you refused to implement the pattern, you haven’t improve your experience with this pattern. It is an infinity loop: you can’t implement because you don’t have a required experience. Time passes, and you will have the exact same problem in future, and the initial conditions(level of experience with particular pattern) are still low.

I was in this loop for a couple months. And after I recognised this behaviour habit, I’ve asked for help more my more experienced co-workers. The advice was simple and easy:

You can’t succeed without failure. If you want to become more experienced in Object Oriented design and Design patterns, you have to have a will in this trend, and still moving nonetheless the periodic temporary failures.


28
Jan 09

How to remember software design patterns

Who likes to learn from the scratch the same issues over and over again. Assume, that nobody.

But sometimes we have to do so with design patterns, because that is not the case we have a close contact with every of 23 classic software design patterns.

I don’t remember, who wrote that:”we uses implementation patterns every hour, we uses design patterns much rarely, and we use architectural patterns mostly at the start of the project”.

And when we don’t use some of our knowledge for quite a long period of time, we actually loose this knowledge, and will have to learn it again, when we need it.

I think, that design patterns are worth remembering, because it is not the case, when you’ll have to forget it later, because something new will appear. Software design patterns are core solutions for constantly appearing daily design tasks. And mostly, it doesn’t attached to particular programming language, or framework(but every implementation has its own differences).

Continue reading →