SOLID in AIC Projects

Purpose

SOLID principles help AIC teams create maintainable, testable and extensible software.

SOLID is not a slogan. It is a practical design discipline used to reduce change risk.

Single Responsibility Principle

A class should have one reason to change.

Good:

public sealed class CaseNumberGenerator
{
    public string Generate(DateOnly date, int sequence) => $"CASE-{date:yyyyMMdd}-{sequence:0000}";
}

Poor:

public sealed class CaseManager
{
    public void CreateCase() { }
    public void SaveToDatabase() { }
    public void SendEmail() { }
    public void RenderWindow() { }
}

Open Closed Principle

Code should be open for extension but closed for uncontrolled modification.

Use policies, strategies or handlers when variation is expected.

Liskov Substitution Principle

Derived types must not surprise callers. If a subtype cannot honour the base contract, the abstraction is wrong.

Interface Segregation Principle

Prefer small, role-focused interfaces.

Good:

public interface ICaseReader
{
    Task<CaseRecord?> GetAsync(CaseId id, CancellationToken cancellationToken);
}

public interface ICaseWriter
{
    Task SaveAsync(CaseRecord caseRecord, CancellationToken cancellationToken);
}

Avoid large interfaces that force implementers to depend on methods they do not need.

Dependency Inversion Principle

High-level policy should not depend on low-level details.

Application services should depend on abstractions; infrastructure supplies implementations.

SOLID Review Questions

• Does this class have more than one reason to change?

• Is this abstraction real or speculative?

• Can implementations be substituted safely?

• Is the interface too broad?

• Does business logic depend directly on infrastructure?

• Could this be tested without external systems?