SOLID
정의 : 좋은 객체 지향 설계의 5가지 원칙을 로버트 마틴이 정리한 내용.
SOLID 를 왜 사용하는가? 유지보수성과 확장성을 위하여 사용함.
1️⃣ SRP(Single responsibility principle) : 단일 책임 원칙
정의
-
한 클래스는 하나의 책임(기능)만 가져야 한다.
- 책임이라는 말은 너무 모호하다. 기준을 변경으로 잡자!
-
클래스를 변경하는 이유는 단 하나여야한다.
-
결국 모든 소프트웨어의 변경 이유는 "사용자와 이해관계자를 만족시키기 위함" 하나 아닌가?
-
Ex : 판교장터(판교개발자)가 당근마켓으로(일반인들도 사용가능한 서비스) 가 된 것은 요청에 의해서 / 배민이 MSA를 적용한 이유는 장애에 유연하게 대처하여 사용자의 불편을 해소하기 위해서
-
-
하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다.
- 하나의 모듈에 대하여 동일한 방식으로 변경을 원하는 사람은 한 사람만 있는 것이 아니니깐 "사용자 또는 이해관계자"라는 말은 부적절하지 않을까?
-
하나의 모듈은 하나의 액터에 대해서만 책임져야 한다.
-
모듈 : 단순히 함수와 데이터 구조로 응집된 집합
-
액터 : 사용자/이해관계자 개인 or 그룹
-
즉, 응집성이 SRP의 핵심이 되어진다. 하나의 액터를 책임지는 코드를 "응집시켜 주는 힘"이 바로 응집성이다.
응집도
단일 책임 원칙(SRP: Single-Responsibility Principle)은 톰 드마르코(Tom DeMarco)와 메이릴 페이지 존스(Meilir Page-Jones)의 연구에서 설명된 것으로, 그들은 이것을 응집도(cohesion)라 불렀다.
응집도는 모듈의 독립성을 나타내는 개념으로, 모듈 내부 구성요소 간 연관정도
응집도는 정보 은닉 개념의 확장 개념으로, 하나의 모듈은 하나의 기능을 수행하는 것을 의미한다.
한줄정리
변경이 있을 때 파급효과가 적으면 SRP를 잘 따른 것. SRP원리를 적용하면 책임 영역이 확실해지기 때문에 한 책임의 변경에서 다른 책임의 변경으로의 연쇄작용에서 자유로울 수 있다.
예시
// SRP 미적용
public class Person {
public static void cook() {
System.out.println("음식을 만듭니다.");
}
public static void paint() {
System.out.println("그림을 그립니다");
}
public static void drive() {
System.out.println("운전을 합니다");
}
}// SRP 적용
public class Chef {
public static void cook() {
System.out.println("음식을 만듭니다.");
}
}
public class Soldier {
public static void shoot() {
System.out.println("그림을 그립니.");
}
}
public class Driver {
public static void drive() {
System.out.println("운전을 합니다");
}
} 2️⃣⭐️OCP (Open-Closed Principle) : 개방-폐쇄 원칙
If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.
-
소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
-
다형성 활용
-
인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
한줄 정리
새로운 변경사항이 발생했을 때 객체를 직접 수정하지 않고도 변경사항을 적용할 수 있도록 설계해야 함. DI, IoC가 필요.
궁금증
-
서비스에 인터페이스를 도입을 안하는 경우는 그럼 이 원칙을 안지킨 것일까?
-
서비스에 인터페이스를 도입하면 추상화라는 비용이 발생
-
기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법
-
3️⃣ LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
The picture shows that the **parent** Class delivers Coffee(it could be any type of coffee). It is acceptable for the **child** Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.
-
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
-
다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구체를 믿고 사용할려면 이 원칙 필요
-
기능적으로 보장해줘야 함.
예시
자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야함.
한줄정리
클라이언트는 인터페이스 구현객체의 내부를 모르기 대문에 믿고 쓰기 위해서는 인터페이스를 구현한 객체가 인터페이스의 사용 의도에 맞게 구현해야 된다.
4️⃣ ISP(Interface Segregation Principle) :인터페이스 분리 원칙
-
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
-
인터페이스를 잘 쪼개는 것이 중요하다
-
인터페이스가 명확해지고, 대체 가능성이 높아진다.
예제
자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스롤 분리
사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
한줄정리
특정 클래스에서 다 쓰지 않는 다양한 추상메서드가 들어간 커다란 인터페이스보다는 인터페이스를 특정 클라이언트에 맞게 구체적으로 쪼개자.
5️⃣⭐️ DIP(Dependency inversion principle) : 의존관계 역전 원칙
구현 클래스에 의존하지 말고, 인터페이스에 의존해라
한줄정리
클라이언트가 구현객체에 의존하는 것이 아닌 클라이언트와 구현객체 사이에 인터페이스를 두고, 그 인터페이스에 의존하여 구현객체를 변경해도 클라이언트에 변경이 없어야 함.
