좋은 객체 지향 설계의 5가지 원칙(SOLID)

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

SRP단일 책임 원칙

• 하나의 클래스는 하나의 책임만 가져야 한다.
• 경험없이는 이해하기는 조금 모호한 표현이기도 하다. 중요한건 변경을 하였을 때 파급이 적으면 단일 책임 원칙을 적용하여 잘 설계가 된 것이다.
• 예를들어서 하나를 변경해야 하면 여러개를 수정해야 하면 잘못된 설계이다.
• 단일책임원칙을 적절히 잘 중용화 하여 설계하는 것이 객체지향의 묘미이다.
• 변경이 있을 때 파장이 크지 않은것이 단일 책임 원칙이다.

OCP개방 폐쇄 원칙

• Open/closed principle의 약자가 OCP이다.
• 확장에는 열려있어야 하지만 변경에는 닫혀야 한다.
• 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
• 그런데 실상 변경에 닫혀있어야 하지만 변경을 하고 잇어 OCP개방 폐쇄 원칙에 위반이 되고 있다.

LSP 리스코프 치환 원칙

• 자동차 인터페이스의 악셀이라는 기능은 앞으로 가는 기능이다. 하지만 엑셀이 뒤로 가는 기능도 생긴다면 리스코프 치환 원칙을 위해하는 것이다. 느리더라도 무조건 앞으로 가도록 만들어야 한다.

ISP 인터페이스 분리 원칙

• 특정 클라이언트를 위한 여러 인터페이스가 범용 인터페이스 하나보다 낫다.
• 예를들어서 자동차 인터페이스가 있고 운전자 인터페이스가 있다고 가능하는 경우에 자동차에 문제가 생겨서 자동차 인터페이스를 수정하게 되는데 문제가 생긴것은 운전자 인터페이스가 아닌 자동차 인터페이스가 문재가 생긴것이다. 그렇기 때문에 자동차 인터페이스 만 수정하면 되기 때문에 이것이 특정 클라이언트를 위한 여러 인터페이스로 분활한것이다. 굳이 운전자를 변경해야 할 이유가 없기 때문이다.
• 자동차를 바꾼다고 해도 운전자 클라이언트에게 영향을 주지 않는다.
• 인터페이스 분리 원칙을 적용하면 대체 가능성이 높아진다.

DIP 의존관계 역전 원칙

• Dependency inversion principle의 약자가 DIP이다.
• 프로그래머는 추상화에 의존해f야지 구체화에 의존하면 안된다. 의존성주입은 이 원칙을 따른 방법중 하나이다.
• 클라이언트 코드가 구현 코드를 바라보는것이 아닌 인터페이스 코드를 바라봐야 한다.
• 즉 멤버서비스가 멤버 리파지토리 인터페이스만 바라봐야 하며 메모리멤버 JDBC메모리 리포지토리는 몰라야 한다.
• 역활에 의존하는것과 똑같은 이야기 이다. 운전자는 자동차 역활에 대해서 알아야 하지만 K3에 대해서 자세히 알 필요가 없다.
• 공연같은 경우에도 로미로 라는 역활에 김태희가 있으면 우리는 로미오에 집중해야지 김태희에 집중하면 안된다. 왜냐하면 김태희에게 문제가 생기면 다른 배우로 대체가 불가능해지기 때문이다. 그렇기에 우리는 로미오에 집중을 해야지 구현체인 김태희에 집중할 필요가 없다.
• 그래서 역할과 구현을 철저히 분리하여 설계를 해야 한다. 왜냐하면 문제가 생기면 구현체를 언제든지 바꿔야 하기 때문이다.
• 구현체에 의존하게 되면 변경이 어려워진다.
• 여기서 의존한다는 뜻은 의존하는 클래스의 코드를 알고 있다는 뜻이다. 알기만 하면 다 의존하는것이라고 한다.

정리

• 다형성만으로 쉽게 부품을 갈아끼우듯이 개발을 할 수 없다.
• 다형성 만으로 구현 객체를 변경할 때 클라이언트 코드도 같이 변경이 된다.
• 다형성 만으로는 OCP DIP의 규칙을 지킬 수 없다. 그래서 먼가 더 필요하다.