I hope all the developers reading this have the word SOLID engraved on their heart, able to reel off those five principles without even thinking about it.
But everything has to have an opposite so what is opposite of SOLID, well that's easy that's just STUPID.
Singleton
Probably the first design pattern most of us learnt was the Singleton pattern and while it occasionally has its uses it is much more frequently an example of an anti-pattern.
A properly applied design pattern should improve code not just now but in the future and should pass this magic on to the other areas of the code that interact with it.
Singletons don't fit this criteria for a few reasons,
- They encourage the use of global state.
- Their use causes classes to hide their dependencies.
- They do not allow for extension.
All of this means although using a Singleton might fix your immediate need it does damage in the long run.
Tight Coupling
For a class to be tightly coupled means it is very susceptible to breaking when anything changes in it dependencies.
You're then left with a choice of resigning yourself to having to fix that class on a regular basis or determining not to change anything in its dependencies. This second choice will inevitable result in some elaborate hacking to come up with ever more complicated solutions to changes in requirements.
This degradation in the quality and structure of the code is the very definition of code rot.
To compound this calamity this ever more complex code will be difficult to test because of the tight coupling, the viscous circle is complete.
Untestable
Their is almost no acceptable reason for a class to be untestable, very often this is just a slightly different phrasing of saying your code is difficult to use or to work with.
We have to remember that testing our code is not a special activity, it simply involves using what we have written within a test, any issues we find in doing this will surely be just as problematic when we come to using it in an actual application or having to work with it again in the future.
A large majority of untestability is caused by not being able to separate the class in question from its dependencies, either because of tight coupling or because the dependency is simply hidden.
Proper use of interfaces and dependency injection will counter these problems and make your class easy to test and easy to modify in the future.
Premature Optimisation
Developers will very often become involved in intense debates about the optimal way to perform a certain task.
The truth is that in most situations performance really isn't an issue.
This isn't to say that we should give no thought to performance but we should not value it higher than having readable clear code.
The majority of premature optimisations result in code that is difficult to read, understand and work with. This shouldn't be something we want unless the optimisation really is critical, and believe me most of the time it won't be.
Even if you do happen to require a highly optimised system this performance will come from optimising the architecture and thinking about the flow of data around the system, that particular for loop is unlikely to be the key to it all.
As Martin Fowler put it,
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
Indescriptive Naming
In a similar vain, the compiler doesn't care what you call your classes, methods or variables but as a reader of your code I'm hoping you give me a steer as to what's going on by using descriptive unambiguous names.
We sometimes forget that code has to read by others as well as perform the task that is required.
We may think that comments can address this issue but wouldn't it be easier to write code that is self-documenting and doesn't require further explanation?
Their is no mechanism that will keep your comments and your code in sync, a comment that may be accurate now could very easily be completely misleading in the future, whereas the code itself will always describe what the system actually does.
Duplication
Duplicating code to solve a problem has no up side, it results in more code to test, maintain and be a source for bugs.
Problems where duplication is the answer are problems of our own making, we have created a system where parts of the system that should be connected aren't or where areas of the system are required to know or do more than they should.
Copy and paste should be something that makes us feel a bit queasy, surely their must be a better way.
Thankfully answers to all these problems can be found in the warm embrace of the SOLID principles, follow them and you will rarely do anything STUPID.
For every decision you make ask yourself which one of these acronyms would best describe what I've just done.
No comments:
Post a Comment