What is Anti-Pattern?
Anti-patterns are bad design patterns in software development that are considered bad programming practices. So a pattern is an idea of how to solve a problem of some class, and an anti-pattern is an idea of how not to solve it because implementing that idea would result in bad design.
An anti-pattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn’t one. (Koenig, 1995)
The term anti-patterns was defined in Andrew Koenig’s article Patterns and Anti-Patterns in the C ++ column published in the Journal of Object-Oriented Programming in 1995;
It occurs when too much time and energy is devoted to the analysis of a project. The main reason is lack of knowledge and inexperience. Too much analysis before making a decision or taking action causes the business process to stall.
It is that the current problem is perceived as much bigger than it is. While the solution can be done more easily, it can be stated as trying to solve with a more complex structure.
In short, an anti-pattern is a kind of design smell.
We can examine the anti-pattern examples under the following subjects;
The Blob
The biggest problems of the blob are two: difficult to reuse / difficult to test.
A procedural style design is loaded into a single object that is almost exactly the full workload, while most other objects only hold data or execute simple operations.
This anti-pattern is the case where simple data classes can be combined and managed under a single class depending on a single class. The main problem here is that the majority of responsibilities are allocated to a single class.
The allocation of responsibilities is not repartitioned during system evolution so that one module becomes predominant.
The blob is often accompanied by unnecessary code, making it hard to differentiate between the useful functionality of the Blob class and no-longer-used code.
Over time, the blocks of code on the page become interdependent, making it difficult to separate the code.
The solution is to more evenly distribute responsibilities and parse dependencies using abstraction.
Lava Flow Programming
Continue to host unnecessary or low-quality codes due to high removal costs or unforeseen reasons.
In general, when a legacy is working on a project, there are interesting code structures that only the author can understand the written development. Such structures scare the developer who adds them later and does not want to touch them.
Of course, there are some reasons why this situation occurs. Bad manager, limited development time, as one person does this development. As this process gets longer, development becomes inextricable and often ends with a total transfer to a project. To develop both fast and high-quality code, you need to find the optimal balance.
Otherwise, your project, which starts very well, can turn into a complex structure over time.
Poltergeists
Useless classes with no real responsibility of their own are often used to just invoke methods in another class or add an unneeded layer of abstraction.
Poltergeists are classes with limited responsibilities and roles to play in the system; therefore, their effective life cycle is quite brief. Poltergeists clutter software designs, creating unnecessary abstractions; they are excessively complex, hard to understand, and hard to maintain.
In this anti-pattern, it is possible to identify one or more ghost-like ghost classes that appear only briefly to initiate some actions in another more persistent class.
Their names are usually in the format _manager or _controller and can also be defined as ghost classes.
Golden Hammer
Our database, our architecture…
It is called solving all problems by the method believed to be a perfect solution. If he has a hammer in his hand, every problem looks like a nail. For example, micro-service architecture is not required for every project, or it may not be the best architecture.
Document-based databases are sufficient for some projects, but sometimes it just makes the job difficult. Technological developments should be followed continuously. This is among the most common anti-patterns.
Spaghetti Coding
A design pattern can solve any problem but it is useless if it does not solve the problem where it is used.
They are uniformly written code that makes maintenance and development very difficult, often seen in object-oriented programming.
It includes methods that are written against the principles of Single Responsibility and are process-oriented. There is almost no relationship between objects. Most methods take no parameters and use global variables.
Lacks OOP basics and makes things even harder with the use of goto.
Here is another example of spaghetti code with embedded goto statements.
Lasagna Coding
If a pattern causes more problems than it solves, it is an anti-pattern.
This coding format was born in response to the spaghetti code method I mentioned earlier :)
Layers are indeed a great architectural tool for structuring your code when used as needed but lasagna code has more layers than necessary.
In object-oriented programming, this means code that has lots of small classes, while a few slightly larger classes would have been much more understandable.
For example, the code segment that follows contains functions such as LoadGrid(), GetConnection(), and ExecuteQuery(), which completely execute the specified operation. Each object method contains a single process flow that performs all of the steps in the sequence needed to perform the task.
The object retains little or no state information between successive invocations; rather, the class variables are temporary storage locations to handle intermediate results of a single process flow.
Copy Paste Programming
The Cut-and-Paste Programming Anti-Pattern is acceptable when the sole aim is to get the code out of the door as quickly as possible.
However, the price paid is one of increased maintenance.
It is an improvement made by copying the codes instead of a more generic solution. It is usually used by taking a previously developed code block for a solution.
Any changes to be made in the copied code must be made on all copies, otherwise, it will work incorrectly and increases maintenance and development costs.
Magic Pushbutton
This anti-pattern is writing code behind the elements without using any abstraction. This coding format is referred to as button_click programming. Usually seen in GUI type applications and generally, they are improvements made without using any business layer.
When the time comes, you have to fight the code to separate your button_click job because abstraction is not used when developing the code. Also writing tests might be painful.
Reinventing the Square Wheel
The effort to develop a worse custom solution instead of an existing solution is an unnecessary and long road. It is unwise not to use some solutions whose solution has been experienced by all software developers for many years.
Moreover, there are standardized architectural approaches, products, and roofs (Frameworks) for these solutions.
If the wheel has already been invented, just take it and use it, it is unnecessary to invent the wheel again.
Thank you for reading.
Resources:
https://sourcemaking.com/antipatterns
