[Spring] 객체 지향 설계 원칙 - SOLID

 

면접 질문으로도 가끔 나오는 내용

 

SOLID

좋은 객체 지향 설계의 5가지 원칙 - 로버트 마틴(클린코드 저자)

• SRP: 단일 책임 원칙(single responsibility principle)
• OCP: 개방-폐쇄 원칙 (Open/closed principle)
• LSP: 리스코프 치환 원칙 (Liskov substitution principle)
• ISP: 인터페이스 분리 원칙 (Interface segregation principle)
• DIP: 의존관계 역전 원칙 (Dependency inversion principle)

 

 

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

 

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

 

사실 모호한 개념 → 클 수 있고(그 클래스의 책임이 너무 많음), 작을 수 있으며(클래스가 너무 많아짐) 문맥 상황에 따라 다름 

그럼 어떻게 정해야하나? 이에 대한 판단 기준은 변경 

특정 변경이 생겼을 때 파급 효과가 적은 경우 단일 책임 원칙을 잘 따른 것이다

ex) UI를 변경했는데, sql코드부터 application을 다 수정해야한다면? → 설계를 못한거

 

 

OCP
-
개방-폐쇄 원칙(Open Close Principle)

가장 중요

소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다.

 

다형성을 활용한다(코드의 변경없이 기능을 추가한다!) 

인터페이스를 구현한 새로운 클래스를 만들어서 새로운 기능을 구현한다 

역할과 구현의 분리!

 

문제점

(이전 강의의 Member예제를 참고하자)

MemberService가 MemberRepository를 의존하고 있다. 

이를 구현체로 MemoryMemberRepository를 사용하다가, 새로운 구현체인 JdbcMemberRepository를 구현하여서, 이로 변경하려고 한다. 

그렇다면, (클라이언트) 코드에 변경사항이 전혀 없을까?

public class MemberService {
//  private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JdbcMemberRepository();
}

위를 주석처리하고, 아래와 같이 변경해야한다. → 변경이 발생했다는 것 

 

문제점은 여기서 발생한다.

MemberService라는 클라이언트가 구현 클래스를 직접 선택하기 때문에 코드 변경이 필연적이다.

즉, 

• 구현체를 변경하려면 클라이언트 코드를 변경해야한다.
• 다형성을 이용했음에도 OCP원칙을 지킬 수 없었다.

→ 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 별도 설정자가 필요하다! 

이것이 바로 스프링 컨테이너 (DI등등) 가 해주는 일이다! 

 

 

LSP
-
리스코프 치환 원칙
(Liskov Subsitution Principle)

 

특정 인터페이스와 구현체가 있을 때, 

모든 구현체는 인터페이스가 가진 규약을 지켜야한다. (단순히 컴파일 에러가 나지 않는 것을 의미하는 것 X)

다형성을 지원하기 위한 원칙으로, 인터페이스를 구현한 구현체를 믿고 사용하기 위해서는 이 원칙을 지켜야한다.

 

예)

자동차 역할의 인터페이스가 존재,

인터페이스 내에 excel이라는 메소드가 존재한다.

excel메소드는 자동차를 가속하는 것으로 규약이 정해져있다. 

자동차 구현체 A를 실제로 구현할 때, excel메소드에 감속기능을 구현해도 컴파일 상 문제가 없다. 

하지만, 이는 인터페이스가 가진 규약을 지키지 않았으므로 리스코프 치환 원칙을 위배하는 것

 

 

 

 

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

 

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

기능에 맞게 적당한 크기로 인터페이스를 쪼개자

 

예)

자동차에는 여러가지 기능이 있다. 운전관련 기능, 정비관련 기능 등등.. 이를 하나의 인터페이스가 아닌 둘로 분리한다.

자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스로 분리

이렇게 되면, 클라이언트 또한 2개로 나눌 수 있다. 

사용자 클라이언트 → 운전자 클라이언트, 정비사 클라이언트로 분리

이것이 장점!

분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음

인터페이스가 명확해지고, 대체 가능성이 높아진다.

 

 

 

 

DIP
-
의존관계 역전 원칙
(Dependency Inversion Priciple)

중요!

프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 

쉽게 이야기해서 구현 클래스에 의존X 인터페이스에 의존O 

 

좋은 예)

 

클라이언트는 인터페이스를 바라봄(인터페이스에 의존)

 

나쁜 예)

 

즉, 

앞에서 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 

객체 세상도 클라이언트 가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다! 

구현체에 의존하게 되면 변경이 아주 어려워진다.

예) k3(구현체)만 운전할 수 있는 운전자(클라이언트)가 차를 바꿀 수 있을까? 

운전자는 자동차(role)를 운전할 수 있어야지, 특정 모델(구현체)만 운전 가능해서는 변경이 아주 어렵다.

 

 

위에서 OCP위반했던 MemberSerive는 사실 DIP도 위반하고 있다.

public class MemberService {
//  private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JdbcMemberRepository();
}

MemberService라는 클라이언트가, MemberRepository라는 인터페이스 뿐만이 아니라, 구현체 자체도 동시에 의존하고 있다.

구현 클래스를 MemberSerivce가 직접 선택 중 

(추상화에 의존해야지 구체화에 의존하면 안된다.)

→ DIP를 위반 중 

 

어떻게 해결하는지는 나중에~ 

 

 

 

스프링과 객체지향

 

• 객체 지향의 핵심은 다형성
• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다. 
• 다형성 만으로는 OCP, DIP를 지킬 수 없다 → 뭔가 더 필요하다!