SOLID in C# Part 1: Single Responsibility

This is Part 1 of my SOLID Principles in C# series. Each article walks through a principle with real code, the kind you'd actually see in a production codebase. What Is the Single Responsibility Principle? Here's the simple version: a class should have one reason to change. Not one method. Not one line of code. One reason to change . That means one job, one area of responsibility. When someone on your team says "I need to update how we send emails," that change should affect one class, not a class that also handles order calculations and database queries. The Problem: A Class That Does Everything I've seen this pattern in almost every codebase I've worked in. At some point, someone creates an OrderService and just keeps adding to it: public class OrderService { private readonly string connectionString ; public OrderService ( string connectionString ) { this . connectionString = connectionString ; } public void PlaceOrder ( string customerEmail , string product , int quantity , decimal