In the previous chapter, we started with an introduction to Compound patterns. You learned how design patterns work together to solve a real-world design problem. We went further to explore the Model-View-Controller design pattern—the king of Compound patterns. We understood that the MVC pattern is used when we need loose coupling between components and separation of the way in which data is stored from the way data is presented. We also went through the UML diagram of the MVC pattern and read about how the individual components (model, view, and controller) work among themselves. We also saw how it's applied in the real world with the help of the Python implementation. We discussed the benefits of the MVC pattern, learned more about it in the FAQs section, and summarized the discussion at the end of chapter.
In this chapter, we will talk about AntiPatterns. This is different from all the other chapters in the book; here, we will cover what we shouldn't do as architects or software engineers. We will understand what AntiPatterns are and how they are visible in software design or development aspects with the help of theoretical and practical examples.
In brief, we will cover the following topics in this chapter:
- An introduction to AntiPatterns
- AntiPatterns with examples
- Common pitfalls during development
At the end of the chapter, we will summarize the entire discussion—consider this as a takeaway.
Software design principles represent a set of rules or guidelines that help software developers make design-level decisions. According to Robert Martin, there are four aspects of a bad design:
- Immobile: An application is developed in such a way that it becomes very hard to reuse
- Rigid: An application is developed in such a manner that any small change may in turn result in moving of too many parts of the software
- Fragile: Any change in the current application results in breaking the existing system fairly easily
- Viscose: Changes are done by the developer in the code or environment itself to avoid difficult architectural level changes
The above aspects of bad design, if applied, result in solutions that should not be implemented in the software architecture or development.
An AntiPattern is an outcome of a solution to recurring problems so that the outcome is ineffective and becomes counterproductive. What does this mean? Let's say that you come across a software design problem. You get down to solving this problem. However, what if the solution has a negative impact on the design or causes any performance issues in the application? Hence, AntiPatterns are common defective processes and implementations within software applications.
AntiPatterns may be the result of the following:
- A developer not knowing the software development practices
- A developer not applying design patterns in the correct context
AntiPatterns can prove beneficial as they provide an opportunity for the following reasons:
- Recognize recurring problems in the software industry and provide a detailed remedy for most of these issues
- Develop tools to recognize these problems and determine the underlying causes
- Describe the measures that can be taken at several levels of improving the application and architecture
AntiPatterns can be classified under two main categories:
- Software development AntiPatterns
- Software architecture AntiPatterns