Katere so pogoste OOP anti-vzorci?

Question

Accepted Answer

Anti-vzorci so ponavljajoče se "rešitve", ki se zdijo razumne, a pokvarijo oblikovanje. Najpogostejši v OOP so **God Object**, **globoke hierarhije dedovanja** in **Anemic Domain Model**. ## God Object Razred, ki ve in naredi premalo – krši Single Responsibility. ```java class AppManager { // 5,000 lines, touches everything void parseRequest() {} void queryDb() {} void renderHtml() {} void sendEmail() {} void logMetrics() {} void authUser() {} } // Fix: split into focused, cohesive classes (Router, Repo, View, Mailer...) ``` ## Globoke hierarhije dedovanja ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` Vsaka raven je povezana z vsemi predniki; sprememba blizu vrha se razširi povsod (krhka bazna razred). **Rešitev:** sploščiti s kompozicijo; raje "ima-a" sposobnosti pred globokimi "je-a" verigami. ## Anemic Domain Model Objekti, ki so le vrečke getters/setters z vso logiko drugje – OOP samo po imenu. ```java // ANEMIC: data with no behavior; rules live in a separate "service" class Order { List 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 items; double total() { return items.stream().mapToDouble(Item::price).sum(); } } ``` ## Drugi vredi omembe ```text → 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) ``` ## Zakaj je to pomembno Anti-vzorci so kako dobre namere propadejo: God Object je ponavadi začel kot majhen pomočnik, anemic model kot "samo DTO-ji", potem se ukameni. Njihovo poimenovanje daje ekipam skupni zgodnji-opozorilni besednjak pri pregledu kode, in vsak anti-vzorec neposredno kaže na načelo (SRP, kompozicija, enkapsulacija), ki ga odpravi.