Kokie yra bendrieji OOP anti-modeliai?

Question

Accepted Answer

Anti-modeliai yra pasikartojantys „sprendimai", kurie atrodo pagrįsti, tačiau pablogina dizainą. Dažniausi OOP yra **God Object**, **gili paveldimų hierarchija** ir **Anemic Domain Model**. ## God Object Klasė, kuri žino ir daro per daug — pažeidžia 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...) ``` ## Gili paveldimų hierarchija ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` Kiekvienas lygis susietas su visais protėviais; pokytis šioje viršuje sklinda visur (trapus bazinis klasė). **Fix:** suploškite su composition; pageidaukite "has-a" galimybių virš gilių "is-a" grandinių. ## Anemic Domain Model Objektai, kurie yra tik getter/setter maišai su visa logika kitur — OOP tik vardu. ```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(); } } ``` ## Kiti verti paminėjimo ```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) ``` ## Kodėl tai svarbu Anti-modeliai yra tai, kaip geros ketinimas subyra: God Object paprastai prasideda kaip mažas pagalbininkas, aneminis modelis kaip "tik DTO", o paskui sukietėja. Jų pavadinimas suteikia komandai bendrą ankstyvojo perspėjimo žodyną kodo peržiūroje, ir kiekvienas anti-modelis tiesiogiai nurodo į principą (SRP, composition, encapsulation), kuris jį ištaiso.