Hvad er almindelige OOP anti-patterns?

Question

Accepted Answer

Anti-patterns er tilbagevendende "løsninger", der virker rimelige, men forværrer et design. De mest almindelige i OOP er **God Object**, **dybe arvehierarkier** og **Anemic Domain Model**. ## God Object En klasse, der ved og gør for meget — krænker 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...) ``` ## Dybe arvehierarkier ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` Hvert niveau kobler sig til alle forfædre; en ændring tæt på toppen spreder sig overalt (fragile base class). **Løsning:** fladtrykkelse med composition; foretrækk "has-a"-evner frem for dybe "is-a"-kæder. ## Anemic Domain Model Objekter, der blot er poser af getters/setters med al logik andetsteds — OOP kun i navn. ```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(); } } ``` ## Andre mønstre værd at nævne ```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) ``` ## Hvorfor det betyder noget Anti-patterns er sådan gode intentioner forringer: et God Object starter normalt som en lille hjælper, en anemisk model som "bare DTOs", og bliver derefter forsteninger. At navngive dem giver teams et fælles ordforråd for tidlig advarsel i kodegennemsyn, og hvert anti-pattern peger direkte på det princip (SRP, composition, encapsulation), der reparerer det.