[{"_1":2,"_3":-5,"_4":-5},"loaderData",{"_5":6},"actionData","errors","routes/blog-tag",{"_7":8,"_9":10},"tag",{"_31":91,"_71":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":32,"_55":56,"_57":58,"_59":52,"_60":16,"_61":62,"_63":64,"_65":66,"_67":68,"_69":70},"id",3,"title","SOLID: SRP and OCP","slug","clean-code-part-2-solid-srp-ocp","excerpt","Deep dive into Single Responsibility and Open/Closed principles with practical metrics (LCOM), real production stories, and techniques for fixing God Classes.","# Advanced Clean Code Patterns Part 2: SOLID - Single Responsibility & Open/Closed\n\nSOLID principles are the foundation of object-oriented design. Yet most developers can recite them but struggle to apply them. This article dives deep into the first two principles - Single Responsibility and Open/Closed - with practical examples, metrics for detection, and real refactoring patterns.\n\n## 📋 At a Glance\n\n| Aspect | Details |\n|--------|---------|\n| Principles Covered | SRP (Single Responsibility), OCP (Open/Closed) |\n| Key Metric | LCOM (Lack of Cohesion of Methods) |\n| Detection Tools | SonarQube, IntelliJ inspections |\n| Refactoring Pattern | Extract Class, Strategy Pattern |\n| Business Impact | 60% reduction in change-related bugs |\n\n---\n\n## 🎯 What You'll Learn\n\nAfter reading this article, you will be able to:\n\n- **Define \"responsibility\" precisely** using the actor-based definition\n- **Measure cohesion** using LCOM and other metrics\n- **Identify God Classes** and refactor them systematically\n- **Apply OCP** using Strategy, Decorator, and Plugin patterns\n- **Avoid over-application** of SOLID (when to break the rules)\n- **Answer senior interview questions** about SOLID with depth\n\n---\n\n## 🔥 Production Story: The 47-Responsibility Service\n\nA payment processing company had a class called `PaymentService`. It started simple:\n\n```java\n// Year 1: Simple, focused\npublic class PaymentService {\n public PaymentResult processPayment(Payment payment) { ... }\n}\n```\n\nOver three years, it grew:\n\n```java\n// Year 3: The God Class\npublic class PaymentService {\n // Payment processing (original)\n public PaymentResult processPayment(Payment payment) { ... }\n public void refundPayment(String paymentId) { ... }\n\n // Fraud detection (added in Year 1)\n public FraudScore calculateFraudScore(Payment payment) { ... }\n public void reportFraudulentPayment(String paymentId) { ... }\n\n // Reporting (added in Year 2)\n public PaymentReport generateDailyReport() { ... }\n public PaymentReport generateMerchantReport(String merchantId) { ... }\n\n // Notifications (added in Year 2)\n public void sendPaymentConfirmation(Payment payment) { ... }\n public void sendRefundNotification(Refund refund) { ... }\n\n // Compliance (added in Year 3)\n public void exportForAudit(DateRange range) { ... }\n public ComplianceReport generatePCIReport() { ... }\n\n // Analytics (added in Year 3)\n public void trackPaymentMetrics(Payment payment) { ... }\n public Dashboard getPaymentDashboard() { ... }\n\n // ... 35 more methods\n}\n```\n\n**The problems:**\n\n```text\nLines of code: 3,400\nMethods: 47\nDependencies: 23 injected services\nTest file: 8,000 lines\nTest runtime: 12 minutes\nChanges per month: 15 (from 5 different teams)\nBug rate: 4x higher than average\n```\n\n**The cost:** Every change required understanding the entire 3,400-line file. Every test run took 12 minutes. Every bug fix risked breaking something else. Five different teams (Payments, Fraud, Reporting, Compliance, Analytics) had to coordinate for any change.\n\n**The fix took 3 weeks:**\n\n```java\n// After: Focused services\nPaymentProcessor // 200 lines - payments team\nFraudDetectionService // 180 lines - fraud team\nPaymentReportingService // 150 lines - reporting team\nPaymentNotificationService // 120 lines - notifications team\nComplianceExportService // 200 lines - compliance team\nPaymentAnalyticsService // 160 lines - analytics team\n```\n\n**The results:**\n\n```text\nAverage service size: 170 lines (was 3,400)\nTest runtime: 45 seconds per service (was 12 minutes total)\nBug rate: Dropped 75%\nChange coordination: None needed (team owns their service)\n```\n\n---\n\n## 🧠 Mental Model: Responsibility = Reason to Change\n\nThe most common misunderstanding of SRP: thinking \"responsibility\" means \"thing the code does.\"\n\n**Wrong interpretation:** \"This class does one thing - it handles payments.\"\n\n**Correct interpretation:** \"This class has one reason to change - changes requested by one actor/stakeholder.\"\n\n```text\n┌─────────────────────────────────────────────────────────────────┐\n│ SRP: ACTOR-BASED VIEW │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ ACTOR = Stakeholder who requests changes │\n│ │\n│ ┌─────────────┐ requests ┌─────────────┐ │\n│ │ CFO │───────changes───→│ Reporting │ │\n│ │ (Finance) │ to │ Logic │ │\n│ └─────────────┘ └─────────────┘ │\n│ │\n│ ┌─────────────┐ requests ┌─────────────┐ │\n│ │ CTO │───────changes───→│ Technical │ │\n│ │ (Tech) │ to │ Logic │ │\n│ └─────────────┘ └─────────────┘ │\n│ │\n│ ┌─────────────┐ requests ┌─────────────┐ │\n│ │ COO │───────changes───→│ Operations │ │\n│ │ (Ops) │ to │ Logic │ │\n│ └─────────────┘ └─────────────┘ │\n│ │\n│ IF multiple actors request changes to SAME class │\n│ THEN SRP is violated │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n**Example:** An `Employee` class with methods for:\n- `calculatePay()` - requested by Accounting\n- `reportHours()` - requested by HR\n- `save()` - requested by IT/DBAs\n\nThree actors = three reasons to change = SRP violation.\n\n---\n\n## 🔬 Deep Dive\n\n### Part 1: Single Responsibility Principle (SRP)\n\n#### Detecting SRP Violations\n\n**Method 1: The Actor Test**\n\nAsk: \"Who would request a change to this method?\"\n\n```java\npublic class Employee {\n // ❌ SRP Violation - Multiple actors\n\n public Money calculatePay() {\n // Actor: Accounting department\n // They might change: tax rules, overtime calculation\n }\n\n public void reportHours() {\n // Actor: HR department\n // They might change: reporting format, categories\n }\n\n public void save() {\n // Actor: IT/Database team\n // They might change: storage mechanism, schema\n }\n}\n```\n\n**Method 2: LCOM Metric (Lack of Cohesion of Methods)**\n\nLCOM measures how related the methods in a class are:\n\n```text\nLCOM = (Number of method pairs sharing no fields) -\n (Number of method pairs sharing fields)\n\nLCOM = 0: Perfect cohesion\nLCOM > 0: Low cohesion (potential SRP violation)\n```\n\n**Example calculation:**\n\n```java\npublic class ReportService {\n private ReportRepository reportRepository;\n private EmailService emailService;\n private PdfGenerator pdfGenerator;\n\n // Uses: reportRepository\n public Report generateReport() { ... }\n\n // Uses: reportRepository, pdfGenerator\n public byte[] exportToPdf(Report report) { ... }\n\n // Uses: emailService\n public void sendReport(Report report, String email) { ... }\n}\n```\n\n```text\nMethod pairs:\n- generateReport & exportToPdf: Share reportRepository ✓\n- generateReport & sendReport: Share nothing ✗\n- exportToPdf & sendReport: Share nothing ✗\n\nLCOM = 2 - 1 = 1 (Low cohesion, consider splitting)\n```\n\n**Tools that calculate LCOM:**\n- SonarQube (LCOM4 metric)\n- IntelliJ (Metrics Reloaded plugin)\n- JDepend\n\n---\n\n#### Refactoring God Classes\n\n**Step-by-step process:**\n\n**Step 1: Identify responsibility clusters**\n\n```java\n// Original God Class\npublic class OrderService {\n // Cluster 1: Order Creation\n public Order createOrder(OrderRequest request) { ... }\n public void validateOrder(Order order) { ... }\n\n // Cluster 2: Payment\n public PaymentResult processPayment(Order order) { ... }\n public void refundOrder(Order order) { ... }\n\n // Cluster 3: Shipping\n public void shipOrder(Order order) { ... }\n public TrackingInfo getTrackingInfo(Order order) { ... }\n\n // Cluster 4: Notifications\n public void sendOrderConfirmation(Order order) { ... }\n public void sendShippingNotification(Order order) { ... }\n}\n```\n\n**Step 2: Create focused classes**\n\n```java\n// ✅ After: Focused services\n\npublic class OrderCreationService {\n public Order createOrder(OrderRequest request) { ... }\n public void validateOrder(Order order) { ... }\n}\n\npublic class OrderPaymentService {\n public PaymentResult processPayment(Order order) { ... }\n public void refundOrder(Order order) { ... }\n}\n\npublic class OrderShippingService {\n public void shipOrder(Order order) { ... }\n public TrackingInfo getTrackingInfo(Order order) { ... }\n}\n\npublic class OrderNotificationService {\n public void sendOrderConfirmation(Order order) { ... }\n public void sendShippingNotification(Order order) { ... }\n}\n```\n\n**Step 3: Create facade if needed**\n\n```java\n// Optional: Facade for backwards compatibility\npublic class OrderService {\n private final OrderCreationService creationService;\n private final OrderPaymentService paymentService;\n private final OrderShippingService shippingService;\n private final OrderNotificationService notificationService;\n\n public Order createAndProcessOrder(OrderRequest request) {\n Order order = creationService.createOrder(request);\n paymentService.processPayment(order);\n notificationService.sendOrderConfirmation(order);\n return order;\n }\n}\n```\n\n---\n\n### Part 2: Open/Closed Principle (OCP)\n\n**Definition:** Software entities should be open for extension but closed for modification.\n\n**Translation:** Add new behavior without changing existing code.\n\n#### Pattern 1: Strategy Pattern for OCP\n\n```java\n// ❌ Violates OCP - Must modify to add new payment type\npublic class PaymentProcessor {\n public void process(Payment payment) {\n switch (payment.getType()) {\n case CREDIT_CARD:\n processCreditCard(payment);\n break;\n case PAYPAL:\n processPayPal(payment);\n break;\n case BANK_TRANSFER:\n processBankTransfer(payment);\n break;\n // Adding new type requires modifying this class!\n }\n }\n}\n\n// ✅ Follows OCP - Add new types without modification\npublic interface PaymentStrategy {\n boolean supports(PaymentType type);\n PaymentResult process(Payment payment);\n}\n\n@Component\npublic class CreditCardStrategy implements PaymentStrategy {\n public boolean supports(PaymentType type) {\n return type == PaymentType.CREDIT_CARD;\n }\n\n public PaymentResult process(Payment payment) {\n // Credit card specific logic\n }\n}\n\n@Component\npublic class PayPalStrategy implements PaymentStrategy {\n public boolean supports(PaymentType type) {\n return type == PaymentType.PAYPAL;\n }\n\n public PaymentResult process(Payment payment) {\n // PayPal specific logic\n }\n}\n\n// Adding Bitcoin - NO MODIFICATION to existing code!\n@Component\npublic class BitcoinStrategy implements PaymentStrategy {\n public boolean supports(PaymentType type) {\n return type == PaymentType.BITCOIN;\n }\n\n public PaymentResult process(Payment payment) {\n // Bitcoin specific logic\n }\n}\n\n@Service\npublic class PaymentProcessor {\n private final List strategies;\n\n public PaymentProcessor(List strategies) {\n this.strategies = strategies;\n }\n\n public PaymentResult process(Payment payment) {\n return strategies.stream()\n .filter(s -> s.supports(payment.getType()))\n .findFirst()\n .orElseThrow(() -> new UnsupportedPaymentException(payment.getType()))\n .process(payment);\n }\n}\n```\n\n---\n\n#### Pattern 2: Decorator Pattern for OCP\n\n```java\n// Base interface\npublic interface NotificationSender {\n void send(Notification notification);\n}\n\n// Core implementation\n@Component\n@Primary\npublic class EmailNotificationSender implements NotificationSender {\n public void send(Notification notification) {\n // Send email\n }\n}\n\n// Decorator: Add logging without modifying original\n@Component\npublic class LoggingNotificationSender implements NotificationSender {\n private final NotificationSender delegate;\n private final Logger logger;\n\n public LoggingNotificationSender(\n @Qualifier(\"emailNotificationSender\") NotificationSender delegate) {\n this.delegate = delegate;\n this.logger = LoggerFactory.getLogger(getClass());\n }\n\n public void send(Notification notification) {\n logger.info(\"Sending notification: {}\", notification.getId());\n delegate.send(notification);\n logger.info(\"Notification sent: {}\", notification.getId());\n }\n}\n\n// Decorator: Add retry without modifying original\n@Component\npublic class RetryingNotificationSender implements NotificationSender {\n private final NotificationSender delegate;\n private final int maxRetries = 3;\n\n public void send(Notification notification) {\n for (int i = 0; i < maxRetries; i++) {\n try {\n delegate.send(notification);\n return;\n } catch (Exception e) {\n if (i == maxRetries - 1) throw e;\n }\n }\n }\n}\n```\n\n---\n\n#### Pattern 3: Plugin Architecture for OCP\n\n```java\n// Plugin interface\npublic interface ExportPlugin {\n String getFormat();\n byte[] export(Report report);\n}\n\n// Core plugins\n@Component\npublic class PdfExportPlugin implements ExportPlugin {\n public String getFormat() { return \"PDF\"; }\n public byte[] export(Report report) { /* PDF generation */ }\n}\n\n@Component\npublic class CsvExportPlugin implements ExportPlugin {\n public String getFormat() { return \"CSV\"; }\n public byte[] export(Report report) { /* CSV generation */ }\n}\n\n// Plugin registry - automatically discovers plugins\n@Service\npublic class ExportService {\n private final Map plugins;\n\n public ExportService(List plugins) {\n this.plugins = plugins.stream()\n .collect(Collectors.toMap(\n ExportPlugin::getFormat,\n Function.identity()\n ));\n }\n\n public byte[] export(Report report, String format) {\n ExportPlugin plugin = plugins.get(format);\n if (plugin == null) {\n throw new UnsupportedFormatException(format);\n }\n return plugin.export(report);\n }\n\n public Set getSupportedFormats() {\n return plugins.keySet();\n }\n}\n\n// Adding Excel export - just add new class!\n@Component\npublic class ExcelExportPlugin implements ExportPlugin {\n public String getFormat() { return \"XLSX\"; }\n public byte[] export(Report report) { /* Excel generation */ }\n}\n// No modification to ExportService needed!\n```\n\n---\n\n#### OCP with Java 17+ Sealed Classes\n\n```java\n// Sealed class hierarchy - compiler knows all subtypes\npublic sealed interface Notification\n permits EmailNotification, SmsNotification, PushNotification {\n}\n\npublic record EmailNotification(String to, String subject, String body)\n implements Notification {}\n\npublic record SmsNotification(String phoneNumber, String message)\n implements Notification {}\n\npublic record PushNotification(String deviceId, String title, String body)\n implements Notification {}\n\n// Pattern matching - compiler ensures exhaustiveness\npublic class NotificationService {\n public void send(Notification notification) {\n switch (notification) {\n case EmailNotification e -> sendEmail(e);\n case SmsNotification s -> sendSms(s);\n case PushNotification p -> sendPush(p);\n // Compiler error if new type added and not handled!\n }\n }\n}\n```\n\n**When to use Sealed Classes vs Strategy:**\n- **Sealed Classes:** Fixed set of types, rarely adding new ones\n- **Strategy:** Open set, frequently adding new implementations\n\n---\n\n## ⚠️ Common Mistakes\n\n### Mistake 1: One Method Per Class\n\n**Problem:** Taking SRP too literally.\n\n```java\n// ❌ Over-applied SRP\npublic class UserEmailValidator {\n public boolean validate(String email) { ... }\n}\n\npublic class UserPasswordValidator {\n public boolean validate(String password) { ... }\n}\n\npublic class UserNameValidator {\n public boolean validate(String name) { ... }\n}\n\n// ✅ Balanced: One cohesive validation service\npublic class UserValidator {\n public ValidationResult validate(UserRegistration registration) {\n return ValidationResult.combine(\n validateEmail(registration.getEmail()),\n validatePassword(registration.getPassword()),\n validateName(registration.getName())\n );\n }\n}\n```\n\n**Guideline:** Group methods that change together for the same reason.\n\n---\n\n### Mistake 2: Creating Abstractions for Single Implementations\n\n**Problem:** OCP dogma creating unnecessary indirection.\n\n```java\n// ❌ Over-abstracted - only one implementation exists\npublic interface UserRepository { ... }\npublic interface UserService { ... }\npublic interface UserValidator { ... }\npublic interface UserMapper { ... }\n\n// ✅ Practical - abstraction when needed\npublic class UserService {\n private final UserRepository repository; // Interface - has test double\n private final PasswordEncoder encoder; // Interface - security concern\n\n // No interface for UserMapper - it's internal implementation detail\n private UserDto toDto(User user) { ... }\n}\n```\n\n**Rule:** Create interface when you need multiple implementations OR for testing boundaries.\n\n---\n\n### Mistake 3: Shotgun Surgery After SRP Refactoring\n\n**Problem:** Over-splitting causes changes to touch many files.\n\n```text\nBefore: Change payment logic = modify 1 file\nAfter: Change payment logic = modify 8 files\n\nThis means you split by technical layer, not by business capability.\n```\n\n**Solution:** Split by business capability, not by technical layer.\n\n```java\n// ❌ Split by layer - shotgun surgery\nPaymentValidator\nPaymentProcessor\nPaymentPersistence\nPaymentNotifier\nPaymentLogger\nPaymentMetrics\n\n// ✅ Split by capability - cohesive\nPaymentService // All payment processing\nFraudDetectionService // All fraud logic\nPaymentReportingService // All reporting\n```\n\n---\n\n## 🐛 Debug This: The Class That Everyone Feared\n\nA developer reports: \"Every time we touch `OrderService`, something breaks. Last week, a change to shipping calculation broke the email notifications. How is that even possible?\"\n\n```java\npublic class OrderService {\n private OrderRepository orderRepository;\n private InventoryService inventoryService;\n private PaymentGateway paymentGateway;\n private EmailService emailService;\n private ShippingCalculator shippingCalculator;\n private AnalyticsService analyticsService;\n private NotificationService notificationService;\n\n public Order createOrder(OrderRequest request) {\n // Validate inventory\n inventoryService.reserve(request.getItems());\n\n // Calculate shipping\n BigDecimal shipping = shippingCalculator.calculate(request);\n\n // Process payment\n paymentGateway.charge(request.getPaymentMethod(), request.getTotal().add(shipping));\n\n // Save order\n Order order = orderRepository.save(toOrder(request, shipping));\n\n // Send notifications\n emailService.sendOrderConfirmation(order);\n notificationService.pushNotification(order.getCustomerId(), \"Order placed!\");\n\n // Track analytics\n analyticsService.trackOrder(order);\n\n return order;\n }\n\n // 25 more methods mixing all these concerns...\n}\n```\n\n**Why does changing shipping break email? Find the root cause!**\n\n---\n\n**✅ Solution:**\n\nThe root cause is **SRP violation creating hidden coupling**. The class has at least 6 different responsibilities:\n1. Order creation logic\n2. Inventory management\n3. Payment processing\n4. Email notifications\n5. Push notifications\n6. Analytics tracking\n\n**Why shipping broke email:** When all code is in one class, refactoring one method often requires touching shared dependencies. The developer likely:\n- Renamed a private method that email code also used\n- Changed the order of operations, affecting notification timing\n- Modified a shared data structure that both shipping and email relied on\n\n**The lesson:** SRP violations create invisible coupling. When a class does multiple things, changes to one responsibility ripple to others in unexpected ways. The solution is to split by actor/responsibility.\n\n---\n\n## 💻 Exercises\n\n### Exercise 1: Calculate LCOM\n⭐ Difficulty: Easy | ⏱️ Time: 15 minutes\n\n**Task:** Calculate LCOM for this class and determine if it violates SRP.\n\n```java\npublic class CustomerService {\n private CustomerRepository repository;\n private EmailService emailService;\n private ReportGenerator reportGenerator;\n\n public Customer findById(Long id) {\n return repository.findById(id);\n }\n\n public void save(Customer customer) {\n repository.save(customer);\n }\n\n public void sendWelcomeEmail(Customer customer) {\n emailService.send(customer.getEmail(), \"Welcome!\");\n }\n\n public Report generateCustomerReport() {\n return reportGenerator.generate(repository.findAll());\n }\n}\n```\n\n**Questions:**\n1. How many method pairs share fields?\n2. How many method pairs share no fields?\n3. What is the LCOM score?\n4. How would you refactor?\n\n**✅ Solution:**\n\n```text\nMethods that share fields:\n- findById, save → both use repository\n- sendWelcomeEmail → uses emailService (no overlap)\n- generateCustomerReport → uses reportGenerator AND repository\n\nLCOM calculation:\n- Method pairs: 6 (4 methods × 3 / 2)\n- Pairs sharing fields: 2 (findById-save, findById-generateCustomerReport)\n- LCOM = 6 - 2 = 4 (HIGH - indicates low cohesion)\n\nRefactoring:\n1. CustomerRepository (findById, save)\n2. CustomerNotificationService (sendWelcomeEmail)\n3. CustomerReportService (generateCustomerReport)\n```\n\n---\n\n### Exercise 2: Apply Strategy Pattern\n⭐⭐ Difficulty: Medium | ⏱️ Time: 20 minutes\n\n**Task:** Refactor this switch statement using Strategy pattern.\n\n```java\npublic class ShippingCalculator {\n public BigDecimal calculate(Order order) {\n switch (order.getShippingMethod()) {\n case STANDARD:\n return order.getWeight()\n .multiply(new BigDecimal(\"0.5\"))\n .add(new BigDecimal(\"5.00\"));\n case EXPRESS:\n return order.getWeight()\n .multiply(new BigDecimal(\"1.0\"))\n .add(new BigDecimal(\"10.00\"));\n case OVERNIGHT:\n return order.getWeight()\n .multiply(new BigDecimal(\"2.0\"))\n .add(new BigDecimal(\"25.00\"));\n case INTERNATIONAL:\n BigDecimal base = order.getWeight()\n .multiply(new BigDecimal(\"3.0\"));\n BigDecimal customs = new BigDecimal(\"15.00\");\n return base.add(customs).add(new BigDecimal(\"30.00\"));\n default:\n throw new IllegalArgumentException(\"Unknown shipping method\");\n }\n }\n}\n```\n\n**✅ Solution:**\n\n```java\n// Strategy interface\npublic interface ShippingStrategy {\n BigDecimal calculate(Order order);\n}\n\n// Implementations\npublic class StandardShipping implements ShippingStrategy {\n public BigDecimal calculate(Order order) {\n return order.getWeight().multiply(new BigDecimal(\"0.5\")).add(new BigDecimal(\"5.00\"));\n }\n}\n\npublic class ExpressShipping implements ShippingStrategy {\n public BigDecimal calculate(Order order) {\n return order.getWeight().multiply(new BigDecimal(\"1.0\")).add(new BigDecimal(\"10.00\"));\n }\n}\n\n// Factory to get strategy\npublic class ShippingStrategyFactory {\n private Map strategies;\n\n public ShippingStrategy getStrategy(ShippingMethod method) {\n return strategies.getOrDefault(method, new StandardShipping());\n }\n}\n```\n\n---\n\n### Exercise 3: Identify SRP Violations\n⭐⭐ Difficulty: Medium | ⏱️ Time: 15 minutes\n\n**Task:** Identify all SRP violations and list the actors for each responsibility.\n\n```java\npublic class ReportGenerator {\n private DataSource dataSource;\n private PdfLibrary pdfLibrary;\n private EmailClient emailClient;\n private S3Client s3Client;\n\n public Report queryData(ReportCriteria criteria) {\n // SQL queries, data transformation\n }\n\n public byte[] generatePdf(Report report) {\n // PDF formatting, layout, images\n }\n\n public void emailReport(byte[] pdf, String recipient) {\n // Email composition, sending\n }\n\n public String uploadToS3(byte[] pdf) {\n // S3 bucket management, URL generation\n }\n\n public void scheduleReport(ReportCriteria criteria, String cron) {\n // Scheduling logic, cron parsing\n }\n}\n```\n\n**✅ Solution:**\n\n| Responsibility | Actor | Reason to Change |\n|----------------|-------|------------------|\n| Data querying | DBA / Data Team | Schema changes |\n| PDF generation | Design Team | Layout/branding changes |\n| Email sending | Marketing Team | Email templates/rules |\n| S3 storage | DevOps | Infrastructure changes |\n| Scheduling | Product Team | Business schedule changes |\n\n**5 actors = 5 classes needed:**\n```java\nReportDataService // Queries and transforms data\nPdfReportRenderer // Creates PDF from data\nReportEmailSender // Handles email delivery\nReportStorageService // Manages S3 uploads\nReportScheduler // Handles scheduling logic\n```\n\n---\n\n### Exercise 4: Refactor God Class\n⭐⭐⭐ Difficulty: Medium-Hard | ⏱️ Time: 25 minutes\n\n**Task:** Refactor this God Class into cohesive services.\n\n```java\npublic class UserManager {\n // Authentication\n public User authenticate(String username, String password) { ... }\n public void logout(String sessionId) { ... }\n\n // Profile Management\n public void updateProfile(User user, ProfileData data) { ... }\n public void uploadAvatar(User user, byte[] image) { ... }\n\n // Password Management\n public void changePassword(User user, String newPassword) { ... }\n public void resetPassword(String email) { ... }\n\n // Notifications\n public void sendWelcomeEmail(User user) { ... }\n public void sendPasswordResetEmail(User user, String token) { ... }\n\n // Analytics\n public void trackLogin(User user) { ... }\n public UserAnalytics getAnalytics(Long userId) { ... }\n}\n```\n\n**✅ Solution:**\n\n```java\n// Split into 5 focused services:\n\n@Service\npublic class AuthenticationService {\n public User authenticate(String username, String password) { ... }\n public void logout(String sessionId) { ... }\n}\n\n@Service\npublic class ProfileService {\n public void updateProfile(User user, ProfileData data) { ... }\n public void uploadAvatar(User user, byte[] image) { ... }\n}\n\n@Service\npublic class PasswordService {\n public void changePassword(User user, String newPassword) { ... }\n public void resetPassword(String email) { ... }\n}\n\n@Service\npublic class UserNotificationService {\n public void sendWelcomeEmail(User user) { ... }\n public void sendPasswordResetEmail(User user, String token) { ... }\n}\n\n@Service\npublic class UserAnalyticsService {\n public void trackLogin(User user) { ... }\n public UserAnalytics getAnalytics(Long userId) { ... }\n}\n```\n\n---\n\n### Exercise 5: Design for Extension (OCP)\n⭐⭐⭐⭐ Difficulty: Hard | ⏱️ Time: 30 minutes\n\n**Task:** Design a payment system that follows OCP - new payment methods can be added without modifying existing code.\n\n**Requirements:**\n- Support Credit Card, PayPal, Bank Transfer\n- Easy to add new methods (Crypto, Apple Pay)\n- Each method has different validation rules\n- Each method has different fee calculation\n\n**✅ Solution:**\n\n```java\n// Extension point - interface\npublic interface PaymentMethod {\n boolean validate(PaymentRequest request);\n BigDecimal calculateFee(BigDecimal amount);\n PaymentResult process(PaymentRequest request);\n}\n\n// Closed for modification, open for extension\n@Service\npublic class PaymentProcessor {\n private final Map methods;\n\n public PaymentResult process(PaymentRequest request) {\n PaymentMethod method = methods.get(request.getType());\n if (!method.validate(request)) {\n return PaymentResult.invalid(\"Validation failed\");\n }\n BigDecimal fee = method.calculateFee(request.getAmount());\n request.setFee(fee);\n return method.process(request);\n }\n}\n\n// Adding new method requires ZERO changes to PaymentProcessor\n@Component\npublic class CryptoPayment implements PaymentMethod {\n @Override\n public boolean validate(PaymentRequest request) {\n return request.getWalletAddress() != null;\n }\n\n @Override\n public BigDecimal calculateFee(BigDecimal amount) {\n return amount.multiply(new BigDecimal(\"0.01\")); // 1%\n }\n\n @Override\n public PaymentResult process(PaymentRequest request) {\n // Crypto-specific processing\n }\n}\n```\n\n---\n\n## 🎤 Senior-Level Interview Questions\n\n### Question #1: How do you identify Single Responsibility violations?\n\n**Strong answer:**\n\nI use multiple approaches:\n\n1. **Actor Analysis:** Who would request changes to this class? Multiple actors = SRP violation.\n\n2. **Method Cohesion:** Do methods share common data? If method groups use different fields, consider splitting.\n\n3. **LCOM Metric:** I check LCOM in SonarQube. LCOM > 1 signals low cohesion.\n\n4. **Change History:** I look at git history. If different parts change for different reasons, it's a violation.\n\n5. **Import Count:** Many imports often indicate multiple responsibilities.\n\n6. **Test Difficulty:** If testing requires mocking many unrelated dependencies, responsibilities are mixed.\n\n---\n\n### Question #2: When should you NOT apply OCP?\n\n**Strong answer:**\n\nOCP adds indirection. Sometimes that cost isn't justified:\n\n1. **Stable, rarely-changing code:** If logic hasn't changed in years, abstraction is overhead.\n\n2. **Internal implementation details:** Not every private method needs strategy pattern.\n\n3. **Performance-critical paths:** Virtual dispatch has cost; hot paths may need concrete classes.\n\n4. **Small applications:** Startup with 3 developers doesn't need plugin architecture.\n\n5. **Clear, simple logic:** Two-case switch with no foreseeable additions is fine.\n\n**My rule:** Apply OCP when I see a pattern of extension (3+ similar changes) or when I can't predict future requirements.\n\n---\n\n### Question #3: Explain the relationship between SRP and microservices.\n\n**Strong answer:**\n\nSRP at class level and microservices share the same principle at different scales:\n\n**Class SRP:** One reason to change → one actor/stakeholder\n**Service SRP:** One business capability → one team\n\nBoth aim for:\n- Independent deployability\n- Isolated change impact\n- Clear ownership\n\n**Key difference:** Microservice boundaries have higher cost (network, data consistency). You need stronger justification than class splitting.\n\n**My approach:**\n1. Start with well-factored monolith (SRP at class level)\n2. Identify natural service boundaries (team ownership, scaling needs)\n3. Extract when benefits exceed costs (independent deployment worth the complexity)\n\n---\n\n### Question #4: How does SRP relate to testing?\n\n**Strong answer:**\n\nSRP makes testing dramatically easier:\n\n**High cohesion (good SRP):**\n- Few dependencies to mock\n- Tests focus on one behavior\n- Fast test execution\n- Easy to understand test intent\n\n**Low cohesion (poor SRP):**\n- Many mocks required\n- Tests verify unrelated behaviors\n- Slow, complex tests\n- Hard to maintain\n\n**Example:**\n```java\n// Poor SRP - testing processOrder requires mocking 6 services\nclass OrderProcessor {\n void processOrder(Order order) {\n // validates, charges, ships, notifies, logs, tracks\n }\n}\n\n// Good SRP - each service tested independently\nclass PaymentService { void charge(Order) { } } // 1 mock\nclass ShippingService { void ship(Order) { } } // 1 mock\nclass NotificationService { void notify(Order) { } } // 1 mock\n```\n\n---\n\n### Question #5: How do you refactor a large class without breaking existing functionality?\n\n**Strong answer:**\n\nI follow a systematic process:\n\n1. **Characterization tests:** Write tests capturing current behavior before any changes.\n\n2. **Identify clusters:** Group related methods by the data they use and the actor they serve.\n\n3. **Extract one cluster at a time:**\n - Create new class\n - Move methods\n - Update callers\n - Run tests\n - Commit\n\n4. **Use facade:** Keep original class as thin facade during transition.\n\n5. **Parallel run:** Both old and new code active, compare results.\n\n6. **Deprecate original:** Mark old methods as deprecated, migrate callers gradually.\n\n**Key:** Small, reversible steps. Never refactor and add features simultaneously.\n\n---\n\n### Question #6: What metrics indicate healthy SRP/OCP adherence?\n\n**Strong answer:**\n\n**For SRP:**\n- **LCOM (Lack of Cohesion):** < 1.0 ideal, > 2.0 needs attention\n- **Class size:** < 200 lines typically, > 500 is red flag\n- **Method count:** < 15 public methods\n- **Change coupling:** Changes affect single class, not cascade\n\n**For OCP:**\n- **Instability metric:** Ce/(Ca+Ce) should be near 0 for stable abstractions\n- **Change pattern:** Adding features = adding classes, not modifying existing\n- **Extension frequency:** How often do you add new implementations?\n\n**Tools:**\n- SonarQube: LCOM4, cognitive complexity, class coupling\n- JDepend: Package metrics, dependency analysis\n- Git: Churn analysis, co-change patterns\n\n---\n\n## 📝 Summary & Key Takeaways\n\n### Single Responsibility Principle\n\n| Aspect | Key Point |\n|--------|-----------|\n| Definition | One reason to change (one actor) |\n| Detection | LCOM metric, actor analysis |\n| Smell | Class changed by multiple teams |\n| Refactoring | Extract Class by responsibility |\n| Balance | Don't over-split cohesive logic |\n\n### Open/Closed Principle\n\n| Aspect | Key Point |\n|--------|-----------|\n| Definition | Open for extension, closed for modification |\n| Implementation | Strategy, Decorator, Plugin patterns |\n| Detection | Frequent modification of switch/if-else |\n| Benefit | Add features without breaking existing code |\n| Balance | Don't abstract prematurely |\n\n### Key Metrics\n\n```text\nLCOM (Lack of Cohesion): < 1.0 good, > 2.0 problematic\nClass size: < 200 lines typical, > 500 red flag\nPublic methods: < 15 per class\nDependencies: < 7 injected services\n```\n\n### Decision Checklist\n\n**When to split a class (SRP):**\n- [ ] Multiple actors request changes\n- [ ] Methods use different sets of fields\n- [ ] LCOM > 2.0\n- [ ] Class > 500 lines\n- [ ] Testing requires many unrelated mocks\n\n**When to apply OCP:**\n- [ ] 3+ similar switch/if-else modifications\n- [ ] Adding new types is common operation\n- [ ] Want plugin architecture\n- [ ] Need to modify behavior without source changes\n\n---\n\n## 🏁 Conclusion\n\nSRP and OCP are the foundation of maintainable code. SRP keeps classes focused and testable. OCP enables extension without risk.\n\n**Key insights:**\n- **SRP is about actors**, not about \"doing one thing\"\n- **OCP is about extension points**, not about making everything abstract\n- **Both require judgment** - over-application is as harmful as under-application\n- **Metrics help** - LCOM, class size, change coupling\n\n**Your next step:** Continue to Part 3 (SOLID - LSP, ISP, DIP) to complete your understanding of SOLID principles.\n\n---\n\n## 📅 Review Schedule for This Article\n\n| Day | Task | Time |\n|-----|------|------|\n| Day 1 | Review SRP actor-based definition diagram | 5 min |\n| Day 3 | Redo Exercise 1 (Calculate LCOM) | 15 min |\n| Day 7 | Answer interview questions without looking | 10 min |\n| Day 14 | Redo Debug This and Exercise 2 (Strategy Pattern) | 15 min |\n| Day 30 | Review OCP extension points in your current project | 10 min |\n\n---\n\n*Next in series: [Part 3: SOLID - Liskov, Interface Segregation, Dependency Inversion]*\n","featuredImage","isPublished","isFeatured","subscriptionType","BASIC","publishedAt","2026-06-10T07:19:24.639109Z","createdAt","2026-06-10T07:19:24.640148Z","updatedAt","2026-06-16T21:26:56.086200Z","readingTimeMinutes",19,"estimatedReadingTime","authorId","authorUsername","tomasz_main","categoryName","Java","readingTime","seriesId","seriesOrder",2,"author",{"_31":32,"_101":56,"_102":103,"_104":105,"_106":-5,"_107":-5,"_108":-5,"_109":-5,"_110":-5},"category",{"_31":97,"_71":58,"_35":98,"_74":99,"_100":-5},"tags",[77,78,79,80,81],"series",{"_31":16,"_71":72,"_35":73,"_74":75,"_76":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":94,"_71":95,"_35":96},{"_31":91,"_71":92,"_35":93},{"_31":88,"_71":89,"_35":90},{"_31":85,"_71":86,"_35":87},{"_31":82,"_71":83,"_35":84},21,"Srp","srp",20,"Solid","solid",23,"Single Responsibility","single-responsibility",24,"Open-closed","open-closed",22,"Ocp","ocp",5,"java","Category for Java","colorHex","username","firstName","Tomasz","lastName","Jarosz","profilePicture","bio","website","githubUrl","linkedinUrl"]