Notice
Recent Posts
Recent Comments
06-24 20:22
«   2024/06   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
Archives
Today
Total
관리 메뉴

Byeol Lo

SOLID 본문

BackEnd/Design Pattern

SOLID

알 수 없는 사용자 2024. 6. 11. 14:38

객체 지향을 위한 설계에서 빼놓을 수 없는 설계 방식이다.

  1. Single Reponsibility Principle (SRP): 단일 책임 원칙
  2. Open/Closed Principle (OCP): 개방 폐쇄의 원칙
  3. Liskov Substitution Principle (LSP): 리스코프 치환 원칙
  4. Interface Segregation Principle (ISP): 인터페이스 분리 원칙
  5. Dependency Inversion Principle (DIP): 의존관계 역전 원칙

 

SRP

 한 클래스는 하나의 책임만 가져야 한다(책임은 클 수도 있고 작을 수도 있지만, 경험적으로 지정해야 한다). 책임의 범위를 결정하는 중요한 기준은 "변경" 임. 파급효과를 불러일으키는 설계는 줄이고 적은 쪽으로 설계를 한다. 

 

OCP

 소프트웨어가 확장에는 열려있지만, 변경에는 닫혀있어야 한다. 즉, 역할(interface)는 고정이되어야 하며, 이를 통한 class들은 무수히 많이 만들어내는(확장이 되는) 것이 되어야 하지만, 이 interface의 변경에 대한 관점에서는 폐쇄적이어야 한다는 것. DB 관점에서는 너무 많은 migration을 하지 말아라 ! 이다.

 이 말은 다형성을 이용하라는 것인데, 이 다형성을 이용해도 깨지는 일이 발생(코드 자체에서 생성자를 만들어 내는 부분에 "변경"이 일어나기 때문)한다. 그렇다면 이를 따로 조정해주는 생성자가 따로 필요하다.

 

LSP

 프로그램의 객체는 프로그램의 정확성을 깨뜨리면 안되고, 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 즉, 메소드의 이름에 맞는 일반적인, 정상적인 뜻을 가진 명확한 동작을 하는 클래스를 만들어야 한다.

 

ISP

 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 즉, 인터페이스의 명을 명확하게 구분할 수 있는 여러 개의 인터페이스로 가능한 한 분리를 해라(너무 많이 분리해도 안되고 적당히..).

 

DIP

 프로그래머는 추상화에 의존해야하며, 구체화에 의존하면 안된다. 즉, 인터페이스에 집중을 더 주고, 구현에는 너무 많은 초점을 주지 않는다. 또한 interface에 대한 구현체에서는 구체화에 의존시키면 안된다는 것이다. 추상화에만 목적을 둔 interface의 구현체는 interface 본래의 목적에 충실해야 한다. 그 하위의 class에 대해서 해당 구현체 내에서 그걸 명시해버리면(멤버 클래스 같은 것) 이것은 구체화에 더 의존을 하게 되는 것이다. 이를 의존관계 역전의 법칙(Dependency Inversion Principle) 이라고 한다

Comments