Skip to content

5. 설계 원칙: SOLID

HyoSang edited this page May 26, 2019 · 1 revision

설계 원칙 : SOLID

단일 책임 원칙

  • 클래스는 단 한개의 책임을 가져야 한다.
  • 클래스가 여러 책임을 가지면 각 책임 마다 변경되는 이유가 발생하므로 클래스를 하나의 이유로만 변경하기 위해 한 개의 책임만을 가져야 한다. (클래스를 변경하는 이유는 단 한 개여야 한다.)

단일 책임 원칙 위반이 불러오는 문제점

  • 하나의 변경을 위해서 바꾸지 않아도 될 부분을 바꿔야 한다.
  • 이러한것들이 모이면 코드가 절차지향적으로 바뀌게 된다.

책임이란 변화에 대한 것

  • 책임의 단위는 변화되는 부분과 관련된다
  • 각각의 책임은 서로 다른 이유로 변경되고, 서로 다른 비율로 변경되는 특징이 있다.
  • 메서드를 실행하는 주체를 확인하면 클래스가 몇개의 책임을 가지고 있는지 대략적으로 알 수 있다.

개방 폐쇄 원칙

  • (사용되는 기능의) 확장에는 열려 있고 (기능을 사용하는 코드의) 변경에는 닫혀 있어야 한다.
  • 확장 되는 부분을 추상화해서 표현함으로써 구현할 수 있다.
  • 또는 상속을 이용해서 구현할 수 있다.(protected 접근 제어자)

개방 폐쇄 원칙이 깨질 때의 주요 증상

  • 다운 캐스팅을 한다
  • 비슷한 if-else 블록이 존재한다.

개방 폐쇄 원칙은 유연함에 대한 것

  • 개방 폐쇄 원칙은 유연함과 관련된 원칙
  • 변화가 예상되는 것을 추상화해서 변경의 유연함을 얻도록 해준다
  • 즉 변화가 예상되는 부분을 추상화 해야 한다.

리스코프 치환 원칙

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

리스코프 치환 원칙 위반 사례

  • 명시된 명세에서 벗어난 값을 리턴한다
  • 명시된 명세에서 벗어난 익셉션을 발생한다.
  • 명시된 명세에서 벗어난 기능을 수행한다.

리스코프 치환 원칙은 계약과 확장에 대한 것

  • 리스코프 치환 원칙을 지키지 않으면 개방 폐쇄 원칙을 지킬 수 없다.

인터페이스 분리 원칙

  • 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
  • 용도에 맞게 인터페이스를 분리하는 것은 단일 책임 원칙과도 연결 된다.
  • 인터페이스 분리 원칙은 인터페이스와 콘크리트 클래스의 재사용성을 높여주는 효과도 갖는다

인터페이스 분리 원칙은 클라이언트에 대한 것

  • 인터페이스를 분리하는 기준은 클라이언트여야 한다.

의존 역전 원칙

  • 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다. 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

고수준 모듈이 저수준 모듈에 의존할 때의 문제

  • 고수준 모듈은 상대적으로 큰 틀에서 프로그램을 다룬다면 저수준 모듈은 각 개별 요소가 어떻게 구현될지에 대해서 다룬다.
  • 저수준 모듈에 의존하게 되면 저수준 모듈이 추가될 때 마다 고수준 모듈에 변경이 생긴다

의존 역전 원칙을 통한 변경의 유연함 확보

  • 추상화를 통해서 구현할 수 있다.
  • 개방 폐쇄 원칙을 따르는 설계를 만들어 주는 기반이 된다.

소스 코드 의존과 런타임 의존

  • 의존 역전 원칙은 런타임에서의 의존이 아닌 소스 코드의 의존을 역전 시킴으로써 변경의 유연함을 확보할 수 있도록 만들어주는 원칙이다.

SOLID 정리

  • 단일 책임 원칙과 인터페이스 분리 원칙은 객체가 커지지 않도록 막아 준다.
  • 리스코프 치환 원칙과 의존 역전 원칙은 개방 폐쇄 원칙을 지원한다.
  • SOLID 원칙은 사용자 입장에서의 기능 사용을 중시한다.
Clone this wiki locally