[Spring] 스프링/객체 지향 프로그래밍/다형성/SOLID

스프링 Concept

- Java언어의 특징인 객체 지향을 극대화

- 좋은 객체 지향 애플리케이션을 개발할 수 있도록 도와줌

- 스프링의 IoC, DI는 Java의 다형성을 활용하여 역할과 구현을 편리하게 다룰 수 있도록 도와줌

 

객체 지향 프로그래밍

- 객체 지향 프로그램

= 프로그램들이 여러 객체의 모임, 각 객체는 서로 협력, 유연하고 변경이 용이(부품을 갈아 끼우듯이 개발이 가능)

 

다형성

운전자는 운전하는 방법만 알면 된다.

- 운전자는 자동자의 기능이 바뀌어도 상관없음

- 운전자는 자동차의 내부 구조도 알 필요 없음

- 운전자는 자동차가 아반떼에서 소나타로 바껴도 운전은 할 수 있음

역할과 구현으로 구분

클라이언트는 역할만 알면 된다.

- 클라이언트는 구현체의 구조가 변경되도 영향 X

- 클라이언트는 구현체의 구조를 몰라도 됨

- 클라이언트는 구현체 자체가 바뀌어도 영향 X

(* 역할 자체가 변하면 클라이언트와 서버 모두 큰 변경이 불가피)

=> 유연하고 변경이 용이

=> 확장이 가능한 설계

=> 클라이언트에 영향 X

 

역할 = 인터페이스 (MemberRepository)

구현 = 인터페이스 구현체 (MemberMemberRepository, JdbcmemberRepository)

 

 

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

 

 

 

 

SOLID

SRP 단일 책임 : 하나의 클래스는 하나의 책임

OCP 개방-폐쇄 : SW구성요소는 확장에는 OPEN, 변경에는 CLOSE (새로운 기능은 인터페이스를 새로 구현해서 확장, 클라이언트의 변경 X)

LSP 리스코프 치환 : 인터페이스 규약 준수 (자동차의 액셀을 밟으면 앞으로 가야 함, 뒤로 가면 안 됨)

ISP 인터페이스 분리 : 특정한 클라이언트를 위한 여러 인터페이스가 범용 인터페이스보다 좋음 (자동차 IF -> 운전 IF, 정비 IF)

DIP 의존관계 역전 : 클라이언트는 클래스가 아닌 인터페이스에 의존해야 함 (운전자는 운전법만 알면 되고, 소나타에 대해서는 잘 알 필요 없음)

 

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

이 코드는 다형성을 잘 사용하였지만 OCP와 DIP를 위반함

=> 클라이언트인 MemberService에서 MemoryMemberRepository에서 JdbcMemberRepository를 바꿔 사용하기 위해서 MemberSerivce의 변경이 필요함 (클라이언트가 구현체를 직접 고름 => 클라이언트의 변경)

 

=> 다형성으로는 SOLID원칙을 지키기가 어려움 => 스프링의 IoC, DI컨테이너가 도와줌 (클라이언트 코드 변경 없이 기능 확장)