[스프링 핵심 원리 기본] 객체 지향 설계와 스프링

스프링 핵심 가치 

- 객체지향 

 

옛날 옛적에 ejb가 있었음

표준 기술 느낌 

 

정말 어렵고 복잡하고 느림 .. 즉 쓰기가 어렵다 

 

2002년 로드 존슨이 스프링을 만듦

---

필수

- 스프링 프레임워크

- 스프링 부트 

 

그 외

- 스프링 시큐리티

- 스프링 데이터

- 스프링 클라우드 등등

 

 

 

 

 

 

=====

 

좋은 객체 지향이란??

객체지향 특징 

추상화

캡슐화 

상속 

다형성

 

 

유연하고 변경이 용이하다라

-> 다형성!!!

 

다형성!! 가장 중요하당 

 

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

역할이 인터페이스

구현이 인터페이스 구현한 객체

 

역할은 여러가지 구현체로 구현이 가능 

자동차 개념 이걸 구현한게 여러 테슬라 기아 아반떼 

 

운전자는 아반떼에서 테슬라로 바껴도 운전가능하다

자동차가 바껴도 운전자에게 영향이 없다 

즉 유연하고 변경이 용이 

 

인터페이스 즉 역할만 의존하면 그에따른 구현체 아무거나 다 사용가능

클라이언트가 자동차 내부구조 몰라도 된다 

아반떼를 테슬라모델로 바꿔도 그대로 운전가능 

다른 대상으로 변환 가능 및 새 기종 나와도 그대로 사용가능 자동차 세상을 무한히 확장

기름 자동차에서 전기 자동차 타도 됨

세상을 바꾸지 않고 기능을 추가 가능 

역할 과 기능으로 세상을 구분했기 때문에

새로운 자동차가 나와도 클라이언트는 새로 안 배워도 됨!! 

개꿀 

 

 

 

공연을 기획하는 사람

 

로미오역할과 줄리엣 역할이 있음

이 역할은 장동건 송혜교 등등 다 할 수 있음 무명배우라도 가능한 역할 

배우는 대체가 가능 

즉!!!! 대체가 가능함 구현 

 

역할과 구현으로 나누니까 

줄리엣을 누가하듯 로미오는 대본만 잘 외우면 됨 

구현이 바껴도 역할은 영향이 없다 

 

이게 유연하고 변경이 용이핟 ㅏ

 

자전거 타는 법말 아면 3발이든 2발이든 4발이든 가능 

 

 

 

역할이 인터페이스 

구현이 구현체

 

인터페이스를 잘 설계하면 구현체를 바꿔가면서 변경이 가능하다 

역할이 더 중요하다 

 

 

자바 언어의 다형성!

오버라이딩

- 기능을 넘어서 타버린다 즉 재정의 

- 필수만 가지고 그 외 추가적으로 기능을 넘어서 재정의한것 

- 실행시점에 유연하게 변경이 가능 

- 

 

 

클라이언트는 멤버리포지토리를 의존 

멤버 리포지토리는 구현체 2개가 있음 

구현체 2개를 어느것 넣어도 인터페이스가 사용가능 - 다형성

 

부모는 맘이 넓어서 다 품기 가능

자식은 부모 맘 몰라서 대입도 불가

 

 

구현체 멀 넣냐에 따라서 클라이언트가 바라보는 구현체가 달라짐

 

클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경 가능 

 

클라이언트 파란색 변경없이 빨간 녹색으로 변경이 가능 유연하게~~ 

이게 다형성의 본질 

 

 

자동차가 비행기로 바뀌면 좀 큰일이져?

 

대본을 고치면 다 영햐ㅐㅇ을 받죠 

즉 설계할 때 인터페이스를 안정적으로 변함없도록 설계하는 것이 가장 중요

 

 

스프링 사용하면 코드를 바꿔도 전혀 영향없이 구현을 변경할 수가 있다 굳굳

 

---

 

 

변경이 있을 때 파급이 적으면 단일 책임 원칙을 잘 적용한것 

 

 

확장에 열려있고 변경에 닫혀있어야한다라... 

코드 변경없이 기능을 추가한다라... 

 

자동차를 생각해보자

기름차에서 전기차로 바꿔도 운전자는 운전 가능하잖아 

공연도 그럼 

역할이 있고 구현이 있으면 

구현은 무명배우가 해도 되는데! 

 

이게 개방 폐쇄원칙이다 

세상을 바꿀필요없이 기능을 추가해야하는데

위에거는 코드를 수정해버렸죠~~~

ocp랑 다르죠ㅕ

변경에 닫혀있지 않죠!

 

멤버서비스 클라이언트가 구현 클래스를 직접선택해버림 

즉 구현 객체 변경할 때 클라이언트 코드르 변경을 해야함

ocp 깨짐

즉 별도의 조치가 필요하다 이걸 스프링 컨테이너가 해줌

 

이거 근데 설명 어려우니 코드로 확인하자 

 

 

컴파일 단계를 이야기하는게 아니라 

인터페이스상 규약을 무조건 맞춰야하는 것 

엑셀 앞으로 가라고 했는데 뒤로 가면  lsp 깨진거ㅏ임

 

 

자동차 인터페이스 하나만 있으면 너무 크니까 인터페이스를 좀 더 세분화하는거임

분리하면 문제가 생길 때 그 부분만 수정하면 됨 

적당한 크기로 쪼개는 것이 중요!@!@

명확해지고 대체 가능이 됨

 

중요함

 

OCP랑 DIP

 

프로그래머는 추상화에 의존해여ㅑ지 구체화에 의존하면 안 됨 

 

클라이언트가 역할만 바라보도록 구현체가 아니라

역할에만 의존하도록 

 

운전자는 자동차라는 역할에 대해서 알아야지

테슬라 관해서 자세하게만 알면 나머지 자동차 제대로 못 다룰지도

 

원빈이 로미오 역할을 하는데 줄리엣 역할하는 김태희 구현체에 너무 의존해버려서 전지현 구현체랑 연기할 때 연기 못하면 

노답 상황이 되버린다

대체 가능성이 사라짐

 

역할과  구현을 철저히 구분해서 

시스템을 갈아끼울 수 있도록 해야한다 

 

역할에 의존해야지!! 배우는 대본만 ! 운전자는 자동차의 운전만!

역할만 의존하자 = dip

 

클라이언트가 구현체에 의존하면 변경빡세짐 

근데 이거 멤버서비스 클라이언트가 구현체에 의존중이지? 잘못된거임 

구현 클래스르 직접 선택해서 의존중임

 

dip 위반 = > 추상화가 아닌 구체화에 의존 

 

 

핵심은 다형성 

하지만 더 필요하다..

 

---

 

 

컨테이너 - 객체를 넣어서 코드에 넣어줌 : 이걸로 부품 교체하듯 개발 가능 

 

인터페이스를 ㅈ다 설계하고 구현체 만드는 식으로 하면 

디비가 정해져있지 않아도 개발이 가능 

구현체만 낑겨서 바꾸면 되니까 

인터페이스 먼저 만들어 놓으면 기술적인 정책을 뒤에 뺄 수있음 즉 빠르게 개발가능 

 

기능확장이 없는경우 구현체를 쓰는게 맞지만

미래 확장 가능성이 있는 경우 낑겨서 새로 넣을 수 있으니까 추상화 인터페이스를 도입하는 것을 고려해볼만하다

 

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

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