좋은 객체지향 프로그래밍 및 설계를 위한 5가지 원칙을 말한다.
프로그래머가 시간이 지나도 유지보수와 확장이 쉬운 프로그램을 만들고자 할 때 유용한 지침이다.
모든 클래스는 하나의 역할(책임)만 가져야하며, 클래스는 그 책임을 완전히 캡슐화해야 함을 말한다.
책임은 변경하려는 이유로 정의할 수 있으며, 어떤 클래스나 모듈은 변경하려는 단 하나의 이유만을 가져야 한다.
다른 시기에 다른 이유로 변경되어야 한다면 잘못된 설계일 수 있다.
소프트웨어 요소(클래스, 메서드 등)는 확장에는 열려있으나 변경에는 닫혀있어야한다.
[개방 - 폐쇄 원칙 위반]
public class MemberService {
//private final MemberRepository memberRepository = new MemoryMemberRepository();
// 기존 코드
private final MemberRepository memberRepository = new JdbcTemplateMemberRepository();
// 변경 코드
...
MemberService
의 코드를 수정해야 한다.프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
[인터페이스 분리 예시]
예를 들어, 자동차 인터페이스가 있다고 가정해보자.
자동차 인터페이스 -> 운전, 정비 인터페이스로 각각 분리한다.
사용자 인터페이스 -> 운전자, 정비사 클라이언트로 각각 분리한다.
이렇게 인터페이스를 분리함으로써 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않는다.
인터페이스가 명확해지고 쉽게 대체할 수 있다.
프로그래머는 추상화에 의존해야지 구체화에 의존하면 안된다.
쉽게 말하면 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 의미이다.
[DIP 위반]
public class MemberServiceImpl implements MemberService {
...
private final MemberRepository memberRepository = new MemoryMemberRepository();
...
MemberService
가 구현 클래스를 직접 선택함으로써 MemberService
클래스는 인터페이스(MemberRepository
) 그리고 구현 클래스(JdbcTemplateMemberRe pository
) 모두 의존한다.
따라서 DIP를 위반하고 있다.
DIP를 지키기 위해서는 구현객체를 생성하고 연결하는 책임을 갖는 별도의 설정 클래스가 필요하다.
[구현 객체를 생성하고 주입해주는 설정 클래스]
public class AppConfig {
public MemberService memberService(){
return new MemberServiceImpl(new MemoryMemberRepository());
}
public OrderService orderService(){
return new OrderServiceImpl(new MemoryMemberRepository(), new FixDiscountPolicy());
}
}
...
public class MemberServiceImpl implements MemberService {
private final MemberRepository memberRepository;
public MemberServiceImpl(final MemberRepository memberRepository) {
this.memberRepository = memberRepository;
}
...
AppConfig
클래스는 구현객체 MemberServiceImpl
, MemoryMemberReposi tory
를 생성해준다.
생성한 객체 인스턴스의 참조를 생성자를 통해 주입해준다.
설계를 변경하여 MemberServiceImpl
은 MemoryMemberRepository
를 의존하지 않아 DIP를 위반하지 않는다.
의존성 주입은 DIP를 따르는 방법 중 하나이다.