[디자인패턴] 객체지향 설계 5가지 원칙, SOLID 원칙

SOLID 원칙

컴퓨터 프로그래밍에서 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것.

 

소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이자, 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부.

 

 

 

이 5가지 원칙의 앞 글자를 따서 SOLID 원칙이라고 한다.

대략적인 내용을 알고 있는 것이 도움이 되므로 잘 알아두자.

 

---

1. 단일 책임 원칙 (Single Responsibility Principle, SRP)

객체에서 중요한건 역할, 책임, 협력이고, 한 클래스가 어떤 역할의 기능을 구현하고 있어야 한다.

모든 클래스는 단 하나의 책임만 가지며 그 책임을 완전히 캡슐화 해야 한다는 원칙이다.

 

2. 개방 폐쇄의 원칙 (Oepn-Closed Principle, OCP)

객체 자신의 수정에 대해서는 유연하고, 다른 클래스가 수정될 때는 영향을 받지 않는다.

예) 자바 JDBC, I/O Stream

추상클래스 레벨에서 접근하여 구현하여 수정하는 것을 말한다.

소프트웨어 개체는 확장에 대해 열려 있어야하고, 수정에 대해서는 닫혀있어야 한다는 원칙이다.

 

3. 리스코프 치환 원칙 (Liskov Subsititution Principle, LSP)

하위 클래스는 항상 상위 클래스로 교체 될 수 있어야 한다. 상속할 때는 서로 연관이 있는 관계가 되어야 한다.

예) IS-A 관계

상위 타입의 객체를 하위타입의 객체로 치환하더라도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야한다는 원칙이다.

 

4. 의존 역전 원칙 (Dependency Inversion Principle, DIP)

의존 관계는 구체적인 것보다는 추상적인 것에 의존한다. 여기서 구체적인 것은 이미 구현이 되어있고 변하기 쉬운것이고 추상적인 것은 인터페이스나 추상 클래스(상위 클래스)를 말한다.

 

소프트웨어 모듈들을 분리하는 특정 형식을 지칭하는 것을 말한다.

정책을 결정하는 상위 계층이 세부사항인 하위계층에 의존하는 전통적인 의존관계를 반대로 역전 시킴으로써 상위계층이 하위 계층의 구현으로부터 독립되게 할 수 있다.

 

A가 B에(a -> b) 의존한다고 하면 

업캐스팅, 상위 클래스를 받도록 하면 다양한 하위 클래스를 받아올 수 있음.

 

5. 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

제공하는 기능에 대한 인터페이스에만 종속적이어야 한다.

만약 하나의 객체가 여러 기능을 제공해야 한다면 ( 단일 책임 원칙에 위배 ),이때 클라이언트가 사용할 수 있는 여러 인터페이스로 분리하여 제공하면 클라이언트가 사용하지 않는 기능에 종속적이지 않을 수 있다.

여러 기능이 복합적으로 제공되는데 만약 분리가 할 필요가 있고 사용할때는 나눠서 사용한다고 한다면 인터페이스를 나눠서 사용하는 것이 좋다.

 

클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 

큰 덩어리의 인터페이스들을 구체적으로 작은 단위들로 분리시킴으로써 클라이언트가 꼭 필요한 메서드들만 이용할 수 있게 한다.

 

 

* 단일 책임원칙과 인터페이스 분리 원칙은 서로 상반되는 부분이 있어서 중요도에 따라 분리해서 적용하면 된다.