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?

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".
–
Joachim SauerJul 19 '12 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.
–
Radu MurzeaJul 19 '12 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.
–
RPKJul 19 '12 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.
–
MattDaveyJul 23 '12 at 12:26

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:

Your code base is testable at unit level

Whenever you are implementing any change requests then you are making changes only to relevant classes which co-related in the domain.

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:

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.

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.

Coupling

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.

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.

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.
–
Adrian SchneiderJul 23 '12 at 22:51