{"id":17,"date":"2024-08-24T09:08:43","date_gmt":"2024-08-24T09:08:43","guid":{"rendered":"https:\/\/contentlabstudy.com\/soft\/?p=17"},"modified":"2026-09-24T21:15:24","modified_gmt":"2026-09-24T20:15:24","slug":"the-solid-principles","status":"publish","type":"post","link":"https:\/\/contentlabstudy.com\/soft\/the-solid-principles\/","title":{"rendered":"The SOLID Principles"},"content":{"rendered":"

SOLID<\/strong> is five object-design heuristics from Robert C. Martin\u2019s school of thought. They are about where change lands, not about \u201cmore interfaces.\u201d Use them when a class has started to rot under two reasons to change. Ignore them as a scorecard for every DTO.<\/p>\n

S \u2014 Single Responsibility<\/h2>\n

A module should have one reason to change<\/em> (one actor \/ one axis of change), not \u201cone method.\u201d A User<\/code> entity that also sends email and writes audit rows will change when HR policy, SMTP, or schema changes. Split along those axes: entity, EmailGateway<\/code>, AuditLog<\/code>.<\/p>\n

UserManager<\/code> changes when the email rule, SMTP, or the audit table changes.<\/p>\n

sealed class UserManager\n{\n    public void ChangeEmail(User user, string email)\n    {\n        user.ChangeEmail(email);\n        SendSmtp(email, \"changed\");\n        InsertAuditRow(\"email changed\");\n    }\n\n    static void SendSmtp(string to, string body) { }\n    static void InsertAuditRow(string message) { }\n}<\/code><\/pre>\n
The entity changes the email. The other two types change when their own side changes.<\/p>\n
sealed class User\n{\n    public string Email { get; private set; } = \"\";\n    public void ChangeEmail(string email) => Email = email;\n}\n\ninterface IEmailGateway { void Send(string to, string body); }\ninterface IAuditLog { void Write(string message); }\n\nsealed class ChangeEmail\n{\n    private readonly IEmailGateway email;\n    private readonly IAuditLog audit;\n    public ChangeEmail(IEmailGateway email, IAuditLog audit)\n    {\n        this.email = email;\n        this.audit = audit;\n    }\n\n    public void Handle(User user, string next)\n    {\n        user.ChangeEmail(next);\n        email.Send(next, \"changed\");\n        audit.Write(\"email changed\");\n    }\n}<\/code><\/pre>\n
Trap:<\/strong> a thousand one-line classes is not SRP. Cohesion still matters.<\/p>\n
O \u2014 Open\/Closed<\/h2>\n
Open for extension, closed for modification: add a new variant without editing the switch you already tested. Mechanisms: new implementations of an interface, composition, data-driven rules. Not \u201cnever touch a file.\u201d<\/p>\n
\/\/ A switch you edit twice a year can stay. This one gained a carrier every week.\nstatic decimal WeeklySwitch(string carrier, decimal weight) => carrier switch\n{\n    \"ups\" => weight * 2m,\n    \"fedex\" => weight * 3m,\n    \"dhl\" => weight * 4m,\n    _ => throw new ArgumentOutOfRangeException(nameof(carrier))\n};\n\ninterface IShipper { decimal Price(decimal weight); }\n\nstatic decimal Price(IShipper shipper, decimal weight) => shipper.Price(weight);<\/code><\/pre>\n
The new carrier is a new IShipper<\/code>. The twice-a-year switch in the trap below does not need this.<\/p>\n
Trap:<\/strong> premature strategy hierarchies for two cases. A switch<\/code> you edit twice a year is fine.<\/p>\n
L \u2014 Liskov Substitution<\/h2>\n
If client code works with type T<\/code>, it must still work with any subtype of T<\/code>. Subtypes must honor the parent\u2019s contract: preconditions no stronger, postconditions no weaker, invariants preserved. No surprising exceptions, no no-op methods that the parent promised would do work.<\/p>\n
The penguin example is only an LSP bug if Bird<\/code> guarantees<\/em> Fly()<\/code>. Then Penguin : Bird<\/code> is the wrong model. Fix the contract: Bird<\/code> does not fly; FlyingBird<\/code> does. Square\/rectangle is the same bug: a Rectangle.SetWidth<\/code> that a Square<\/code> silently couples to height breaks callers who set width then height.<\/p>\n
This is a bug only because Rectangle<\/code> lets a caller set the sides independently. Stretch<\/code> expects 20. A Square<\/code> returns 25. The repair is two types that do not inherit.<\/p>\n
class Rectangle\n{\n    public virtual int Width { get; set; }\n    public virtual int Height { get; set; }\n    public int Area => Width * Height;\n}\n\nclass Square : Rectangle\n{\n    public override int Width\n    {\n        get => base.Width;\n        set { base.Width = value; base.Height = value; }\n    }\n\n    public override int Height\n    {\n        get => base.Height;\n        set { base.Height = value; base.Width = value; }\n    }\n}\n\nstatic int Stretch(Rectangle shape)\n{\n    shape.Width = 4;\n    shape.Height = 5;\n    return shape.Area; \/\/ 20 for a Rectangle, 25 for a Square\n}<\/code><\/pre>\n
sealed record Box(int Width, int Height)\n{\n    public int Area => Width * Height;\n}\n\nsealed record SquareShape(int Side)\n{\n    public int Area => Side * Side;\n}<\/code><\/pre>\n
I \u2014 Interface Segregation<\/h2>\n
Do not force clients to depend on methods they never call. Fat IMachine<\/code> with Print\/Scan\/Fax makes a simple printer fake a scanner. Split roles the clients actually use. This is about call sites<\/em>, not about one interface per method.<\/p>\n
interface IMachine\n{\n    void Print();\n    void Scan();\n    void Fax();\n}\n\nsealed class SimplePrinter : IMachine\n{\n    public void Print() { }\n    public void Scan() { } \/\/ this printer has nothing to scan\n    public void Fax() { }\n}\n\ninterface IPrinter { void Print(); }\n\nsealed class Printer : IPrinter\n{\n    public void Print() { }\n}<\/code><\/pre>\n
IPrinter<\/code> is the role the caller uses. It is not one interface per method.<\/p>\n
D \u2014 Dependency Inversion<\/h2>\n
High-level policy should depend on abstractions it owns, not on SQL or HTTP details. Details depend inward. Dependency injection<\/strong> is a technique (constructor args, a container). DIP is the direction of the source dependency. You can inject SqlOrderRepository<\/code> everywhere and still violate DIP if the domain references that concrete type.<\/p>\n
static void PlaceBroken(SqlConnection db)\n{\n    _ = db.ConnectionString;\n}\n\nstatic void Place(IOrders orders) => orders.Add(new Order());<\/code><\/pre>\n
Passing a SqlConnection<\/code> into the use case is the break, even if a container constructed it. Place<\/code> depends on the port.<\/p>\n
Pitfalls<\/h2>\n