Skip to main content

​
Large Class Issues in C#

What is Large Class Issues? Large Class Issues refers to the anti-pattern where a single class grows excessively large by taking on too many responsibilities, violating the Single Responsibility Principle (SRP). Common aliases include “God Class,” “Blob Class,” or “Swiss Army Knife Class.” This occurs when a class handles multiple unrelated concerns, leading to code that’s difficult to maintain, test, and extend. Core problems include tight coupling, reduced cohesion, and violation of encapsulation principles.

​
How it works in C#

​
Extract Class

Explanation: Extract Class involves identifying cohesive subsets of related fields and methods within a large class and moving them to a new, focused class. This follows the “One Reason to Change” principle. C# Example: 
// Before - Large Customer class handling both customer data and order processing
public class Customer
{
    public string Name { get; set; }
    public string Email { get; set; }
    public List<Order> Orders { get; set; }
    
    // Order-related methods bloating the Customer class
    public void AddOrder(Product product, int quantity)
    {
        var order = new Order { Product = product, Quantity = quantity };
        Orders.Add(order);
    }
    
    public decimal CalculateTotalRevenue()
    {
        return Orders.Sum(o => o.Product.Price * o.Quantity);
    }
    
    // Customer-related methods
    public bool ValidateEmail() => Email.Contains("@");
}

// After - Extracted OrderManagement class
public class Customer
{
    public string Name { get; set; }
    public string Email { get; set; }
    public OrderManager OrderManager { get; set; } = new OrderManager();
    
    public bool ValidateEmail() => Email.Contains("@");
}

public class OrderManager
{
    public List<Order> Orders { get; set; } = new List<Order>();
    
    public void AddOrder(Product product, int quantity)
    {
        var order = new Order { Product = product, Quantity = quantity };
        Orders.Add(order);
    }
    
    public decimal CalculateTotalRevenue()
    {
        return Orders.Sum(o => o.Product.Price * o.Quantity);
    }
}

​
Interface Segregation

Explanation: Interface Segregation Principle (ISP) states that clients shouldn’t be forced to depend on interfaces they don’t use. For large classes, this means breaking down “fat interfaces” into smaller, more specific ones. C# Example: 
// Before - Large interface forcing implementers to handle unrelated methods
public interface IOrderOperations
{
    void CreateOrder(Order order);
    void CancelOrder(int orderId);
    void ProcessPayment(Order order);
    void GenerateInvoice(Order order);
    void ShipOrder(Order order);
    void TrackShipment(int orderId);
}

// After - Segregated interfaces
public interface IOrderManagement
{
    void CreateOrder(Order order);
    void CancelOrder(int orderId);
}

public interface IPaymentProcessing
{
    void ProcessPayment(Order order);
}

public interface IInvoiceGeneration
{
    void GenerateInvoice(Order order);
}

public interface IShippingOperations
{
    void ShipOrder(Order order);
    void TrackShipment(int orderId);
}

// Classes now implement only relevant interfaces
public class OrderProcessor : IOrderManagement, IPaymentProcessing
{
    public void CreateOrder(Order order) { /* Implementation */ }
    public void CancelOrder(int orderId) { /* Implementation */ }
    public void ProcessPayment(Order order) { /* Implementation */ }
}

​
Service Injection

Explanation: Service injection involves using Dependency Injection (DI) to break large class dependencies by injecting specialized services instead of having the class handle everything internally. C# Example: 
// Before - Large class handling logging, caching, and data access internally
public class ProductService
{
    private readonly ILogger _logger;
    private readonly ICacheService _cache;
    private readonly IProductRepository _repository;
    
    public ProductService()
    {
        _logger = new FileLogger();  // Tight coupling
        _cache = new MemoryCache();  // Tight coupling
        _repository = new SqlProductRepository();  // Tight coupling
    }
    
    public Product GetProduct(int id)
    {
        _logger.Log("Getting product...");
        var cached = _cache.Get<Product>($"product_{id}");
        if (cached != null) return cached;
        
        var product = _repository.GetById(id);
        _cache.Set($"product_{id}", product);
        return product;
    }
}

