01. 객체 지향 설계와 스프링

스프링부트

스프링을 편리하게 사용할 수 있도록 지원하는 웹 프레임워크,

스프링 프레임워크를 도와주는 역할 / 단독으로 사용하기는 힘듦.

 

스프링

자바 기반이며 좋은 객체지향 어플리케이션 개발을 도와주는 프레임워크

 

객채 지향 프로그래밍이란?

컴퓨터 프로그램을 객채들의 모임으로 파악

프로그램이 유연하며 변경에 용이해 대규모 소프트웨어 개발에 강점.

 

객채 지향 특징

다형성

역할과 구현으로 세상을 구분

 

 

자동차가 바뀌어도 운전자는 운전이 가능하다.

즉, 자동차가 바뀌어도 운전자한테 영향 X

운전자를 클라이언트라 할때, 클라이언트는 자동차의 내부 구조를 몰라도 된다

기존 자동차가 변해도, 완전히 새로운 자동차가 나와도 클라이언트는 운전이 가능하다

-> 클라이언트는 대상 역할의 인터페이스만 알면되며, 내부 구조가 변경되거나 구현 대상 자체를 변경해도 영향 X

 

자바 언어의 다형성

역할=인터페이스

구현=인터페이스를 구현한 클래스, 구현 객체

객체 설계 시 역할과 구현을 명확히 분리.

 

오버라이딩

Memory MemberRepository(빨간색)을 넣으면 Memory MemberRepository(빨간색) 서버를 보게되고 save()를 호출하면 Memory MemberRepository save()를 호출한다. 그 반대도 똑같다.

 

좋은 객체지향 설계

5가지 원칙

• SRP : 단일 책임 원칙
• OCP : 개방-폐쇄 원칙
• LSP : 리스코프 치환 원칙
• ISP : 인터페이스 분리원칙
• DIP : 의존관계 역전 원칙 

1. SRP 단일 책임 원칙

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

하나의 책임은 모호한데, 중요한 기준은 변경.

변경이 있을 때 파급된 효과가 적어야 이를 잘 따른 것.

 

2. OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에 열려있어야 하지만 변경에는 닫혀 있어야 함.

아까의 오버라이딩 그림과 구현 클래스이다. 구현 객체를 변경하려면 클라이언트 코드를 변경하여야 한다.

다형성을 사용했지만 OCP 원칙을 지킬 수 없다.

이를 해결하려면 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자 필요.

 

3. LSP 리스코프 치환 원칙

객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꾸는 것이 가능하여야 함.

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

ex) 자동차 인터페이스의 '엑셀'은 앞으로 가는 기능, 뒤로 가게 구현 시 LSP 위반이며 느리더라도 앞으로 가야한다.

 

4. ISP 인터페이스 분리 원칙

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

ex) 자동차 인터페이스-> 운전 인터페이스, 정비 인터페이스로 분리

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

정비 인터페이스가 바뀌어도 운전자 클라이언트에 영향 X

 

5. DIP 의존관계 역전 원칙

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

구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻(아까 보았던 자동차 예시에서 자동차 역할에 의존)

클라이언트가 인터페이스에 의존해야함.

여기서는 MemberService는 MemberRepository라는 추상화 인터페이스에 의존하지만 구체화인 MemoryMemberRepository에도 의존하므로 DIP 위반.

 

 

객체지향의 핵심은 다형성

다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 같이 변경됨.

다형성만으로는 OCP, DIP를 지킬 수 없다. 

 

객체지향과 스프링

스프링은 DI(Dependency Ingection) 컨테이너를 제공하여 다형성 + OCP, DIP를 가능하게 지원

클라이언트 코드의 변경 없이 기능 확장 가능