[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":91,"_72":92,"_35":93},"articles",{"_11":12,"_13":14,"_15":16,"_17":16,"_18":19,"_20":21,"_22":23,"_24":23,"_25":16,"_26":27},"content",[30],"pageable",{"_28":21,"_29":19},"totalElements",1,"totalPages","size",10,"number",0,"first",true,"last","numberOfElements","empty",false,"page_number","page_size",{"_31":32,"_33":34,"_35":36,"_37":38,"_11":39,"_40":-5,"_41":23,"_42":27,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_53":52,"_54":55,"_56":57,"_58":59,"_60":52,"_61":16,"_62":63,"_64":65,"_66":67,"_68":69,"_70":71},"id",5,"title","Code Smells Catalog","slug","clean-code-part-4-code-smells","excerpt","Comprehensive catalog of 22 core code smells organized by categories (bloaters, OO abusers, change preventers, dispensables, couplers) with detection and refactoring guidance.","# Advanced Clean Code Patterns Part 4: Code Smells - Complete Catalog\n\nCode smells are surface indications of deeper problems. Like symptoms of an illness, they don't tell you exactly what's wrong, but they point you in the right direction. This article provides a comprehensive catalog of code smells with detection techniques, examples, and recommended refactorings.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Total Smells Covered | 22 core smells |\n| Categories | Bloaters, OO Abusers, Change Preventers, Dispensables, Couplers |\n| Detection Tools | SonarQube, IntelliJ inspections, SpotBugs |\n| Key Insight | Smell = Symptom, not disease |\n| Business Impact | Early smell detection prevents 60% of major refactorings |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter reading this article, you will be able to:\n\n- **Recognize all major code smells** at a glance\n- **Understand the root causes** behind each smell\n- **Apply appropriate refactorings** for each smell\n- **Configure tools** for automatic smell detection\n- **Prioritize smells** based on impact and fix difficulty\n- **Use smells in code reviews** constructively\n\n---\n\n## 🔥 Production Story: The Thousand-Line Method\n\nA team inherited a legacy e-commerce system. The checkout method was legendary:\n\n```java\npublic class CheckoutService {\n public OrderResult checkout(Cart cart) {\n // Line 1-150: Validate cart\n // Line 151-280: Calculate totals\n // Line 281-420: Apply discounts\n // Line 421-580: Process payment\n // Line 581-720: Update inventory\n // Line 721-850: Send notifications\n // Line 851-980: Generate reports\n // Line 981-1047: Cleanup and logging\n return result;\n }\n}\n```\n\n**The symptoms:**\n- Bug fixes took 2 days minimum (half day just to understand the code)\n- Every change broke something else\n- No one could test it properly (integration test took 8 minutes)\n- New developers avoided touching it\n\n**The smells present:**\n- Long Method (1,047 lines)\n- Feature Envy (reached into 12 different classes)\n- Data Clumps (same 5 parameters passed everywhere)\n- Comments (100+ comments explaining \"what\" instead of \"why\")\n- Duplicate Code (discount logic repeated 4 times with variations)\n\n**The fix:** 3 weeks of systematic refactoring:\n- Extracted 14 focused methods\n- Created 6 collaborating services\n- Introduced Parameter Objects for data clumps\n- Result: Each method < 20 lines, 90% test coverage, bugs fixed in hours\n\n---\n\n## 🧠 Mental Model: Smell Categories\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ CODE SMELL TAXONOMY │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ 🐘 BLOATERS (Things that grow too big) │\n│ ├── Long Method │\n│ ├── Large Class │\n│ ├── Primitive Obsession │\n│ ├── Long Parameter List │\n│ └── Data Clumps │\n│ │\n│ 🔀 OO ABUSERS (Misuse of OO features) │\n│ ├── Switch Statements │\n│ ├── Temporary Field │\n│ ├── Refused Bequest │\n│ └── Alternative Classes with Different Interfaces │\n│ │\n│ 🚧 CHANGE PREVENTERS (Make changes difficult) │\n│ ├── Divergent Change │\n│ ├── Shotgun Surgery │\n│ └── Parallel Inheritance Hierarchies │\n│ │\n│ 🗑️ DISPENSABLES (Unnecessary code) │\n│ ├── Comments (excessive) │\n│ ├── Duplicate Code │\n│ ├── Lazy Class │\n│ ├── Dead Code │\n│ └── Speculative Generality │\n│ │\n│ 🔗 COUPLERS (Excessive coupling) │\n│ ├── Feature Envy │\n│ ├── Inappropriate Intimacy │\n│ ├── Message Chains │\n│ └── Middle Man │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n---\n\n## 🔬 Deep Dive: Complete Smell Catalog\n\n### Category 1: Bloaters\n\n#### Long Method\n\n**What:** Method that's too long to understand at a glance.\n\n**Threshold:** > 20 lines (some say 10)\n\n**Symptoms:**\n- Multiple levels of abstraction in one method\n- Comments separating \"sections\"\n- Scrolling required to read method\n- Multiple responsibilities\n\n```java\n// ❌ Long Method (70+ lines)\npublic Invoice createInvoice(Order order) {\n // Validate order\n if (order == null) {\n throw new IllegalArgumentException(\"Order cannot be null\");\n }\n if (order.getItems() == null || order.getItems().isEmpty()) {\n throw new InvalidOrderException(\"Order must have items\");\n }\n for (OrderItem item : order.getItems()) {\n if (item.getQuantity() <= 0) {\n throw new InvalidOrderException(\"Invalid quantity\");\n }\n }\n\n // Calculate line items\n List lineItems = new ArrayList<>();\n BigDecimal subtotal = BigDecimal.ZERO;\n for (OrderItem item : order.getItems()) {\n BigDecimal lineTotal = item.getPrice()\n .multiply(BigDecimal.valueOf(item.getQuantity()));\n lineItems.add(new InvoiceLineItem(\n item.getProduct().getName(),\n item.getQuantity(),\n item.getPrice(),\n lineTotal\n ));\n subtotal = subtotal.add(lineTotal);\n }\n\n // Apply discounts\n BigDecimal discount = BigDecimal.ZERO;\n if (order.getCustomer().isVip()) {\n discount = subtotal.multiply(new BigDecimal(\"0.1\"));\n }\n if (order.getCoupon() != null) {\n discount = discount.add(order.getCoupon().getDiscount(subtotal));\n }\n\n // Calculate tax\n BigDecimal taxableAmount = subtotal.subtract(discount);\n BigDecimal tax = taxableAmount.multiply(new BigDecimal(\"0.21\"));\n\n // Calculate total\n BigDecimal total = taxableAmount.add(tax);\n\n // ... 30 more lines for creating invoice, audit log, etc.\n}\n\n// ✅ After Extract Method\npublic Invoice createInvoice(Order order) {\n validateOrder(order);\n List lineItems = createLineItems(order);\n BigDecimal subtotal = calculateSubtotal(lineItems);\n BigDecimal discount = calculateDiscount(order, subtotal);\n BigDecimal tax = calculateTax(subtotal, discount);\n return buildInvoice(order, lineItems, subtotal, discount, tax);\n}\n\nprivate void validateOrder(Order order) { /* ... */ }\nprivate List createLineItems(Order order) { /* ... */ }\nprivate BigDecimal calculateSubtotal(List items) { /* ... */ }\nprivate BigDecimal calculateDiscount(Order order, BigDecimal subtotal) { /* ... */ }\nprivate BigDecimal calculateTax(BigDecimal subtotal, BigDecimal discount) { /* ... */ }\n```\n\n**Refactoring:** Extract Method, Replace Temp with Query\n\n---\n\n#### Large Class (God Class)\n\n**What:** Class that does too much.\n\n**Threshold:** > 200-500 lines, > 15 public methods, > 10 fields\n\n**Symptoms:**\n- Class name includes \"Manager\", \"Processor\", \"Handler\", \"Util\"\n- Many unrelated methods\n- Multiple groups of methods using different fields\n- Difficult to name precisely\n\n```java\n// ❌ God Class\npublic class OrderManager {\n // Order operations\n public Order createOrder() { }\n public Order updateOrder() { }\n public void deleteOrder() { }\n\n // Payment operations\n public PaymentResult processPayment() { }\n public void refundPayment() { }\n\n // Inventory operations\n public void reserveInventory() { }\n public void releaseInventory() { }\n\n // Notification operations\n public void sendOrderConfirmation() { }\n public void sendShippingNotification() { }\n\n // Reporting operations\n public Report generateDailyReport() { }\n public Report generateMonthlyReport() { }\n\n // 300+ more lines...\n}\n\n// ✅ After Extract Class\npublic class OrderService {\n public Order createOrder() { }\n public Order updateOrder() { }\n public void deleteOrder() { }\n}\n\npublic class PaymentService {\n public PaymentResult processPayment() { }\n public void refundPayment() { }\n}\n\npublic class InventoryService {\n public void reserveInventory() { }\n public void releaseInventory() { }\n}\n\n// etc.\n```\n\n**Refactoring:** Extract Class, Extract Subclass, Extract Interface\n\n---\n\n#### Primitive Obsession\n\n**What:** Using primitives instead of small objects for domain concepts.\n\n**Symptoms:**\n- String for email, phone, currency code\n- int for quantities, amounts, IDs\n- Validation logic scattered everywhere\n\n```java\n// ❌ Primitive Obsession\npublic class User {\n private String email; // Should be Email\n private String phoneNumber; // Should be PhoneNumber\n private String zipCode; // Should be ZipCode\n private int age; // Maybe should be Age or Birthdate\n\n public void setEmail(String email) {\n // Validation duplicated everywhere this is used\n if (!email.contains(\"@\")) {\n throw new IllegalArgumentException(\"Invalid email\");\n }\n this.email = email;\n }\n}\n\n// ✅ After: Value Objects\npublic record Email(String value) {\n public Email {\n if (value == null || !value.matches(\"^[\\\\w.-]+@[\\\\w.-]+\\\\.[a-z]{2,}$\")) {\n throw new IllegalArgumentException(\"Invalid email: \" + value);\n }\n }\n}\n\npublic record PhoneNumber(String value) {\n public PhoneNumber {\n String cleaned = value.replaceAll(\"[^0-9]\", \"\");\n if (cleaned.length() < 10) {\n throw new IllegalArgumentException(\"Invalid phone: \" + value);\n }\n }\n\n public String formatted() {\n // Formatting logic in one place\n }\n}\n\npublic class User {\n private Email email;\n private PhoneNumber phoneNumber;\n // Validation guaranteed by construction\n}\n```\n\n**Refactoring:** Replace Primitive with Object, Introduce Parameter Object\n\n---\n\n#### Long Parameter List\n\n**What:** Method with too many parameters.\n\n**Threshold:** > 3-4 parameters\n\n**Symptoms:**\n- Easy to mix up parameter order\n- Boolean parameters (what does `true` mean?)\n- Many parameters of same type\n\n```java\n// ❌ Long Parameter List\npublic Order createOrder(\n Long customerId,\n String customerName,\n String customerEmail,\n String shippingStreet,\n String shippingCity,\n String shippingZip,\n String shippingCountry,\n String billingStreet,\n String billingCity,\n String billingZip,\n String billingCountry,\n boolean expedited,\n boolean giftWrap,\n String giftMessage) {\n // Which string is which?\n}\n\n// ✅ After: Parameter Objects\npublic Order createOrder(CreateOrderRequest request) {\n // Clear, self-documenting\n}\n\npublic record CreateOrderRequest(\n Customer customer,\n Address shippingAddress,\n Address billingAddress,\n ShippingOptions shippingOptions,\n GiftOptions giftOptions\n) {}\n\npublic record ShippingOptions(boolean expedited) {}\npublic record GiftOptions(boolean wrap, String message) {}\n```\n\n**Refactoring:** Introduce Parameter Object, Preserve Whole Object\n\n---\n\n#### Data Clumps\n\n**What:** Same group of data appears together in multiple places.\n\n**Symptoms:**\n- Same 3+ parameters passed to multiple methods\n- Same fields in multiple classes\n- Same local variables declared together\n\n```java\n// ❌ Data Clumps\npublic void sendEmail(String email, String firstName, String lastName) { }\npublic void printLabel(String firstName, String lastName, String street,\n String city, String zip) { }\npublic void validateUser(String email, String firstName, String lastName) { }\n\npublic class Order {\n private String shippingStreet;\n private String shippingCity;\n private String shippingZip;\n private String shippingCountry;\n}\n\npublic class Customer {\n private String addressStreet;\n private String addressCity;\n private String addressZip;\n private String addressCountry;\n}\n\n// ✅ After: Extract Class\npublic record PersonName(String firstName, String lastName) {\n public String fullName() { return firstName + \" \" + lastName; }\n}\n\npublic record Address(String street, String city, String zip, String country) {\n public String formatted() { /* ... */ }\n}\n\npublic void sendEmail(Email email, PersonName name) { }\npublic void printLabel(PersonName name, Address address) { }\n```\n\n**Refactoring:** Extract Class, Introduce Parameter Object\n\n---\n\n### Category 2: Object-Orientation Abusers\n\n#### Switch Statements\n\n**What:** Complex switch/if-else chains, especially on type.\n\n**Symptoms:**\n- Switch on type field\n- Same switch repeated in multiple places\n- Adding new type requires changes everywhere\n\n```java\n// ❌ Switch on type\npublic BigDecimal calculateArea(Shape shape) {\n return switch (shape.getType()) {\n case CIRCLE -> Math.PI * shape.getRadius() * shape.getRadius();\n case RECTANGLE -> shape.getWidth() * shape.getHeight();\n case TRIANGLE -> 0.5 * shape.getBase() * shape.getHeight();\n // Add new shape = modify this method AND every other switch\n };\n}\n\n// ✅ After: Polymorphism\npublic sealed interface Shape permits Circle, Rectangle, Triangle {\n BigDecimal area();\n}\n\npublic record Circle(double radius) implements Shape {\n public BigDecimal area() {\n return BigDecimal.valueOf(Math.PI * radius * radius);\n }\n}\n\npublic record Rectangle(double width, double height) implements Shape {\n public BigDecimal area() {\n return BigDecimal.valueOf(width * height);\n }\n}\n```\n\n**Refactoring:** Replace Conditional with Polymorphism, Replace Type Code with State/Strategy\n\n---\n\n#### Temporary Field\n\n**What:** Field that's only used in certain circumstances.\n\n**Symptoms:**\n- Field is null/default most of the time\n- Complex conditionals check if field is set\n- Field only populated for specific operations\n\n```java\n// ❌ Temporary Field\npublic class Order {\n private Report report; // Only set during reporting\n\n public void generateReport() {\n this.report = new Report();\n this.report.addLine(/* ... */);\n // ...\n }\n\n public void printReport() {\n if (this.report == null) {\n throw new IllegalStateException(\"Report not generated\");\n }\n this.report.print();\n }\n}\n\n// ✅ After: Extract Class or local variable\npublic class Order {\n public Report generateReport() {\n Report report = new Report();\n report.addLine(/* ... */);\n return report; // Return instead of storing\n }\n}\n\n// Or Extract Class\npublic class OrderReportGenerator {\n public Report generate(Order order) {\n Report report = new Report();\n // ...\n return report;\n }\n}\n```\n\n**Refactoring:** Extract Class, Introduce Null Object\n\n---\n\n#### Refused Bequest\n\n**What:** Subclass doesn't use or want inherited behavior.\n\n**Symptoms:**\n- Overriding methods to throw UnsupportedOperationException\n- Empty overrides\n- Ignoring inherited fields\n\n```java\n// ❌ Refused Bequest\npublic class Bird {\n public void fly() { }\n public void eat() { }\n}\n\npublic class Penguin extends Bird {\n @Override\n public void fly() {\n throw new UnsupportedOperationException(\"Penguins can't fly!\");\n }\n}\n\n// ✅ After: Extract interface, composition\npublic interface Bird {\n void eat();\n}\n\npublic interface FlyingCreature {\n void fly();\n}\n\npublic class Sparrow implements Bird, FlyingCreature {\n public void eat() { }\n public void fly() { }\n}\n\npublic class Penguin implements Bird {\n public void eat() { }\n // No fly method - doesn't inherit unwanted behavior\n}\n```\n\n**Refactoring:** Replace Inheritance with Delegation, Extract Superclass/Interface\n\n---\n\n### Category 3: Change Preventers\n\n#### Divergent Change\n\n**What:** One class changed for multiple different reasons.\n\n**Symptoms:**\n- \"I have to change this class whenever...\"\n- Different parts of class change for different features\n- Multiple developers editing same class for different reasons\n\n```java\n// ❌ Divergent Change - changed for orders, payments, AND shipping\npublic class OrderProcessor {\n // Changed when order rules change\n public void validateOrder(Order order) { }\n\n // Changed when payment providers change\n public void processPayment(Order order) { }\n\n // Changed when shipping carriers change\n public void shipOrder(Order order) { }\n}\n\n// ✅ After: Single Responsibility\npublic class OrderValidator {\n public void validate(Order order) { }\n}\n\npublic class PaymentProcessor {\n public void process(Order order) { }\n}\n\npublic class ShippingService {\n public void ship(Order order) { }\n}\n```\n\n**Refactoring:** Extract Class (one per reason for change)\n\n---\n\n#### Shotgun Surgery\n\n**What:** Single change requires modifications to many classes.\n\n**Symptoms:**\n- Adding a field requires changes in 10 places\n- Small feature touches many files\n- Fear of making changes due to ripple effects\n\n```java\n// ❌ Shotgun Surgery - adding new currency affects many classes\npublic class PriceFormatter { /* format with currency */ }\npublic class PriceCalculator { /* math with currency */ }\npublic class PriceValidator { /* validate currency */ }\npublic class PriceConverter { /* convert currency */ }\npublic class PriceDisplay { /* show currency symbol */ }\n// Change currency handling = change ALL of these\n\n// ✅ After: Move Method, consolidate\npublic class Money {\n private BigDecimal amount;\n private Currency currency;\n\n public String format() { }\n public Money add(Money other) { }\n public boolean isValid() { }\n public Money convertTo(Currency target) { }\n public String displaySymbol() { }\n}\n// All currency logic in ONE place\n```\n\n**Refactoring:** Move Method, Move Field, Inline Class\n\n---\n\n#### Parallel Inheritance Hierarchies\n\n**What:** Creating a subclass in one hierarchy requires creating subclass in another.\n\n**Symptoms:**\n- Every Shape needs a ShapeFactory\n- Every Employee needs an EmployeeUI\n- Hierarchies mirror each other\n\n```java\n// ❌ Parallel Hierarchies\n// Hierarchy 1\nabstract class Shape { }\nclass Circle extends Shape { }\nclass Rectangle extends Shape { }\n\n// Hierarchy 2 (parallel - grows with Hierarchy 1)\nabstract class ShapeRenderer { }\nclass CircleRenderer extends ShapeRenderer { }\nclass RectangleRenderer extends ShapeRenderer { }\n\n// ✅ After: Merge or use composition\ninterface Renderable {\n void render(Graphics g);\n}\n\nclass Circle implements Renderable {\n public void render(Graphics g) {\n // Circle knows how to render itself\n }\n}\n\n// Or use strategy\nclass Shape {\n private RenderStrategy renderer;\n\n public void render(Graphics g) {\n renderer.render(this, g);\n }\n}\n```\n\n**Refactoring:** Move Method, Collapse Hierarchy\n\n---\n\n### Category 4: Dispensables\n\n#### Comments (Excessive)\n\n**What:** Comments that explain *what* code does instead of *why*.\n\n**Symptoms:**\n- Every line has a comment\n- Comments repeat what code says\n- Comments become outdated\n- Comments apologize for bad code\n\n```java\n// ❌ Bad Comments\npublic void process(Order order) {\n // Check if order is null\n if (order == null) {\n // Throw exception if null\n throw new IllegalArgumentException(\"Order is null\");\n }\n\n // Get the items from the order\n List items = order.getItems();\n\n // Loop through items\n for (Item item : items) {\n // Process each item\n processItem(item);\n }\n}\n\n// ✅ Self-documenting code + meaningful comments\npublic void processOrder(Order order) {\n requireNonNull(order, \"Order required\");\n\n // Business rule: Items must be processed in priority order\n // per regulation XYZ-123 (2024 compliance requirement)\n order.getItemsByPriority()\n .forEach(this::processItem);\n}\n```\n\n**Refactoring:** Extract Method, Rename Method, Introduce Assertion\n\n---\n\n#### Duplicate Code\n\n**What:** Same or similar code in multiple places.\n\n**Symptoms:**\n- Copy-paste patterns\n- Bug fixed in one place but not another\n- Same structure with slight variations\n\n```java\n// ❌ Duplicate Code\npublic class AdminController {\n public void createUser(UserDto dto) {\n if (dto.getEmail() == null || dto.getEmail().isBlank()) {\n throw new ValidationException(\"Email required\");\n }\n if (!dto.getEmail().contains(\"@\")) {\n throw new ValidationException(\"Invalid email\");\n }\n // ... create user\n }\n}\n\npublic class PublicController {\n public void registerUser(UserDto dto) {\n if (dto.getEmail() == null || dto.getEmail().isBlank()) {\n throw new ValidationException(\"Email required\");\n }\n if (!dto.getEmail().contains(\"@\")) {\n throw new ValidationException(\"Invalid email\");\n }\n // ... register user (SAME VALIDATION!)\n }\n}\n\n// ✅ After: Extract Method\npublic class EmailValidator {\n public void validate(String email) {\n if (email == null || email.isBlank()) {\n throw new ValidationException(\"Email required\");\n }\n if (!email.contains(\"@\")) {\n throw new ValidationException(\"Invalid email\");\n }\n }\n}\n```\n\n**Refactoring:** Extract Method, Extract Class, Pull Up Method, Form Template Method\n\n---\n\n#### Speculative Generality\n\n**What:** Code written for \"future needs\" that never come.\n\n**Symptoms:**\n- Abstract class with only one subclass\n- Parameters/options that are never used\n- Complex configuration for simple needs\n- \"We might need this someday\"\n\n```java\n// ❌ Speculative Generality\npublic interface DataProcessor {\n R process(T input, C context, ProcessingOptions options);\n}\n\npublic abstract class AbstractDataProcessor\n implements DataProcessor {\n // Complex framework for... one implementation\n}\n\npublic class UserDataProcessor\n extends AbstractDataProcessor {\n // The only implementation that will ever exist\n}\n\n// ✅ After: Keep it simple\npublic class UserDataProcessor {\n public UserResult process(User user) {\n // Just what we need, nothing more\n }\n}\n```\n\n**Refactoring:** Collapse Hierarchy, Inline Class, Remove Parameter\n\n---\n\n### Category 5: Couplers\n\n#### Feature Envy\n\n**What:** Method uses more features of another class than its own.\n\n**Symptoms:**\n- Method calls many getters on another object\n- Method manipulates another object's data extensively\n- Logic should probably live in the other class\n\n```java\n// ❌ Feature Envy - ShippingCalculator envies Order\npublic class ShippingCalculator {\n public BigDecimal calculate(Order order) {\n BigDecimal weight = BigDecimal.ZERO;\n for (OrderItem item : order.getItems()) {\n weight = weight.add(\n item.getProduct().getWeight()\n .multiply(BigDecimal.valueOf(item.getQuantity()))\n );\n }\n\n BigDecimal baseRate = order.getShippingAddress().getCountry()\n .equals(\"US\") ? new BigDecimal(\"5\") : new BigDecimal(\"15\");\n\n if (order.getCustomer().getMembershipLevel() == MembershipLevel.GOLD) {\n baseRate = baseRate.multiply(new BigDecimal(\"0.8\"));\n }\n\n return baseRate.add(weight.multiply(new BigDecimal(\"0.5\")));\n }\n}\n\n// ✅ After: Move Method to where data lives\npublic class Order {\n public BigDecimal totalWeight() {\n return items.stream()\n .map(item -> item.weight())\n .reduce(BigDecimal.ZERO, BigDecimal::add);\n }\n\n public BigDecimal calculateShipping() {\n BigDecimal baseRate = shippingAddress.getBaseRate();\n BigDecimal discount = customer.getShippingDiscount();\n BigDecimal weightCharge = totalWeight().multiply(WEIGHT_RATE);\n return baseRate.multiply(discount).add(weightCharge);\n }\n}\n```\n\n**Refactoring:** Move Method, Extract Method\n\n---\n\n#### Inappropriate Intimacy\n\n**What:** Classes that know too much about each other's internals.\n\n**Symptoms:**\n- Classes access each other's private data (via reflection or package-private)\n- Bi-directional dependencies\n- Changes in one class break the other\n\n```java\n// ❌ Inappropriate Intimacy\npublic class Order {\n Customer customer; // Package-private for \"convenience\"\n\n void applyDiscount() {\n // Directly manipulates customer's data\n customer.totalPurchases = customer.totalPurchases.add(getTotal());\n if (customer.totalPurchases.compareTo(new BigDecimal(\"1000\")) > 0) {\n customer.membershipLevel = MembershipLevel.GOLD;\n }\n }\n}\n\n// ✅ After: Proper encapsulation\npublic class Order {\n private final Customer customer;\n\n void complete() {\n customer.recordPurchase(getTotal()); // Tell, don't ask\n }\n}\n\npublic class Customer {\n private BigDecimal totalPurchases;\n private MembershipLevel membershipLevel;\n\n public void recordPurchase(BigDecimal amount) {\n this.totalPurchases = totalPurchases.add(amount);\n updateMembershipLevel();\n }\n\n private void updateMembershipLevel() {\n if (totalPurchases.compareTo(GOLD_THRESHOLD) > 0) {\n this.membershipLevel = MembershipLevel.GOLD;\n }\n }\n}\n```\n\n**Refactoring:** Move Method, Move Field, Change Bidirectional to Unidirectional\n\n---\n\n#### Message Chains\n\n**What:** Long chains of method calls navigating object structure.\n\n**Symptoms:**\n- `a.getB().getC().getD().doSomething()`\n- Violation of Law of Demeter\n- Tight coupling to object structure\n\n```java\n// ❌ Message Chain\npublic String getCustomerCity(Order order) {\n return order.getCustomer()\n .getAddress()\n .getCity()\n .getName();\n}\n// If any structure changes, this breaks\n\n// ✅ After: Hide Delegate\npublic class Order {\n public String getCustomerCityName() {\n return customer.getCityName();\n }\n}\n\npublic class Customer {\n public String getCityName() {\n return address.getCityName();\n }\n}\n\npublic class Address {\n public String getCityName() {\n return city.getName();\n }\n}\n```\n\n**Refactoring:** Hide Delegate, Extract Method, Move Method\n\n---\n\n#### Middle Man\n\n**What:** Class that only delegates to another class.\n\n**Symptoms:**\n- Most methods just call same method on another object\n- Class adds no value\n- Extra indirection without purpose\n\n```java\n// ❌ Middle Man\npublic class CustomerService {\n private CustomerRepository repository;\n\n public Customer findById(Long id) {\n return repository.findById(id);\n }\n\n public List findAll() {\n return repository.findAll();\n }\n\n public void save(Customer customer) {\n repository.save(customer);\n }\n\n public void delete(Long id) {\n repository.deleteById(id);\n }\n // Just forwarding everything - no added value!\n}\n\n// ✅ After: Remove Middle Man (or add actual behavior)\n// Option 1: Use repository directly\n@RestController\npublic class CustomerController {\n private final CustomerRepository repository; // Direct use\n\n @GetMapping(\"/{id}\")\n public Customer getCustomer(@PathVariable Long id) {\n return repository.findById(id)\n .orElseThrow(() -> new NotFoundException(id));\n }\n}\n\n// Option 2: Add actual behavior to justify service\n@Service\npublic class CustomerService {\n public Customer registerCustomer(RegistrationRequest request) {\n validateUniqueEmail(request.getEmail());\n Customer customer = createCustomer(request);\n sendWelcomeEmail(customer);\n return customer;\n }\n // Now there's actual logic!\n}\n```\n\n**Refactoring:** Remove Middle Man, Inline Method\n\n---\n\n## 📊 Smell Detection Tools Configuration\n\n### SonarQube Rules\n\n```yaml\n# sonar-project.properties\nsonar.java.source=17\n\n# Bloaters\nsonar.java.method.lines.max=30\nsonar.java.class.lines.max=500\nsonar.java.method.parameters.max=4\nsonar.java.method.complexity.max=10\n\n# Enable specific rules\nsonar.issue.ignore.multicriteria=e1\nsonar.issue.ignore.multicriteria.e1.ruleKey=java:S1192\nsonar.issue.ignore.multicriteria.e1.resourceKey=**/test/**\n```\n\n### IntelliJ Inspections\n\n```text\nSettings → Editor → Inspections → Java\n\nEnable:\n├── Class structure\n│ ├── Class with too many methods (>15)\n│ ├── Class with too many fields (>10)\n│ └── Method with too many parameters (>4)\n├── Code maturity\n│ ├── Unused declaration\n│ └── Redundant code\n├── Code style issues\n│ ├── Chained method calls (>3)\n│ └── Feature envy\n└── Probable bugs\n ├── Suspicious collections method calls\n └── Suspicious variable/parameter name\n```\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: Treating Smells as Absolutes\n\n**Problem:** Blindly following smell thresholds.\n\n```text\n❌ \"Method has 21 lines, must refactor!\"\n\n✅ \"Method has 21 lines. Is it cohesive and readable?\n If yes, it's fine. If not, let's improve it.\"\n```\n\n---\n\n### Mistake 2: Refactoring Without Tests\n\n**Problem:** Fixing smells while breaking functionality.\n\n```text\n❌ See smell → Refactor immediately → Hope it works\n\n✅ See smell → Add characterization tests → Refactor safely → Verify\n```\n\n---\n\n### Mistake 3: Over-Refactoring\n\n**Problem:** Creating new smells while fixing old ones.\n\n```text\nSmell: Long Method (50 lines)\nOver-fix: 25 tiny methods with no cohesion\n\nBetter: 5-7 cohesive methods with clear purposes\n```\n\n---\n\n## 🐛 Debug This: The Mystery of the Failing Refactoring\n\nA developer reports: \"I refactored this method to be shorter and now it doesn't work. But I only extracted methods - I didn't change any logic!\"\n\n```java\n// Before refactoring - worked fine\npublic class OrderProcessor {\n private Order currentOrder;\n\n public void processOrder(Order order) {\n currentOrder = order;\n\n validateOrder();\n calculateTotals();\n applyDiscounts();\n processPayment();\n sendConfirmation();\n\n currentOrder = null;\n }\n\n private void validateOrder() {\n if (currentOrder.getItems().isEmpty()) {\n throw new ValidationException(\"No items\");\n }\n }\n\n private void calculateTotals() {\n BigDecimal total = BigDecimal.ZERO;\n for (OrderItem item : currentOrder.getItems()) {\n total = total.add(item.getPrice());\n }\n currentOrder.setTotal(total);\n }\n\n // ... more methods using currentOrder\n}\n\n// After \"refactoring\" - now fails with NullPointerException\npublic class OrderProcessor {\n private Order currentOrder;\n\n public void processOrder(Order order) {\n currentOrder = order;\n executeSteps();\n currentOrder = null;\n }\n\n private void executeSteps() {\n List steps = Arrays.asList(\n () -> validateOrder(),\n () -> calculateTotals(),\n () -> new DiscountService().applyDiscounts(currentOrder), // Bug is here!\n () -> processPayment(),\n () -> sendConfirmation()\n );\n steps.parallelStream().forEach(Runnable::run); // Runs in parallel!\n }\n}\n```\n\n**Why does the refactored code fail? Find the hidden code smell!**\n\n---\n\n**✅ Solution:**\n\nThe root cause is a **Temporary Field smell** combined with unsafe parallelization:\n\n1. **Original problem:** `currentOrder` is a temporary field - it's only valid during `processOrder()`\n2. **Refactoring issue:** The new code uses `parallelStream()`, which executes lambdas in different threads\n3. **Race condition:** By the time some parallel steps run, `currentOrder` might already be null\n\n**The code smells:**\n- **Temporary Field:** `currentOrder` is set, used, then cleared - class state is inconsistent\n- **Mutable Shared State:** Field is modified during execution\n- **Hidden Coupling:** Methods implicitly depend on `currentOrder` being set\n\n**The lesson:** Temporary Field smell makes code fragile. When you pass data through fields instead of parameters, you create hidden dependencies that break under refactoring. Always prefer passing data explicitly.\n\n**Fix:** Pass `order` as parameter to each method instead of storing in field.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Smell Identification\n⭐ Difficulty: Easy | ⏱️ Time: 15 minutes\n\n**Task:** Identify all smells in this code:\n\n```java\npublic class DataProcessor {\n private Report tempReport;\n private boolean isProcessing;\n\n public void process(String type, String data, String format,\n boolean validate, boolean log, String output) {\n if (validate) {\n if (data == null || data.isEmpty()) {\n throw new RuntimeException(\"Invalid\");\n }\n // ... 20 more lines of validation\n }\n\n switch (type) {\n case \"CSV\":\n // 30 lines of CSV processing\n break;\n case \"JSON\":\n // 30 lines of JSON processing\n break;\n case \"XML\":\n // 30 lines of XML processing\n break;\n }\n\n if (log) {\n System.out.println(\"Processed: \" + data.substring(0, 10));\n }\n\n tempReport = new Report();\n tempReport.setData(data);\n }\n}\n```\n\n**Find:** Long Parameter List, Long Method, Switch Statements, Temporary Field, Primitive Obsession\n\n**✅ Solution:**\n\n| Smell | Location | Severity |\n|-------|----------|----------|\n| Long Parameter List | 6 parameters | High |\n| Long Method | 100+ lines implied | High |\n| Switch Statements | type-based switch | Medium |\n| Temporary Field | tempReport, isProcessing | Medium |\n| Primitive Obsession | String type, String format | Low |\n\n---\n\n### Exercise 2: Refactoring Practice\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Refactor this code to eliminate Feature Envy:\n\n```java\npublic class OrderPrinter {\n public void print(Order order) {\n System.out.println(\"Order #\" + order.getId());\n System.out.println(\"Customer: \" + order.getCustomer().getName());\n System.out.println(\"Address: \" + order.getCustomer().getAddress().getStreet()\n + \", \" + order.getCustomer().getAddress().getCity());\n\n BigDecimal total = BigDecimal.ZERO;\n for (OrderItem item : order.getItems()) {\n BigDecimal lineTotal = item.getProduct().getPrice()\n .multiply(BigDecimal.valueOf(item.getQuantity()));\n System.out.println(\" \" + item.getProduct().getName()\n + \" x \" + item.getQuantity() + \" = $\" + lineTotal);\n total = total.add(lineTotal);\n }\n System.out.println(\"Total: $\" + total);\n }\n}\n```\n\n**✅ Solution:**\n\n```java\n// Move behavior to the objects that own the data\npublic class Order {\n public String getFormattedHeader() {\n return \"Order #\" + id + \"\\nCustomer: \" + customer.getFullName();\n }\n public BigDecimal getTotal() { ... }\n}\n\npublic class Customer {\n public String getFullName() { return name; }\n public String getFormattedAddress() {\n return address.getStreet() + \", \" + address.getCity();\n }\n}\n\npublic class OrderItem {\n public BigDecimal getLineTotal() {\n return product.getPrice().multiply(BigDecimal.valueOf(quantity));\n }\n public String format() {\n return \" \" + product.getName() + \" x \" + quantity + \" = $\" + getLineTotal();\n }\n}\n\n// OrderPrinter now delegates to objects\npublic class OrderPrinter {\n public void print(Order order) {\n System.out.println(order.getFormattedHeader());\n System.out.println(\"Address: \" + order.getCustomer().getFormattedAddress());\n order.getItems().forEach(item -> System.out.println(item.format()));\n System.out.println(\"Total: $\" + order.getTotal());\n }\n}\n```\n\n---\n\n### Exercise 3: Code Smell Catalog\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Match each smell with its primary solution:\n\n| Smell | Solution |\n|-------|----------|\n| 1. Long Method | A. Replace with Strategy/Polymorphism |\n| 2. Long Parameter List | B. Extract Class |\n| 3. Data Clumps | C. Introduce Parameter Object |\n| 4. Switch Statements | D. Extract Method |\n| 5. Divergent Change | E. Move Method to appropriate class |\n| 6. Feature Envy | F. Create dedicated class for clumped data |\n\n**✅ Solution:**\n\n| Smell | Solution |\n|-------|----------|\n| Long Method | D. Extract Method |\n| Long Parameter List | C. Introduce Parameter Object |\n| Data Clumps | F. Create dedicated class for clumped data |\n| Switch Statements | A. Replace with Strategy/Polymorphism |\n| Divergent Change | B. Extract Class |\n| Feature Envy | E. Move Method to appropriate class |\n\n---\n\n### Exercise 4: Refactor Data Clumps\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 20 minutes\n\n**Task:** Identify and fix the Data Clumps smell:\n\n```java\npublic class UserService {\n public void createUser(String firstName, String lastName,\n String street, String city, String zipCode, String country,\n String email, String phone) { ... }\n\n public void updateAddress(Long userId,\n String street, String city, String zipCode, String country) { ... }\n\n public void validateAddress(String street, String city, String zipCode, String country) { ... }\n\n public BigDecimal calculateShipping(String street, String city, String zipCode, String country) { ... }\n}\n```\n\n**✅ Solution:**\n\n```java\n// Extract Data Clumps into value objects\npublic record Address(String street, String city, String zipCode, String country) {\n public boolean isValid() {\n return street != null && city != null && zipCode != null;\n }\n}\n\npublic record ContactInfo(String email, String phone) {}\n\npublic record UserName(String firstName, String lastName) {\n public String getFullName() { return firstName + \" \" + lastName; }\n}\n\n// Clean service\npublic class UserService {\n public void createUser(UserName name, Address address, ContactInfo contact) { ... }\n public void updateAddress(Long userId, Address address) { ... }\n public boolean validateAddress(Address address) { return address.isValid(); }\n public BigDecimal calculateShipping(Address address) { ... }\n}\n```\n\n---\n\n### Exercise 5: Complete Smell Audit\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 25 minutes\n\n**Task:** Perform a complete smell audit on this class and refactor:\n\n```java\npublic class ReportManager {\n private boolean initialized;\n private Connection conn;\n private String lastQuery;\n\n public void init(String host, int port, String user, String pass) {\n conn = DriverManager.getConnection(\"jdbc:\" + host + \":\" + port, user, pass);\n initialized = true;\n }\n\n public Report generate(String type, Date start, Date end, String format,\n boolean includeCharts, boolean sendEmail, String recipient) {\n if (!initialized) throw new IllegalStateException(\"Not initialized\");\n\n String query;\n switch (type) {\n case \"SALES\": query = \"SELECT * FROM sales WHERE...\"; break;\n case \"INVENTORY\": query = \"SELECT * FROM inventory WHERE...\"; break;\n case \"FINANCE\": query = \"SELECT * FROM finance WHERE...\"; break;\n default: throw new IllegalArgumentException(\"Unknown type\");\n }\n lastQuery = query;\n\n ResultSet rs = conn.executeQuery(query);\n Report report = new Report();\n\n // 100 lines of processing...\n\n if (sendEmail) {\n sendEmail(recipient, report);\n }\n\n return report;\n }\n}\n```\n\n**✅ Solution:**\n\nSmells found:\n1. **Temporary Fields:** `initialized`, `conn`, `lastQuery`\n2. **Long Parameter List:** 7 parameters\n3. **Switch Statements:** type-based branching\n4. **Long Method:** 100+ lines implied\n5. **Inappropriate Intimacy:** Direct DB connection handling\n6. **Feature Envy:** Email sending mixed with reporting\n\n```java\n// Clean refactoring\npublic record ReportRequest(\n ReportType type,\n DateRange dateRange,\n OutputFormat format,\n ChartOptions chartOptions\n) {}\n\npublic interface ReportGenerator {\n ReportType getType();\n Report generate(ReportRequest request);\n}\n\n@Service\npublic class ReportService {\n private final Map generators;\n private final ReportNotificationService notificationService;\n\n public Report generate(ReportRequest request, NotificationOptions notification) {\n ReportGenerator generator = generators.get(request.type());\n Report report = generator.generate(request);\n\n if (notification.shouldSend()) {\n notificationService.notify(report, notification);\n }\n\n return report;\n }\n}\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Question #1: How do you prioritize which smells to fix?\n\n**Strong answer:**\n\nI use a risk-based approach:\n\n1. **High priority:**\n - Smells in hot paths (frequently changed code)\n - Smells blocking new features\n - Smells causing production bugs\n\n2. **Medium priority:**\n - Smells in moderately changed code\n - Smells slowing down development\n\n3. **Low priority:**\n - Smells in stable, rarely-touched code\n - Cosmetic smells in working code\n\n**Formula:** `Priority = (Change Frequency × Bug Density × Business Impact)`\n\n---\n\n### Question #2: What's the relationship between smells and SOLID?\n\n**Strong answer:**\n\nSmells are symptoms of SOLID violations:\n\n| Smell | Usually Violates |\n|-------|------------------|\n| Long Method | SRP |\n| Large Class | SRP |\n| Divergent Change | SRP |\n| Shotgun Surgery | SRP (inverted) |\n| Switch Statements | OCP |\n| Refused Bequest | LSP |\n| Fat Interface smell | ISP |\n| Feature Envy | SRP, encapsulation |\n\nKnowing SOLID helps predict what refactoring to apply.\n\n---\n\n### Question #3: When should you NOT fix a code smell?\n\n**Strong answer:**\n\n1. **Code is being deleted soon** - waste of effort\n2. **No test coverage** - risk of breaking it\n3. **Deadline pressure** - log it, fix after\n4. **Code is stable and working** - \"ain't broke\"\n5. **Smell is intentional** (trade-off) - document why\n6. **Fix creates worse smell** - cure worse than disease\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Quick Reference Table\n\n| Category | Smell | Refactoring |\n|----------|-------|-------------|\n| Bloaters | Long Method | Extract Method |\n| Bloaters | Large Class | Extract Class |\n| Bloaters | Primitive Obsession | Value Object |\n| Bloaters | Long Parameter List | Parameter Object |\n| OO Abusers | Switch Statements | Polymorphism |\n| OO Abusers | Refused Bequest | Composition |\n| Change Preventers | Divergent Change | Extract Class |\n| Change Preventers | Shotgun Surgery | Move Method |\n| Dispensables | Duplicate Code | Extract Method |\n| Dispensables | Comments | Self-documenting code |\n| Couplers | Feature Envy | Move Method |\n| Couplers | Message Chains | Hide Delegate |\n\n### Detection Checklist\n\n- [ ] Method > 20 lines?\n- [ ] Class > 200 lines?\n- [ ] Parameters > 4?\n- [ ] Switch on type?\n- [ ] Same code in multiple places?\n- [ ] Method uses other class's data extensively?\n- [ ] Long chains of getters?\n\n---\n\n## 🏁 Conclusion\n\nCode smells are your early warning system. They tell you where problems are brewing before they become crises. Learn to recognize them, and you'll catch issues while they're still easy to fix.\n\n**Key insight:** Smells are symptoms, not diseases. The same smell can have different causes and need different solutions. Use your judgment.\n\n**Your next step:** Continue to Part 5 (Code Quality Metrics Framework) to learn how to measure code quality objectively.\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review Code Smells Catalog table | 5 min |\n| Day 3 | Redo Exercise 1 (Smell Identification) | 15 min |\n| Day 7 | Answer interview questions without looking | 10 min |\n| Day 14 | Redo Debug This (Temporary Field paradox) | 10 min |\n| Day 30 | Audit one class in your project for code smells | 15 min |\n\n---\n\n*Next in series: [Part 5: Code Quality Metrics Framework]*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.672443Z","createdAt","2026-06-10T07:19:24.673720Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",24,"estimatedReadingTime","authorId",3,"authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder",4,"author",{"_31":55,"_97":57,"_98":99,"_100":101,"_102":-5,"_103":-5,"_104":-5,"_105":-5,"_106":-5},"category",{"_31":32,"_72":59,"_35":94,"_75":95,"_96":-5},"tags",[78,79,80,81],"series",{"_31":16,"_72":73,"_35":74,"_75":76,"_77":23},"name","Advanced Clean Code Patterns: From Principles to Production Mastery","advanced-clean-code-patterns","description","A comprehensive 26-part series covering enterprise-grade clean code patterns for Java developers. From SOLID principles and code smells through refactoring patterns, error handling, validation, to legacy modernization and modern Java 21+ features. Includes real production stories, mental models, exercises, and 150+ interview questions.","isActive",{"_31":91,"_72":92,"_35":93},{"_31":88,"_72":89,"_35":90},{"_31":85,"_72":86,"_35":87},{"_31":82,"_72":83,"_35":84},33,"Technical Debt","technical-debt",31,"Refactoring","refactoring",30,"Code Smells","code-smells",32,"Anti-patterns","anti-patterns","java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]