SOLID
클린코드의 저자 로버트 마틴이 정리한 5가지 설계 원칙
1. SRP
단일 책임 원칙(Single Responsibility Principle)
- 하나의 클래스는
하나의 책임만 가져야 한다.- 하나의 책임이라는 것은 모호하다.
- 클 수도 있고 작을 수도 있다.
- 문맥과 상황에 따라 다를 수 있다.
- 중요한 기준은
변경이다. 변경되었을 때, 파급 효과가 적을 경우 단일 책임 원칙을 잘 따랐다고 말할 수 있다.
Ex) UI 변경, 객체의 생성과 사용 분리
2. OCP
개방-폐쇄 원칙(Open/Closed Principle)
- 소프트웨어 요소는
확장에는 Open,변경에는 Closed다형성을 활용- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현한다.
- 기존 코드를 변경하는 행위가 아님
문제점
클라이언트가 인터페이스의 구현 클래스를 직접 선택할 때, 구현 객체를 변경하려면 클라이언트의 코드를 변경해야 한다.
public class MemberService { private MemberRepo mr = new MemoryMemberRepo(); } public class MemberService { //private MemberRepo mr = new MemoryMemberRepo(); private MemberRepo mr = new JdbcMemberRepo(); }
- 다형성을 사용했으나 OCP 원칙에는 위배가 된다. 따라서 객체를 생성하고 연관 관계를 맺어주는 별도의 조립, 설정자가 필요하다.
3. LSP
리스코프 치환 원칙(Liskov Substitution Principle)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것
- 다형성을 위한 원칙
Ex) Car 인터페이스의 엑셀 기능은 앞으로 가는 역할을 맡는데, 뒤로 가게 구현하면 LSP를 위배했다고 볼 수 있다.
4. ISP
인터페이스 분리 원칙(Interface Segregation Principle)
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
(하나의 인터페이스에 많은 기능이 있으면 복잡해지므로)
- Car 인터페이스 -> Drive 인터페이스, Fix 인터페이스로 분리
- User 클라이언트 -> Driver 클라이언트, Mechanic 클라이언트로 분리
- 분리하면 Fix 인터페이스가 변경되어도 Driver 클라이언트에 영향을 주지 않게 된다.
- 인터페이스가 명확해지고 대체 가능성이 높아진다.
5. DIP
의존관계 역전 원칙(Dependency Inversion Principle)
- 프로그래머는
추상화에 의존하지, 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.- 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 의미이다.
역할에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있기 때문이다. 구현 클래스에 의존하게 되면 변경이 어려워진다.문제점
위 코드에서 MemberService는 인터페이스에 의존하지만, 구현 클래스에도 동시에 의존하고 있다.(MemberService 클라이언트가 구현 클래스를 직접 선택) 따라서 저 코드는 DIP 원칙도 위배하고 있다.
마무리
객체 지향의 핵심은 다형성이다. 다형성 만으로 구현 객체를 변경할 때 클라이언트 코드도 함께 변경되므로 OCP, DIP 원칙을 지킬 수 없다. 무엇인가 더 필요해지는데, 여기서 스프링은 Dependency Injection, DI 컨테이너를 제공함으로써 OCP, DIP 원칙을 지킬 수 있도록 지원해 준다.(클라이언트 코드의 변경 없이 기능을 확장할 수 있도록 보장해줌)
