Τα anti-patterns είναι επαναλαμβανόμενες "λύσεις" που φαίνονται εύλογες αλλά υποβαθμίζουν ένα σχέδιο. Τα πιο συνηθισμένα στο OOP είναι το God Object, οι βαθιές ιεραρχίες κληρονομιάς και το Anemic Domain Model.
Μια κλάση που γνωρίζει και κάνει πολλά — παραβιάζει το Single Responsibility.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
Κάθε επίπεδο συνδέεται με όλους τους προγόνους. μια αλλαγή κοντά στην κορυφή εξαπλώνεται παντού (fragile base class). Λύση: επίπεδη χρήση σύνθεσης. προτιμήστε τις δυνατότητες "has-a" έναντι των βαθιών αλυσίδων "is-a".
Αντικείμενα που είναι απλώς σακούλες getters/setters με όλη τη λογική που ζει αλλού — OOP μόνο ονόματι.
// ANEMIC: data with no behavior; rules live in a separate "service"
class Order { List<Item> items; double total; /* only getters/setters */ }
class OrderService { double calcTotal(Order o) { ... } } // logic exiled
// RICH: behavior lives with the data it operates on
class Order {
private List<Item> items;
double total() { return items.stream().mapToDouble(Item::price).sum(); }
}
→ Yo-yo problem (jumping up/down a deep hierarchy to follow logic)
→ Circular deps (A needs B needs A)
→ Feature envy (a method that mostly uses another class's data)
Τα anti-patterns είναι πώς σαπίζουν οι καλές προθέσεις: ένα God Object συνήθως ξεκινά ως μικρή βοηθός, ένα αναιμικό μοντέλο ως "απλώς DTOs", στη συνέχεια σκληρύνεται.
Το όνομα τους δίνει στις ομάδες κοινό λεξιλόγιο πρόωρης προειδοποίησης στην αναθεώρηση κώδικα, και κάθε anti-pattern δείχνει άμεσα στην αρχή (SRP, composition, encapsulation) που τη διορθώνει.