While Design patterns are recurring solutions to problems often encountered in software applications, anti-patterns are exactly the opposite — these are recurring programming practices that create problems instead of solving them. These evolve out of over engineering, wrong implementation of design patterns, not following the recommended practices, etc.
Selecting the Right Combination
The choice of which patterns, frameworks and platforms to use in an application depends largely on an objective observation of the functional and non-functional requirements. You shouldn’t select a design pattern because you saw someone use it somewhere or someone told you that there is no harm in using it. You should decide whether or not it is the right pattern to use based on what your problem statement is and what solutions are available for you to achieve the stated goal.
Let’s discuss a few programming anti-patterns. Single Responsibility Principle is one of the most important of the SOLID principles in software engineering. The SOLID principles include: single responsibility principle, open/closed principle, Liskov substitution principle, Interface segregation principle and dependency inversion principle. SOLID principles, if followed properly help you to build types that are easier to manage, test and maintain. The Single Responsibility Principle states that an object should perform one, and only one, task.
It is a bad design if you have too many operations in your class. If you have a class that performs, or is intended to perform, too many tasks, it violates the Single Responsibility Principle. This anti-pattern is characterized by a single class that contains many different operations — many responsibilities are allocated to this class. Instances of such classes that perform too many tasks are known as God objects. Such classes are difficult to test, manage and maintain.
Spaghetti code is another example of an anti-pattern — such code is difficult to maintain and is not reusable. Spaghetti code is a result of developers writing code without a proper design and code review. The relationship between objects is a bare minimum and you would need to write many integration tests before you could deploy your application to production. Testing of Spaghetti code is difficult, such code doesn’t leverage the benefits of object oriented programming and most importantly, the flow of execution is dictated by the objects and not the consumers.
Constructor injection becomes an anti-pattern if one or more of the arguments to the constructor is not a class dependency. In essence, imagine that you have a class with an argument constructor and the argument(s) in your constructor is not always needed. You are still constrained to pass the arguments in the order in which they have been declared just to satisfy the method (the constructor in this example) call. This is an example of a code smell — you are injecting dependencies that are not always needed using a constructor. Implementing design patterns to solve the design problems encountered is definitely a good idea. However, you should not overuse patterns. If design patterns are not used the proper way, your code would become difficult to understand and maintain and become an anti-pattern.
Conclusion: There are many other anti-patterns such as service locator, singleton, generic repository and the dispose pattern. Such anti-patterns are an example of using these patterns the wrong way. These patterns do have some useful applications but if not used properly will result in code smells and hence an anti-pattern.
About the author: A Microsoft Most Valuable Professional in ASP.Net, as well as a speaker and the author of several books and articles. He received the prestigious MVP (Most Valuable Professional) award at ASP.Net for 2007, 2008, 2009, 2010, 2011, and 2012. He has more than 18 years of industry experience in IT, with more than 12 years in Microsoft .Net and its related technologies. He has been selected as MSDN Featured Developer of the Fortnight (MSDN) and as Community Credit Winner several times. He is the author of eight books and more than 250 articles. Many of his articles have been featured at Microsoft’s Official Site on ASP.Net. He was a speaker at the reputed Spark IT 2010 event and at the reputed Dr. Dobb’s Conference 2014 in Bangalore. He was also a speaker at SSWUG Virtual Conference in April, 2015. He’s also worked as a judge for the Jolt Awards at Dr. Dobb’s Journal.