[디자인 패턴] SOLID 원칙

 S

Single Resposibility Principal(단일 책임의 원칙) : 어떤 클래스 한 개는 하나의 책임만 가진다. 

예를 들어, 

Class ADD {

  // 더하기 기능을 제공할 책임만 가져야 함

  // 빼기, 더하기 등등 부가적으로 제공하면 SRP를 위반함 

}

O

Open Close Principal(개방 폐쇄의 원칙) : 개방에는 open되어 있고, 수정에는 close되어 있어야 한다.

예를 들어, 

A.class를 만들어서 테스트하고 서비스도 하고 있음.

이러한 상황에서 A.class를 기능 보완을 하고 싶을 때 A.class를 고치는 것이 아니라, 새로운 클래스를 만들어서 새 클래스에서 기능 보완을 해야 한다. 

즉, 기존에 있는 클래스를 손대지 않고(수정에는 close), 새로운 클래스를 만들어서 보완해야 함.(새로운 클래스 생성에는 open)

L

Liscov Subtitution Principal(리스코브 치환 법칙) : 부모 객체와 자식 객체가 있을 때, 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체할 수 있다. 즉, A 객체가 B 객체의 자식 클래스일 때, A 클래스와 B 클래스를 바꿔도 문제가 없어야 한다.

I

Interface Sergregation Pricipal(인터페이스 분리 법칙) : 하나의 광범위한 인터페이스보다 구체적인 여러 개의 인터페이스를 만들어야 한다. 이를 위해 객체는 자신이 사용하는 메서드에만 의존해야 한다. 

인터페이스를 지나치게 광범위하게 구현해서는 안되며, 그 인터페이스를 사용하는 객체를 기준으로 잘게 분리해야 한다.

예를 들어, 

위 그림에서 User1, User2, User3 객체 모두 OPS를 상속받고 있다. 이 상황에서 User1 객체는 op1 메서드만을, User2 객체는 op2 메서드만을, User3 객체는 op3 메서드만을 사용한다고 가정한다. User1 객체는 OPS를 상속받기 때문에 op1, op2, op3 메서드 모두를 사용할 수 있지만, op2 메서드에 변동이 있을 경우, User1은 해당 메서드를 사용하지도 않는데 재컴파일되는 과정을 거쳐야 한다. 

이는 상속받은 인터페이스가 지나치게 광범위하기 때문에 발생하는 문제이다. 

위 그림과 같이 OPS를 상속받는 U1Ops, U2Ops, U3Ops로 분리하여 각각의 객체가 상속받도록 하면, 각 객체는 자신이 사용하는 메서드만을 사용할 수 있는 구조가 된다. 

D

Dependency Inversion Principal(의존성 역전 원칙) : 객체는 구체적인 객체가 아니라, 추상화에 의존해야 한다.

인터페이스, 추상클래스와 같은 고수준 모듈이 메인 클래스, 객체와 같은 저수준 모듈에 의존해서는 안된다. 

사실 고수준 클래스가 저수준 클래스를 사용하므로 고수준 클래스가 저수준 클래스에 의존하는 것이 자연스러워 보일 수 있다.

하지만 저수준 클래스는 빈번하게 변경되고, 새로운 것이 추가될 때마다 고수준 클래스가 영향을 받기 쉬우므로 의존관계를 역전시켜야 한다.

 

 

 

 

이러한 원칙들은 지키면 좋겠다라는 것이지, 무조건 지켜야만 하는 것은 아니다. 지키지 않는다고 해서 컴파일 오류가 나는 등의 문제는 발생하지 않지만 좋은 코드를 작성하기 위해서 개발자가 이러한 원칙을 지키면서 프로그래밍하겠다는 마음가짐을 가져야 한다.