Introduction to Software Engineering/Architecture/Anti-Patterns

Anti-Patterns and Code Smells.
If design patterns are the good guys, then the anti-patterns are the bad guys. And sometimes a good guy can turn into a bad guy. This happens in Hollywood movies, but it also happens in software engineering. 
The "golden hammer" is a favorite notion of this problem: you learned to use a tool in one context (the golden hammer), and now because you are so proud having learned how to use this complicated tool, all of a sudden you see golden nails everywhere.
A good example is the Singleton pattern: it is so easy that it is the first pattern most beginning software engineers understand and henceforth, since presumably it is a good guy, they will use it at every possible occasion. However, the problem with the Singleton is that it violates "information hiding". Now information hiding is one of the sacred cows of modern software engineering, and it should be violated only when there is a really good reason for it. And just having learned about the Singleton pattern is not!
In software engineering, an "anti-pattern" is a pattern that may be commonly used but is ineffective and/or counterproductive in practice. The term was coined in 1995 by Andrew Koenig,
inspired by Gang of Four's book "Design Patterns", which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book "AntiPatterns", which extended the use of the term beyond the field of software design and into general social interaction. According to the authors of the latter, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:
By formally describing repeated mistakes, one can recognize the forces that lead to their repetition and learn how others have refactored themselves out of these broken patterns.
Examples of Anti-Patterns.
To understand anti-patterns a little better, let us take a look at a few examples. By studying them you may recognize some violation against software engineering principles you may have committed yourself at one point in time. Some of these anti-patterns have very funny names.
Singleton Overuse.
We have talked about this one: the first pattern you understood immediately, and you used it heavily. But beware it violates information hiding. Therefore the simple rule: when in doubt don't use it. My experience is that the larger the project, the more Singletons show up. 
How do you detect Singletons? Look at the class diagram. All classes that have references to themselves (or their base class) are potential Singletons. If you want to get rid of them, Kerievsky shows you the medicine that cures this disease. 
Functional Decomposition.
Although very popular once, in a modern object-oriented language there is no more space for functional decomposition. It is a remanent of procedural languages such as C or Pascal. Usually it indicates old software that was integrated into a new project or migrated.
This anti-pattern reveals itself in three ways: The names of classes sound like function names (e.g. CalculateInterest). Or the classes only have one action, i.e., they only do one thing. Or all class attributes are private (which is fine) but they are only used within the class. To detect this anti-pattern you can use a tool such as SourceMonitor. It lists all class names, and also lists the functions.
Poltergeist.
People like this anti-pattern because of its name. What it is, are classes that briefly appear to only disappear into oblivion. Either nobody knows what they really do, or they have very limited functionality. Usually they are not needed or can be absorbed in other classes.
Usually one recognizes this anti-pattern by class names that end in ’*controller’ or ’*manager’. Again a tool such as SourceMonitor can help to find this anti-pattern.
Often a consequence of "agile" approaches where cogitating is preferred to Design.
Spaghetti.
Spaghetti code is like the noodles: it is very long. Although the noodles are delicious, code the longer it gets is not. 
SourceMonitor can help you find this pattern, you simply look for methods with many lines of code. Refactoring usually is the cure here.
Blob.
A blob is a class with a lot of attributes and methods. Quite often these are not even related. You can detect this smell with your favorite code analysis tool, by listing classes with lots of attributes and methods or many lines of code. Usually splitting this class into several smaller classes will help here.
Copy and Paste.
As the name implies, somebody copied some code from some place to another place. It is the simplest way to duplicate functionality, but it should be avoided for many reasons. The simplest solution is to turn the code into a method instead, or use inheritance. 
To detect almost identical code you can use a tool like PMD’s Tool Copy/Paste Detector.
Lava Flow.
What is lava flow? "A lava flow is a moving outpouring of lava, which is created during a non-explosive effusive eruption. When it has stopped moving, lava solidifies to form igneous rock." In software engineering it means that the code is ancient, nobody has touched it for eons, and nobody has the guts to touch it (never touch a working class...). 
You can find these classes by using your source control system. Simply list those classes that have not been checked out and modified for a long time.
Code Smells.
Code smells are similar to anti-patterns, but not quite as formal. If code smells, then that smell can be o.k. (like some cheese) or it can be bad, possibly indicating a deeper problem. Kent Beck introduced the idea in the late 1990s and Martin Fowler made it popular in his book "Refactoring. Improving the Design of Existing Code". You can use tools, such as FindBugs, Checkstyle or PMD to find bad smells. Usually refactoring is used to remove the offending odor. Martin Fowler and Joshua Kerievsky, among others, provide the appropriate refactorings.
Duplicate Code.
This smell is very similar to the Copy and Paste anti-pattern. You can use the PMD Tool Copy/Paste Detector to find the problematic areas.
Long Method.
Related to the Spaghetti anti-pattern, you can find it using SourceMonitor when sorting classes according to ’Avg Stmts/Meth’. Methods that have more then 50 lines are definitely suspicious.
Indecent Exposure.
In the current Victorian age of information hiding, naturally indecent exposure is a bad thing. If a class has too many methods, or, god forbid, any public attributes then we talk about indecent exposure. You find this smell by checking for public methods of classes. If a class has more than 50% public methods, this may not conform to the information hiding policy.
Lazy Class.
Reminds me of the Poltergeist anti-pattern: this is a class that does so little that it has no reason for existence. Try to absorb it into another class. To detect this smell use SourceMonitor: Sort 'Methods/Class' and look for classes that have fewer than two methods or look for classes with very few lines of code. They are suspect of being lazy.
Large Class.
A large class is the opposite of a lazy class. You find it similarily, look for classes with too many methods, or too many statements. Usually a class should not have more than 30 methods or more than 400 statements. Also class with too many attributes could be large classes.
Kerievsky shows several possible ways of reducing this smell.
Really means not coding to code conventions. Look up Meyer, MISRA etc.
Known Anti-Patterns.
There are many known anti-patterns. A list and brief description of some is provided for your entertainment.