Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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:
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.
This should give you a fair idea.
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:
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.
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.
