Vilka är vanliga OOP anti-mönster?

Question

Accepted Answer

Anti-mönster är återkommande "lösningar" som verkar rimliga men försämrar en design. De vanligaste inom OOP är **God Object**, **djupa arvshierarkier** och **Anemic Domain Model**. ## God Object En klass som vet och gör för mycket – bryter mot 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...) ``` ## Djupa arvshierarkier ```text Entity → LivingThing → Animal → Mammal → Carnivore → Feline → Cat → HouseCat ``` Varje nivå är kopplat till alla förfäder; en ändring nära toppen återverkar överallt (spröd basklass). **Fix:** platta till med komposition; föredra "har-en" förmågor över djupa "är-en" kedjor. ## Anemic Domain Model Objekt som bara är påsar av getters/setters med all logik någon annanstans – OOP endast i namn. ```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(); } } ``` ## Andra värda att nämna ```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) ``` ## Varför det spelar roll Anti-mönster är hur goda avsikter förtvinar: en God Object börjar vanligtvis som en liten hjälpare, en anemic modell som "bara DTO:er", sedan förstenas. Att namnge dem ger lag ett gemensamt tidigvarnings-ordförråd vid kodgranskning, och varje anti-mönster pekar direkt på principen (SRP, komposition, inkapsling) som fixar det.