I am successfully able to scale all my old applications which were not using documented Design Patterns. Whatever pattern it is I don't know. To a large extent, I only felt a need to use simple OOP concepts.

The Design Patterns concept is complex and hard to understand. When implemented, how to determine whether the implementation is correct and the application possess real loose coupling?

  • 49
    There is a serious misconception about what design patterns are. They are not magic fairy dust that you sprinkle over your application to make it better. They are primarily a common vocabulary to be able to talk about commonly used ways to solve problems. I'm pretty sure there are many people who "implement patterns correctly" all day long without ever having heard of the word "pattern". Jul 19, 2012 at 7:50
  • 2
    @JoachimSauer What you just said is the kind of stuff that technical universities should teach... Since I'm currently a student, this is the thing that currently pisses me off the most. Jul 19, 2012 at 8:48
  • 1
    @JoachimSauer Actually this misconception arises because there are variety of implementation techniques for the same pattern. Take for instance MVC and MVP, there are as many variations as the projects, of the same pattern.
    – RPK
    Jul 19, 2012 at 16:27
  • @RPK +1, the very fact that there are scores of MVX patterns (MVC, MVP, MVA, MVVM etc) should be a clear indication that there are many equally viable ways to do things.
    – MattDavey
    Jul 23, 2012 at 12:26
  • possible duplicate of When should I use—and not use—design patterns?
    – gnat
    Apr 9, 2013 at 5:44

4 Answers 4


To keep the answer concise, i would say if the following characteristics are visible in your code, you can be confident that the patterns are in place even if you have not made deliberate efforts (which is not an issue) towards it.

Desired Characteristics:

  1. Your code base is testable at unit level
  2. Whenever you are implementing any change requests then you are making changes only to relevant classes which co-related in the domain.
  3. Your code base is not exhibiting software entropy.

If your still curious to identify and tag your code with the real patterns names, i would recommend a to perform following actions to get the ball rolling.

  1. Reverse engineer your code base to generate a few UML daigrams.
  2. Visually compare the diagrams with any ready reference of patterns reference material.

This should give you a fair idea.

  • Could you elaborate more about the third one?
    – NingW
    Apr 1, 2019 at 7:20

You mention both design patterns and coupling. These are separate concepts so I'll deal with them separately. The only real connection is that design patterns tend to promote loose coupling (since it's a major aspect of good design).

Design Patterns

The concept of Design Patterns is actually quite simple: They're just a set of templates of how to deal various common problems. There are 2 main reasons that they are popular:

  1. They are 'proven': they have been used before many times and the benefits/drawbacks of each are generally known, in particular any subtle issues that might cause big problems are known.
  2. They provide a common set of terminology, and so enable easier communication. If someone says "class X plays the role of the observer in the observer pattern" then developers who are familiar with the pattern can immediately grasp what's going on.

How do you know that you've implemented it correctly? That's a tricky one. For most patterns it's simple - you've either grokked it or you haven't. Some patterns are less clearly-defined than others - e.g. model-view-controller. Patterns like that are better used as general guidelines. The specifics of how you implement it are less important than understanding the reasons that the pattern exists and what it's meant to accomplish.

Design patterns aren't 'the one true way'. Often you'll either need to adapt them for your specific purposes, or sometimes there just won't be any patterns which fit the requirements. Forcing a design pattern where it doesn't fit is a bad idea; it's like using a really good hammer when what you actually want is a screwdriver.


This is a really important idea in computer science. Since requirements for most software projects change over time (sometimes significantly) then the ability for a design to cope with changes is important. Coupling is basically the measure of "how hard would it be to swap out this component for another one?" The 'component' could be a method, class, package, library, etc.

There are various types of coupling listed in this Wikipedia article.


The answer is actually the purpose that you want to write design patterns from start. Why do you want flexibility for?

That is change; requirements change. Try to change something in your requirements that reflects in code change and see how easy/difficult is to do that.


Using design patterns is a preventive action. You use design paterns to ease your work when you are scaling the application later. Of course, to ease your work later you must do a bit more work now. so the real question is how much change can you expect in the future and what this change is. If you do not need scalability and flexibility you can do away with design patterns.

Design patterns are themselves an implementation of Object Oriented Design Principles. As long as you follow these principles your applications are going to be flexible and scalable; even if you dont really have an actual design pattern. As Joachim Sauer has commented above they are common solutions to common problems.

  • 2
    IMO, using design patterns have nothing to do with scalability. It's simply a vocabulary to recognize common patterns in code so we can talk about them. Often, scaling applications may mean going against good designs in favour of performance. Jul 23, 2012 at 22:51

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.