अँटी-पॅटर्न्स हे पुनरावर्ती "समाधान" आहेत जे वाजवी दिसतात परंतु डिজाइन खराब करतात. OOP मधील सर्वात सामान्य God Object, गहन इनहेरिटन्स हायरार्की आणि Anemic Domain Model आहेत.
क्लास जो खूप काहीतरी जाणते आणि करते — Single Responsibility चा उल्लंघन करते.
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
प्रत्येक स्तर सर्व पूर्वजांना जोडलेला असतो; शीर्षाजवळ केलेले बदल सर्वत्र पसरतात (fragile base class). Fix: composition सह सपाट करा; गहन "is-a" साखळ्यांपेक्षा "has-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)
अँटी-पॅटर्न्स असे आहेत की उत्तम हेतू कसे खराब होतात: God Object सामान्यतः एक लहान हेल्पर म्हणून सुरू होते, एक अ-रक्त मॉडेल "फक्त DTO" म्हणून, नंतर कठोर होते.
त्यांना नाव देणे टीमला कोड रिव्यूमध्ये एक सामायिक प्रारंभिक-चेतावणी शब्दावली देते, आणि प्रत्येक अँटी-पॅटर्न थेट तत्त्व (SRP, composition, encapsulation) वर निर्देश करते जो त्याला स्थिर करते.