
## Introduction

Clean methods help locally; clean class design helps globally.

When classes are too large or tightly coupled, every change becomes risky. This post shows practical class design rules based on SOLID.

## 1) Single Responsibility Principle (SRP)

A class should have one reason to change.

### Bad: one class does everything

```csharp
public class OrderService
{
    public void PlaceOrder(Order order)
    {
        Validate(order);
        Save(order);
        SendNotification(order);
    }
}
```

### Better: split by responsibility

```csharp
public class OrderValidator
{
    public void Validate(Order order) { /* ... */ }
}

public class OrderRepository
{
    public Task SaveAsync(Order order, CancellationToken ct) => Task.CompletedTask;
}

public class OrderNotifier
{
    public Task NotifyAsync(Order order, CancellationToken ct) => Task.CompletedTask;
}

public class OrderService(
    OrderValidator validator,
    OrderRepository repository,
    OrderNotifier notifier)
{
    public async Task PlaceOrderAsync(Order order, CancellationToken ct)
    {
        validator.Validate(order);
        await repository.SaveAsync(order, ct);
        await notifier.NotifyAsync(order, ct);
    }
}
```

## 2) Depend on abstractions, not concretions

High-level classes should not instantiate low-level dependencies directly.

```csharp
// BAD
public class SqlReportRepository
{
    public async Task<ReportData> GetDataAsync(int id, CancellationToken ct)
    {
        return new ReportData("Monthly Sales");
    }
}

public class ReportGenerator
{
    private readonly SqlReportRepository _repository;

    public ReportGenerator()
    {
        _repository = new SqlReportRepository();
    }

    public async Task<Report> GenerateAsync(int id, CancellationToken ct)
    {
        var data = await _repository.GetDataAsync(id, ct);
        return BuildReport(data);
    }

    private static Report BuildReport(ReportData data) => new(data.Title);
}

// GOOD
public interface IReportRepository
{
    Task<ReportData> GetDataAsync(int id, CancellationToken ct);
}

public class ReportGenerator(IReportRepository repository)
{
    public async Task<Report> GenerateAsync(int id, CancellationToken ct)
    {
        var data = await repository.GetDataAsync(id, ct);
        return BuildReport(data);
    }

    private static Report BuildReport(ReportData data) => new(data.Title);
}
```

This makes the class easier to test and swap implementations.

## 3) Prefer composition over inheritance

Inheritance can create brittle hierarchies.

```csharp
// BAD
public class FlyMovement
{
    public void Move() => Console.WriteLine("Flying");
}

public class WalkMovement
{
    public void Move() => Console.WriteLine("Walking");
}

public class Animal
{
    private readonly FlyMovement _flyMovement;
    private readonly WalkMovement _walkMovement;
    private readonly string _type;

    public Animal(string type)
    {
        _type = type;
        _flyMovement = new FlyMovement();
        _walkMovement = new WalkMovement();
    }

    public void Move()
    {
        if (_type == "Bird")
        {
            _flyMovement.Move();
        }
        else if (_type == "Dog")
        {
            _walkMovement.Move();
        }
    }
}


// GOOD
public interface IMovementStrategy
{
    void Move();
}

public class FlyMovement : IMovementStrategy
{
    public void Move() => Console.WriteLine("Flying");
}

public class WalkMovement : IMovementStrategy
{
    public void Move() => Console.WriteLine("Walking");
}

public class Animal(IMovementStrategy movement)
{
    public void Move() => movement.Move();
}
```

You can change behavior by changing strategy, not by rewriting class trees.

## 4) Keep classes cohesive

A cohesive class has members that all support one purpose.

Warning signs:

- class has multiple groups of unrelated fields
- methods only use a small subset of fields
- class keeps growing with `#region` blocks

When these appear, extract classes.

## 5) Open/Closed principle in practice

Avoid repeated `if/switch` chains that must be edited for each new type.

```csharp
public abstract class Shape
{
    public abstract double CalculateArea();
}

public class Circle(double radius) : Shape
{
    public override double CalculateArea() => Math.PI * radius * radius;
}

public class Rectangle(double width, double height) : Shape
{
    public override double CalculateArea() => width * height;
}
```

New behavior is added by extension, not by changing old code.

## Summary

Strong class design reduces coupling and change risk. Start with SRP and dependency inversion; these two practices usually deliver immediate maintainability gains.


Learn how to apply SRP, dependency inversion, and composition in C# to build maintainable, extensible production services.

