Patterns, Best Practices and Clean Code

Question

I often find myself reading books and articles that outline patterns, best practices, and how to write "clean code." However, some of these concepts just seem to be over engineered and at times obscure the essence of the underlying problem, making the code more difficult to relate to the problem domain being modeled.

How often do you find yourself refactoring a piece of code that works well in favor of a "pattern?" Have you encountered a situation where the "pattern" actually complicated the code or obscured its meaning? I felt this way a while back after seeing a solution to a problem I solved with a simple class rewritten using lambdas and closures.

I struggle with this and I'm curious how others approach find the right balance.

Answer 1

You should never refactor your code just to make it fit to a pattern you've read in some book.

Patterns really help you to train your brain in terms of thinking about good software design. I would actually say that I acquired much of my programming skills and knowledge through reading of pattern books and by reflecting about them and by learning to understand how they work out and what advantages they'll give you. And that's actually the key. Their purpose is to make things easier, more maintainable, easier to test etc... not to make your life harder :)

I think that's also the "difficulty". Patterns give you a frame, a point to start from when you encounter a problem. Example: You really want to unit test your code, but you're just not able to because it depends on UI logic or is too much coupled. That's your problem, so you may get to a solution by knowing about the MVC pattern and the concept of dependency injection and IOC. They may give you a starting point since the MVC for instance explains you on a high level concepts of an Observer, Observable, Controller view etc...and how they are related to each other. It is then your task as a good programmer to choose the right approach and to what extend you find it reasonable to apply the pattern. Don't just apply it 'cause the pattern tells you. Remember, it is just a frame, you may modify and adapt it s.t. it is suitable for your specific circumstances.

Answer 2

My advice is to keep your design straightforward for as long as is practically possible - without sacrificing maintainability.

A good pattern based object oriented design has lots of small, very specialized classes. The simplest of functionalities can touch many classes. Which makes it time consuming to learn/understand the design. The advantage of such "well-factoredness" is that the code is maintainable - a small requirements change generally requires a small localized code change.

The less complex your system is, the easier you can get away with a straightforward design. But as a system gets bigger and more complex, the tradeoff swings towards a more complex design for maintainability's sake.

Answer 3

Use these articles and books as a guide. The more you know the more you will have at your disposal in making the right decision about what to use and when. Design patterns are not meant to be used whenever possible nor is refactoring something you just do because.

You should refactor code when you need to. For example as you are adding a feature or fixing a bug and notice you can make it better.

You should use a pattern in the same way. Patterns can make your code worse when used wrong/improperly and obscure code when a simpler non-pattern way would satisfy the solution. There's no need to go pattern happy in code and when this occurs the code is the worse for it.

Stick with the YAGNI (You aren't going to need it) approach. This is not to say, you don't ever think about your design. Rather, it's the idea that we often as you mentioned can over engineer our solution instead of letting it develop over time as needs are identified.

"Theory is good. Theory reminds us that people have dealt with these issues before. But is it law? We owe it to ourselves to think and understand for ourselves." - Rob Conery