[디자인패턴] 좋은 객체 지향 설계의 5가지 원칙 SOLID(feat: Spring)

SOLID 원칙을 알아야 하는 이유

시스템에 새로운 기능이 확장되거나 변경사항이 있는 경우 기존 기능들이 영향을 적게 받는 것이 좋은 설계이기 때문. 이 좋은 설계를 하기 위해 나타난 다섯가지 원칙을 가지고 있는 것이 SOLID원칙이다.

이 원칙을 사용하면 코드를 확장하고, 유지 보수 관리하기가 쉬워지며, 불필요한 복잡성을 제거해 개발의 생산성을 높일 수 있다. 

또한, 면접 단골 질문이라고 하니 잘 기억해두면 좋겠다. 

 

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

• 한 클래스는 하나의 책임만 가져야한다. -> 한 클래스가 여러개의 기능을 수행하면 안된다는 것. 
• 만약 한 클래스가 여러개의 기능을 수행하면, 변경이 일어났을 때 수정해야할 코드가 증가. ex. A를 수정하였더니 B를 수정하고, C수정해야하고.. 연쇄적으로 수정 -> 한 책임의 변경으로부터 다른 책임의 변경으로의 연쇄 작용을 극복 가능.
• 한 책임이라는 기준이 모호하지만, 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적다면 단일 책임 원칙을 잘 따른 것이라고 볼 수 있다. 

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

• 확장에는 열려 있으나 변경에는 닫혀 있어야 한다. -> 다형성의 활용
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현. 
• 예를 들어 자동차 기능을 명시해놓은 인터페이스가 있고, 이 인터페이스를 상속받아 테슬라를 구현하는 클래스를 제네시스로 바꾸고싶다. 그러면 자동차 인터페이스를 상속받은 제네시스 구현 클래스를 하나 더 만들어야지 테슬라를 구현하는 클래스를 고쳐서 제네시스 클래스로 바꾸지 말라는 이야기이다. -> 역할과 구현의 분리.(역할: 인터페이스, 구현: 그 인터페이스를 상속받아 기능을 구현하는 클래스)
• 정리하자면, 추상화 사용을 통한 관계 구축을 권장 의미

OCP(Open/Closed Principle) 문제점

MemberService가 MemberRepository구현 클래스를 직접 선택한다. 

MebmerRepository memberRepository = new MemoryMemberRepository(); // 기존

MemberRepository memberRepository = new JdbcMemberRepository(); // 변경

이 구현 객체를 사용하는 클라이언트 코드를 변경해주어야 한다. -> 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. 

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

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야한다. 
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다. 예를 들어 자동차 인터페이스에서 사용하는 엑셀 인터페이스는 뒤로가면안된다. 앞으로 가야한다. 오류 발생 여부의 기준이 아니라 하위 클래스가 상위 인터페이스의 규약을 꼭 지켜서 프로그래밍 하여야 한다. -> 이를 통해 인터페이스를 구현한 구현체를 믿고 사용할 수 있기 때문. 

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

• 인터페이스를 각각의 사용에 맞게끔 잘 분리해야한다. 
• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. 
• ex. 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리, 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
• -> 이를 통해 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않는다. 
• ISP 원칙 주의점: 한 번 인터페이스를 분리하여 구성해놓고, 또 분리하면 안됨. -> 인터페이스는 한 번 구성하면 최대한 변하면 안되는 정책 개념

5. DIP(Dependency Inversion Principle): 의존 역전 원칙

• 클래스가 아닌 인터페이스에 의존해라. <- 추상화에 의존해야지, 구체화에 의존하면 안된다. 
• 이를 통해 유연하게 구현체를 변경 가능. 구현체의 의존은 변경을 어렵게 만듬. 
• 아까 OCP에서 사용한 예시와 같다.

MebmerRepository memberRepository = new MemoryMemberRepository(); // 기존

MemberRepository memberRepository = new JdbcMemberRepository(); // 변경

이렇게 하지말란얘기. -> DIP 위반

 

인터페이스 도입의 단점

추상화라는 비용 발생

-> 기능을 확장할 가능성이 없다면, 구체 클래스를 직접 사용하고 향후 꼭 필요할 때 리팩토링하여 인터페이스를 도입하는 것도 방법이다. 

 

References

인프런 - https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 강의 - 인프런

https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID

💠 객체 지향 설계의 5가지 원칙 - S.O.L.I.D