In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.
Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.
Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.
Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.
Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.
Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.
Link:
http://www.codeops.tech/blog/linkedin/what-causes-design-smells/
From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.
