Anti Patterns

Learning of your own or others mistakes:
Yet Another Fucking Layer, see:
http://en.wikipedia.org/wiki/Anti-pattern#Object-oriented_design_anti-patterns

Object-oriented design anti-patterns

• Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
• BaseBean: Inheriting functionality from a utility class rather than delegating to it
• Call super: Requiring subclasses to call a superclass's overridden method
• Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
• Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
• God object: Concentrating too many functions in a single part of the design (class)
• Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
• Object orgy: Failing to proper encapsulate objects permitting unrestricted access to their internals
• Poltergeists: Objects whose sole purpose is to pass information to another object
• Sequential coupling: A class that requires its methods to be called in a particular order
• Singletonitis: The overuse of the singleton pattern
• Yet Another Fucking Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.
• Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation