SOLID 원칙

클린코드로 유명한 로버트 마틴이 정리한 객체 지향 설계의 5가지 원칙은 다음과 같다.

SRP : 단일 책임 원칙(Single Responsibility Principle)

한 클래스는 하나의 책임만 가져야 한다.

클래스 내에서 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따랐다고 할 수 있다. 객체의 생성과 사용을 분리하는 상황을 예시로 들 수 있다.

OCP : 개방-폐쇄 원칙(Open/Closed Principle)

확장에는 열려있으나, 변경에는 닫혀 있어야 하는 원칙이다.

MemberRepository m = new MemoryMemberRepository(); // 기존 코드
MemberRepository m = new JdbcMemberRepository(); // 변경 코드

구현 객체를 변경하려면 클라이언트 코드를 변경해야한다. 다형성을 사용하여 객체 지향 프로그래밍을 하고 싶지만, OCP 원칙을 어기게 된다. 이럴땐 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

LSP : 리스코프 치환 원칙(Liskov Substitution Principle)

다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 하는 원칙이다.

예를 들어 자동차 인터페이스의 엑셀은 앞으로 가라는 기능이지만, 뒤로 가게 구현하면 LSP 원칙을 어기게 된다.

ISP : 인터페이스 분리 원칙(Interface Segregation Principle)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다는 원칙이다.

자동차 인터페이스를 운전, 정비 인터페이스로 분리하면, 사용자 클라이언트를 운전자 클라이언트, 정비사 클라이언트로 분리가 가능해지고, 무엇보다 정비 인터페이스 자체가 변해도 운전자 클라이언트에는 영향을 주지 않는다.
즉, 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP : 의존관계 역전 원칙(Dependency Inversion Principle)

추상화에 의존해야 하고, 구체화에는 의존하면 안된다는 원칙이다.

즉, 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 것이다. 하지만, OCP에서 설명한 MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다. 이러면 DIP를 위반한다고 볼 수 있다.

정리

다형성이 객체 지향의 꽃이지만, 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경되고, 무엇보다 구현 클래스에도 의존, 즉, 코드를 참조하게 되는 현상이 발생한다. 다형성 만으로는 OCP, DIP를 지킬 수 없다.

SOLID 원칙