I am currently learning about design patterns.
I think most people would agree that these patterns are great tools, but should be used with moderation and not as the answer for everything. Using them too much would over-complicate the application with little benefit. Patterns should be used only where they can be the best solution or help in the creation of a good solution (do you agree?).
With this in mind:
The book I'm reading (Head First Design Patterns) frequently emphasizes the importance of loose coupling. This loose coupling is acheived by following principles such as 'program to an interface, not an implementation' and 'encapsulate what varies'.
Basically, most patterns I learned so far exist mostly to allow designs to be loosely coupled, and thus more flexible.
I understand the importance and benefits of loose coupling.
But my question is, how much effort should one actually invest in creating loosely coupled, flexible designs?
Those who oppose design patterns say that the costs to using these patterns often outweighs the benefits. You invest a lot of time in creating a loosely coupled design using some pattern, where in reality – the loose coupling, 'programing to an interface, not an implementation', and all of these principles – might not actually be so important.
What I'd like to know, is how much effort should I actually put in creating additional levels of abstraction and designs, only to allow my application to follow OO principles such as loose coupling, programmign to an interface, etc. Is it really worth it? How much effort should I put in this?
Best Answer
Fatuous answer: the more you do it, the less effort it is.
Basically, building loosely coupled code isn't really very hard. Training your mind to think in terms of loose coupling, on the other hand, is. And, well, I believe it to be totally worth it.
Suppose you take a job that uses an iterative approach to software development, as has been recommended by most everyone over the last 20 years. You build something that works beautifully in iteration 1. In iteration 2 you build on top of it, adding some new features, and somewhat bending one or two things a bit when they don't fit into your iteration 1 concept of how things should work. Now comes iteration 3, and you find out the requirements demand you rethink your basic architecture. How do you tear your code apart and rebuild it without going back to square one?
This happens. A lot. It either makes projects run late, or it makes everyone too scared to do what needs to be done in later iterations. In the best case, you get a Big Ball of Mud. Things like loose coupling and the single responsibility principle mitigate these problems in a big way. That's why SOLID principles are touted--they really do help.
And you will find that after you've got a few loosely coupled designs under your belt, it starts to come naturally. Patterns are things that people found that worked for them, so they documented them. They're useful tools that also come naturally with time.