Anti-patterns भनेको पुनरावृत्ति हुने "समाधान" हुन् जो उचित लाग्छन् तर डिजाइनलाई गिरावट ल्याउँछन्। OOP मा सबैभन्दा सामान्य anti-patterns God Object, गहिरो inheritance hierarchies, र Anemic Domain Model हुन्।
एक class जसले धेरै कुरा जान्छ र गर्छ — Single Responsibility को उल्लङ्घन गर्छ।
{
{} {} {}
{} {} {}
}
Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat
प्रत्येक स्तर सबै पूर्वजमा जोडिन्छ; शीर्षको नजिक परिवर्तन सबै जागामा फैलिन्छ (fragile base class)। समाधान: composition सँग समतल गर्नुहोस्; गहिरो "is-a" chain भन्दा "has-a" क्षमताहरू प्राथमिक गर्नुहोस्।
वस्तुहरू जो केवल getters/setters को झोली हुन् र सबै logic अन्यत्र बस्छ — नाममात्र 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 सामान्यतः सानो सहायकको रूपमा सुरु हुन्छ, anemic model "केवल DTOs" को रूपमा, त्यसपछि कठोर हुन्छ।
तिनीहरूलाई नाम दिनुले टीमलाई कोड समीक्षामा साझा प्रारम्भिक चेतावनी शब्दावली दिन्छ, र प्रत्येक anti-pattern सीधै सिद्धान्त (SRP, composition, encapsulation) को लागि इशारा गर्छ जसले यसलाई ठीक गर्छ।n