Patterns, Best Practices and Clean Code

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 开发者_如何学Cwith a simple class rewritten using lambdas and closures.

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

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.

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.

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

I think that a part of the problem are examples in the books.

When you write a book or article, you need some examples to present your idea. Usually the examples are meant to be simple. However, for a simple example the "pattern" may not make too much sense.

Then some people start applying the complicated machinery to all kind of simple problems, just to stick a pattern somewhere. I think this is the bad usage of patterns you're describing.

However, for more complicated designs (well, it requires very good judgment) patterns may be useful. You may also want to read When are design patterns the problem instead of the solution?

You can't hit the ball if you don't swing the bat. In order to find the right balance, you need to experiment and that means you may over do it sometimes. You shouldn't be afraid to try new things and refactor when you think another design will work better. The only thing you should be afraid of is not learning and getting better.

actually, just recently i've had an argument in Twitter. i invited some programmers to "design patterns barcamp". but one guy started saying that there's no sense in such a barcamp, since you whether know patterns or no. it's like achieving the nirvana, he said. but i disagree. we're all engineers. and learning how to write good software, partially, comes from abstractions. BUT again, it's not enough. learn other programming languages, paradigms, extend your knowledge of the tool you're using, read the code of open-source software written in your favorite language, and you'll become a better programmer (if you're fortunate enough huh)

answering your question. yes, there are some people that think they can apply patterns. but sometimes they're taking the pattern that does not fit their problem. i like to say that all the tools are best for what they're intended for. so, patterns are the same. if you're not sure, better talk to your architect. look up what are the best practices, why patterns are used, what kind of possibilities/difficulties will it give? won't it be an overhead? will the code still be readable and supportable? if "Yes", then go ahead.

IIABDFI. If It Ain't Broke, Don't Fix It.

In other words, the only reason to re-write "a piece of code that works well" as you put it is if you need to generalize what it does not make that same code re-usable.

In which case, using a pattern can be a benefit in figuring out how to achieve re-usability effectively, but the pattern needs to be a tool, not the end goal.

Mind you, whether to use patterns or not is a whole different question and I find that it is best answerd by the first (accepted) answer to this SO question. In short, if you're a good developer, you will be using patterns whether you know it or not, because all a pattern is is a good and often-seen solution to specific class of design problems. (I was in that situation - I have over the years created or was taught, and was using repeatedly, may useful designs only to be told one day that these things are called patterns and someone gave them cute names).

The majority of the time I've found that code that works well already follows appropriate patterns. There are two patterns I've seen that have complicated things - Singleton and Decorator. IMHO a Singleton is just a more verbose version of a class of static methods. The Decorator pattern isn't great either as it forces each decorator to re-implement a load of boiler plate violating DRY, as well as knowing about the decoration violating SRP. On the whole, patterns are mostly good tools, but just because a concept has the title of a "Pattern" doesn't mean it's any good.