SOLID는 좋은 소프트웨어 아키텍처를 만드는 데 도움이 되는 5가지 기본 원칙

단일 책임 원칙 (Single Responsibility Principle)

class(=객체)는 하나의 책임(목적, 역할 등)만 지녀야 한다는 원칙이다.
새로운 기능을 기존 class에 추가하게 되면, (=하나의 class가 여러 기능을 수행하면) 코드가 길어지고 복잡해진다. 또 나중에 수정해야할 때 시간이 많이 걸릴 수 있다.

class Customer
{
  public void Add()
  {
    try
    {
    	// Database code goes here
    }
    catch (Exception ex)
    {
    	System.IO.File.WriteAllText(@"c:Error.txt", ex.ToString());
    }
  }
}

개방-폐쇄 원칙 (Open-Closed Principle)

class(=객체, 함수 등)는 확장에는 개방 되어야하나, 수정에는 폐쇄 되어야한다.
부모 class에서 자식 class를 만들 때, 자식 class에서 기능을 추가/수정할 수 있지만, 자식 class를 위해 부모 class가 수정될 필요는 없다.

class Customer
{
  public virtual double getDiscount(double TotalSales)
  {
  	return TotalSales;
  }
}

class SilverCustomer : Customer
{
  public override double getDiscount(double TotalSales)
  {
  	return base.getDiscount(TotalSales) - 50;
  }
}

class goldCustomer : SilverCustomer
{
  public override double getDiscount(double TotalSales)
  {
  	return base.getDiscount(TotalSales) - 100;
  }
}

리스코프 치환 원칙 (Liskov Substitution Principle)

자식 class는 언제나 자신의 부모 class를 교체할 수 있다는 원칙이다.
부모 class의 위치에 자식 class로 넣어도 어떠한 issue도 없어야 한다는 원칙이다.

interface IDiscount
{
	double getDiscount(double TotalSales);
}

interface IDatabase
{
	void Add();
}

class Enquiry : IDiscount
{
  public  double getDiscount(double TotalSales)
  {
  	return TotalSales - 5;
  }
}

class Customer : IDiscount, IDatabase
{
  private MyException obj = new MyException();
  public virtual void Add()
  {
    try
    {
    	// Database code goes here
    }
    catch (Exception ex)
    {
    	obj.Handle(ex.Message.ToString());
    }
  }
  public virtual double getDiscount(double TotalSales)
  {
    return TotalSales;
  }
}

인터페이스 분리 원칙 (Interface Segregation Principle)

클라이언트가 자신과 관련이 없는 인터페이스는 구현하지 않아야 한다.
class는 자신이 사용하지 않는 method는 구현하지 않아야 한다.

interface IDatabase
{
  void Add(); // old client are happy with these.
  void Read(); // Added for new clients.
}

interface IDatabaseV1 : IDatabase // Gets the Add method
{
	Void Read();
}

class CustomerwithRead : IDatabase, IDatabaseV1
{
  public void Add()
  {
    Customer obj = new Customer();
    Obj.Add();
  }
  Public void Read()
  {
 	 // Implements  logic for read
  }
}

IDatabase i = new Customer(); // 1000 happy old clients not touched
i.Add();
IDatabaseV1 iv1 = new CustomerWithread(); // new clients
Iv1.Read();

의존 역전 원칙 (Dependency Inversion Principle)

고차원 module/class는 저차원 module/class에 의존하면 안된다는 원칙이다.
(고차원, 저차원 module/Class는 모두 추상화(abstractions)에는 의존한다.)
추상화는 세부사항에 의존해서는 안되고, 세부사항은 추상화에 의존해야한다.

interface ILogger
{
	void Handle(string error);
}

class FileLogger : ILogger
{
  public void Handle(string error)
  {
  	System.IO.File.WriteAllText(@"c:Error.txt", error);
  }
}

class EverViewerLogger : ILogger
{
  public void Handle(string error)
  {
  	// log errors to event viewer
  }
}

class EmailLogger : ILogger
{
  public void Handle(string error)
  {
  	// send errors in email
  }
}

class Customer : IDiscount, IDatabase
{
  private Ilogger obj;
  public Customer(ILogger i)
  {
	  obj = i;
  }
}

IDatabase i = new Customer(new EmailLogger());

출처 간단한 C# 예제를 사용한 SOLID 아키텍처 원칙