C# Class Design and SOLID Principles in Real Projects — Clean Code


## Table of Contents

- [SOLID Design Principle](#solid-design-principle)
- [Single Responsibility Principle (SRP)](#single-responsibility-principle)
- [Open/Closed Principle (OCP)](#openclosed-principle)
- [Liskov Substitution Principle (LSP)](#liskov-substitution-principle)
- [Interface Segregation Principle (ISP)](#interface-segregation-principle)
- [Dependency Inversion Principle (DIP)](#dependency-inversion-principle)
- [Conclusion](#conclusion)

## Introduction

This blog talks about design principles in software development. It will
focus on the SOLID design principles and provide a few example codes. This is
Part 2 of the Design Principles series, covering the five SOLID principles
that help developers build maintainable and scalable software.

## SOLID Design Principle

SOLID design principle is an acronym for the following five design principles.
These design principles will help you build maintainable, testable, flexible,
and understandable software applications.

### Single Responsibility Principle

> "There should never be more than one reason for a class to change. In other
> words, every class should have only one responsibility."

SRP, the Single Responsibility Principle, basically states that one class
should only have one purpose or responsibility. This is similar to SoC
(Separation of Concerns), with a slight difference. If we keep this principle
in mind, it will be very helpful for software design in any area. Let's look
at the following sample code.

Assume you start to use Express.js to write a blog system. The back-end is
MongoDB and you're using Node.js Mongoose as an ORM to access the MongoDB
database. The following is an Express.js route that takes an ID from the page,
then performs a query to the MongoDB database and returns the result to the UI.
The UI code is not shown here but will take the post data and display it on the
page.

This is not a lot of code, but it has several areas of concern. You see the
code to define the MongoDB schema, the setup for the index, a query to the
Posts collection by ID, and Express.js code to call the data for the UI. Based
on the Single Responsibility Principle, we should divide all these different
areas of code into separate files. One of the reasons is maintainability. I
know the following code is just a few lines, but in reality one page's code
could be hundreds or thousands of lines. It probably calls many different
services, validation, and filters to get the data. That's why when you first
write the code, it is better to keep this principle in mind and break the code
into different files.

Let's see how we change this code.

```
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

const PostsSchema = new Schema({
   slug: String,
   title: String,
   state: String,
   content: String,
   createdDate: Date,
   tags: Array
});

PostsSchema.index({
   title: 'text',
   content: 'text'
});

async findById(id: any) {
    return this.PostsSchema.findById(id);
}

exports.index = async function(req, res) {

    const model = await findById(req.params.id);

    res.render('my-page-by-id', model);

}
```

posts.schema.ts

First, I think we can move the Posts MongoDB schema to a separate file. This
will be the file you update whenever you change your collection's MongoDB
schema or add some default index.

```
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

export const PostsSchema = new Schema({
   slug: String,
   title: String,
   state: String,
   content: String,
   createdDate: Date,
   tags: Array
});

PostsSchema.index({
   title: 'text',
   content: 'text'
});
```

Posts.dataService.ts

For the MongoDB database access part, create another data repository file
as PostsDataService. This file will be responsible for accessing MongoDB
and returning the result.

```
const {PostsSchema} from './Posts.schema.ts';
export class PostsDataService {

   async findById(id: any) {
        return this.PostsSchema.findById(id);
   }
}
```

index.ts

Now, the last file is the Express.js route — the controller page that handles
page requests, gets data, and returns it to the view. Ideally, there should be
another business logic layer in between, but after removing the MongoDB schema
and data access, this file now has much less responsibility. It simply
validates the request and returns the data to the UI.

```
const {PostsDataService} from './Posts.DataService.ts';

exports.index = async function(req, res) {

   if (!req.params.id) {
       // go to 404 page
      return GoTo404Page();
   }

    const model = await new PostsDataService().findById(req.params.id);

    res.render('my-page-by-id', model);

}
```

### Open/Closed Principle

> "Software entities should be open for extension, but closed for
> modification."

The Open/Closed Principle states that when you create a class, you should hide
or close its implementation from the outside, but it should be open for others
to extend its functions. Let's take a look at the previous Posts DataService
class, this time with a few more functions added.

You'll also notice that you need to create comment, users, and image MongoDB
collections, and they all have similar functions as follows. You want them all
to use the same implementation to access the MongoDB database, but you also
want to extend the functions for each collection.

```
const {PostsSchema} from './Posts.schema.ts';
export class PostsDataService {

   async findById(id: any) {
        return this.PostsSchema.findById(id);
   }

    async countAllQuery(condition:any): Promise {
        return await this.PostsSchema.count(condition);
    }

    async deleteOne(model: any): Promise {
        return await this.PostsSchema.deleteOne(model);
    }

    async update(filter: any, doc: any) {
        return await this.PostsSchema.updateOne(filter, doc);
    }}
```

Let's check how we can achieve this.

IDataServiceBase.ts

First, create an interface which has all the functions you think all the other
collections can use.

```
export interface IDataServiceBase {

    create(model: Dto): Promise;
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;
}
```

DataServiceBase.ts

Next, we'll create a base data class to implement the interface. All the
detailed implementation goes inside this DataServiceBase class.

```
import { Document } from 'mongoose';
export abstract class DataServiceBase
implements InterfaceServiceBase {
    create(model: TModel): Promise {
        throw new Error("Method not implemented.");
    }
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise {
        throw new Error("Method not implemented.");
    }
    findAllByModel(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    findOneById(id: any): Promise {
        throw new Error("Method not implemented.");
    }
    findOne(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    countAll(): Promise {
        throw new Error("Method not implemented.");
    }
    count(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    update(filter: TDocument, doc: TDocument) {
        throw new Error("Method not implemented.");
    }
    deleteOne(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
}
```

### Liskov Substitution Principle

> "Functions that use pointers or references to base classes must be able to
> use objects of derived classes without knowing it."

The Liskov Substitution Principle (LSP) means that objects of a subclass
should be able to replace objects of the parent class without breaking the
application. In other words, if class B is a subclass of class A, you should
be able to pass an instance of B anywhere an instance of A is expected, and
everything should still work correctly. This encourages designing class
hierarchies where derived classes truly extend the behavior of the base class
rather than altering it in unexpected ways. Violating LSP often leads to
fragile code that relies on type-checking or conditional logic to handle
different subclasses.

### Interface Segregation Principle

> "Many client-specific interfaces are better than one general-purpose
> interface."

ISP, the Interface Segregation Principle, is about making interfaces as small
as possible instead of having one big interface doing everything. If you use a
single large interface, you might end up with classes that implement methods
they don't actually need, leaving some declared but doing nothing.

Let's take a look at the following example. It is a data repository interface
which contains basic CRUD operations. Now, let's say you want to implement
some operations that only involve writing or reading. Would you create a class
that implements the full IDataServiceBase?

```
export interface IDataServiceBase {

    create(model: Dto): Promise;
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;
}
```

For that scenario, you should create interfaces only for what is needed. So I
separated IDataServiceBase into the following two interfaces. You can use each
interface to implement specific details in a separate class file.

```
export interface IWriteDataServiceBase {

    create(model: Dto): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;

}

export interface IReadDataServiceBase {

    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
}
```

You can also combine the two interfaces together if needed.

```
export interface IDataServiceBase
extends IReadDataServiceBase, IReadDataServiceBase {

}
```

### Dependency Inversion Principle

> "Depend upon abstractions, not concretions."

The Dependency Inversion Principle (DIP) states that high-level modules should
not depend on low-level modules. Both should depend on abstractions.
Additionally, abstractions should not depend on details; details should depend
on abstractions. In practice, this means that instead of a class directly
creating or referencing a concrete implementation, it should depend on an
interface or abstract class. This makes it easy to swap out implementations
without modifying the high-level code. For example, in the code we wrote
earlier, the Express.js controller depends on the PostsDataService class
directly. With DIP, you would have the controller depend on an
IDataServiceBase interface instead, allowing you to inject any implementation
at runtime.

## Conclusion

In this post, we covered the five SOLID design principles: Single
Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and
Dependency Inversion. Each principle helps you write cleaner, more
maintainable, and more flexible code. By applying SRP you keep classes
focused, OCP lets you extend behavior without modifying existing code, LSP
ensures subclasses are truly interchangeable, ISP keeps interfaces lean, and
DIP decouples high-level logic from low-level details. Keeping these
principles in mind from the start will save you significant effort as your
codebase grows.


This blog talks about design principles in software development. It includes SOLID and a few more widely used design principles, with example code.

SOLID

C# Class Design and SOLID Principles in Real Projects — Clean Code

Design Principles in Software Development Part 2

Subscribe for Updates