Koja su česta OOP anti-uzorka?

Question

Accepted Answer

Anti-uzorci su ponavljajuća "rješenja" koja izgledaju razumno ali degradiraju dizajn. Najčešće u OOP-u su **God Object**, **duboke hijerarhije naslijeđivanja**, i **Anemic Domain Model**. ## God Object Klasa koja zna i radi previše — narušavajuć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...) ``` ## Duboke hijerarhije naslijeđivanja ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` Svaka razina se veže na sve pretke; promjena blizu vrha se širi svugdje (fragile base class). **Popravka:** izravnati sa kompozicijom; preferirati "has-a" sposobnosti umjesto dubokih "is-a" lanaca. ## Anemic Domain Model Objekti koji su samo vrećice gettera/settera s cijelo logikom živećom drugdje — OOP samo u imena. ```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(); } } ``` ## Ostali vrijedni nazwanja ```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) ``` ## Zašto je to važno Anti-uzorci su kako dobare namjere propadaju: God Object obično počinje kao mali pomoćnik, anemic model kao "samo DTO-i", zatim se osifikuje. Davanjem imena oni grupama daju zajedničkog rječnika za rano upozorenje u pregledu koda, i svaki anti-uzorak izravno pokazuje na princip (SRP, kompozicija, enkapsulacija) koji ga ispravlja.