객체지향 책에서 자주봤지만 자주 잊게되는 SOLID에 대하여 알아보겠습니다. SOLID는 Robert Martin이 객체지향 설계를 잘 하기 위하여 모아놓은 다섯가지 원칙의 앞글자모음입니다.
이 원칙들을 꽤뚫는 핵심은 객체를 역할과 구현으로 나누는 것 입니다. 사용자는 역할(인터페이스)만 알면 되고, 구현이 변경되어도 영향을 받지 않게 됩니다.
SOLID
SRP(Single Responsibility Principle), 단일 책임 원칙, 솔로 플레이
하나의 클래스는 하나의 책임을 가져야 합니다. 하나의 메소드는 하나의 책임을 가져야 합니다. 변경의 파급효과가 적을수록, 변경으로 인한 전파가 적을 수록 좋습니다.
OCP(Open Close Principle), 개방 폐쇄 원칙, 마술과 같은 원칙
새로운 기능을 쉽게 추가 하거나 확장할 수 있고 기존코드가 변경되지 않도록 개발한다는 마법같은 원칙입니다. 다형성을 활용하면 아래처럼 새로운 기능의 Repository를 쉽게 변경할 수 있습니다.
Repository repository = new MemoryRepository(); // 기존의 기능
Repository repository = new JPARepository(); // 변경한 기능하지만, 새로운 구현체 클래스를 사용하기 위해서 기존 코드를 크고 작던 수정할 수 밖에 없습니다. 따라서 다형성 만으로는 OCP원칙을 지킬 수 없습니다. 스프링과 같은 객체지향 프레임워크에서는 OCP 원칙을 지킬 수 있도록 지원합니다.
LSP(Liskov Substitution Principle), 리스코프 치환 원칙
인터페이스에서 제공하는 구현체들을 쉽게 변경하기 위해서 구현체는 인터페이스의 규약을 변경없이 지켜야합니다.
자동차 인터페이스의 엑셀이 뒤로가도록 구현하거나, 브레이크가 앞으로 가도록 구현하면 안됩니다.
ISP(Interface Segregation Principle), 인터페이스 분리 원칙
범용 인터페이스 하나보단 역할에 맞게 쪼개는 것이 좋습니다.
자동차 인터페이스 → 운전 인터페이스 / 정비 인터페이스
DIP(Dependency Inversion Principle), 의존 역전 원칙
Dependency(의존)는 코드의 존재를 알고 있다는 뜻입니다. 즉, 직접적으로 접근하고 있다는 것을 의미합니다.
클라이언트는 구현체가 아니라 인터페이스에 의존해야합니다.
다형성은 아래와 같이 구현체를 직접 생성하기 때문에 DIP를 위반하게 됩니다.
// Repository repository = new MemoryRepository();
Repository repository = new JPARepository();DI(Dependency Injection 의존성 주입)는 이 원칙을 따르는 방법중 하나입니다.
# Servicepublic class Service {
private final MemberRepository repo;
public Service(MemberRepository repo) {
this.repo = repo;
}
}
Serivce 안에서 Repository를 직접 생성하면 의존하는 것입니다. 따라서 Repository를 손쉽게 갈아 끼기 위해서 Service를 생성할 때 주입해주면 DIP를 위반하지 않게 됩니다.
# Controllervar repository = new MemoryRepository();
Service service = new Service(repository);
지금까지 SOLID에 대하여 아주 간략하게 정리해보았습니다. 용어에 대하여 봤지만 중요한 것은 설계를 Interface와 Implement로 나누고 세부구현은 숨기는 것입니다.