// After - Services injected via constructor
public class ProductService
{
    private readonly ILogger _logger;
    private readonly ICacheService _cache;
    private readonly IProductRepository _repository;
    
    // Dependency injection promotes loose coupling
    public ProductService(ILogger logger, ICacheService cache, IProductRepository repository)
    {
        _logger = logger;
        _cache = cache;
        _repository = repository;
    }
    
    public Product GetProduct(int id)
    {
        _logger.Log("Getting product...");
        var cached = _cache.Get<Product>($"product_{id}");
        return cached ?? _repository.GetById(id);
    }
}

// Registration in DI container (e.g., ASP.NET Core)
services.AddScoped<ILogger, FileLogger>();
services.AddSingleton<ICacheService, MemoryCache>();
services.AddScoped<IProductRepository, SqlProductRepository>();
services.AddScoped<ProductService>();

​
Partial Classes

Explanation: Partial classes allow splitting a class definition across multiple files, which can help organize large classes but should be used cautiously as they don’t reduce actual complexity. C# Example: 
// Product.cs - Main partial class definition
public partial class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    
    public decimal CalculateDiscount(decimal percentage)
    {
        return Price * (1 - percentage);
    }
}

// Product.Inventory.cs - Inventory-related methods in separate file
public partial class Product
{
    public int StockQuantity { get; set; }
    public bool IsInStock => StockQuantity > 0;
    
    public void UpdateStock(int quantity)
    {
        StockQuantity += quantity;
        if (StockQuantity < 0) StockQuantity = 0;
    }
}

// Product.Pricing.cs - Pricing-related methods in separate file
public partial class Product
{
    public bool IsOnSale { get; set; }
    public decimal SalePrice { get; set; }
    
    public decimal GetCurrentPrice() => IsOnSale ? SalePrice : Price;
}

​
Why is Large Class Issues important?

  1. SOLID Principles Compliance - Breaking large classes enforces SRP and ISP, leading to more maintainable and testable code that adheres to established software design principles.
  2. Testability Improvement - Smaller, focused classes are easier to unit test in isolation, reducing test complexity and improving test coverage through targeted testing strategies.
  3. Scalability and Evolution - Modular code organized around single responsibilities allows teams to work concurrently on different features without merge conflicts and enables safer system evolution.

​
Advanced Nuances

​
1. Strategic vs Tactical Refactoring

Distinguish between extracting classes for immediate relief (tactical) versus designing domain boundaries strategically. Advanced practitioners use Domain-Driven Design (DDD) patterns like Aggregates and Bounded Contexts to guide class extraction decisions, ensuring extracted classes represent meaningful business concepts rather than arbitrary groupings.

​
2. The Interface Segregation Fallacy

Beware of over-segregation where interfaces become too fine-grained, leading to “interface explosion.” The key nuance lies in balancing coherence with specificity—interfaces should represent meaningful abstractions, not just mechanical splits. Use client needs as the guiding principle rather than arbitrarily dividing methods.

​
3. Partial Classes as Organization, Not Solution

Partial classes organize code physically but don’t reduce logical complexity. Advanced usage involves combining partial classes with feature flags or conditional compilation to manage different implementation variants while maintaining a clean public API surface.

​
How this fits the Roadmap

Within the “Bloater Smells” section of the Advanced C# Mastery roadmap, Large Class Issues serves as a foundational prerequisite for understanding more complex code organization patterns. It directly leads into:
  • Prerequisite for: Feature Envy, Data Clumps, and Primitive Obsession patterns
  • Unlocks: Advanced refactoring techniques, Domain-Driven Design implementation, and microservices decomposition patterns
Mastering Large Class resolution establishes the mental framework needed for sophisticated architectural decisions, particularly in distributed systems where class responsibility boundaries directly impact system scalability and maintainability.

Build docs developers (and LLMs) love

Get started for freeTalk to us