[Spring] 객체 지향 설계와 스프링

객체 지향 프로그램

 

객체들의 모임 .. 객체는 서로 메세지를 통해 협력한다 

유연하고 변경이 용이 

 

 

유연하고 변경이 용이 -> 컴포넌트를 쉽고 유연하게 변경하고 개발가능  - > 다형성 !!

 

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

역할 = 인터페이스

구분 = 인터페이스 구축한 객체 

 

벤츠 탄 사람이 트럭 탈 수 있지 자동차 바껴도 운전자에게 역할은 안 바뀜 

유연하고 변경이 용이 = 내가 자동차 역할을 벤츠에서 덤프트럭으로 바꿔도 운전자는 운전면허만 있으면 가능 

 

자동차 끼리 바뀔때는 새로 운전면허 바뀔 필요 없이 운전가능 

운전자는 자동차 인터페이스만 알고 있음 

자동차 역할을 만들고 구현을 구분한 것은  운전자를 위해!

운전자 = 클라이언트  운전자는 자동차 내부 몰라도 됨 ... 자동차 역할만 하고 있으면 내부적으로 바껴도 이상 없지 

 

이런 걸 다른 대상으로 변환 가능하고 새로운 자동차 나와도 기존 기능만 하면 .. 자동차 세상을 무한히 확장 가능 

기름 자동차가 전기자동차로 바껴도 운전가능하지 

클라이언트에 영향을 주지 않고 새로운 기능 추가 가능 

 

왜 ?

역할과 구현으로 세사을 만들엇으니까 

 

중요한것은 새 자동차가 나와도 클라이언트는 새로운 거 안 배워도 됨 !!!@!@!@

 

 

공연은 되어야함 

역할과 구현을 나눔 

로미오 역할을 배우 1 배우 2 다 할 수 잇찌 

 

로미오 역할 하는 사람은 줄리엣하는 사람이 김태희든 전지현이든 상관없다 대본만 보고 하면 됨 !

 

시끄러운 키보드 쓰다가 무접점 키보드 쓰기 가능하고 

미니벤츠타다가 트럭 탈 수 있고 

 

 

 

세상이 단순해지고 변경도 편리해짐 

핵심은 클라이언트 

클라이언트는 인터페이스만 알면 됨  (로미오 배역 , 자동차 운전 )

클라이언트가 자동차 내부구조 알 필요 없지 

클라이언트가 기름차에서 전기차 바껴도 문제 없지 

클라이언트가 테슬라에서 기름차로 바껴도 영향없음 ... 전기차 나와도 세상을 안 바꿔도 됨 

 

 

인터페이스 다중 상속 

핵심은 구현보다 인터페이스가 먼저 

즉 역할이 더 중요하다 

 

다형성 부모가 있고 그걸 구현한거고 ~  이런 거 할 때 클라이언트가 없ㄷ ㅏ

클라이언트는 요청하는 사람 

 

객체 끼리 응답 주고 받거나 서버끼리 주고 받거나 가능 

 

오버라이딩  -> 다형성 

 

오버로딩 -- 여러개 초과해서 로딩했다 여러개 메서드 

오버라이딩 -> 기능을 넘어서 타버린다 = 재정의 

 

결국 오버라이딩 된 메서드가 실행이 되지 

 

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

멤버 리파지토리에 인터페이스 구현한 빨강이 녹색이 넣기 

 

부모는 마음이 넓기 때문에 자식을 다 품을 수 있따

자식들은 부모 마음을 모르니까 품을 수 없다 

 

 

클라이언트를 변경하지 않고 서버의 구현기능을 유연하게  다양하게 구현 및 변경 할 수 있다

 

 

테슬라가 나와도 운전자는 바로 탈 수 있지 

 

인터페이스 만약 하나 더 추가 하면 그 밑에 다 바꿔여하니까 설계 진짜 잘해야함 

 

 

대본 자체가 변하면 배우들 다 영향 받지 클라이언트 영향 

설계할 때 인터페이스를 잘 설계하는 것이 변화없이 잘 진행 가능하다 

API 를 잘 설계하는 것이 정말 중요 그게 정말 잘하는 개발자

 

객체지향 중에 다형성 !

객체지향의 꽃 

객체지향을 잘 이용하고 살리는 것이 스프링 

 

스프링은 레고 블록을 쓰듯이 배우를 고르듯이  

구현을 편리하게 변경 가능 !!!

 

스프링을 잘하려면 다형성과  sloid 잘 알아야함 

 

 

---

 

 

하나의 클래스는 하나의 책임 - 하나의 책임이라는것은 모호하다 

 

먼가 변경이 있을 떄 파급이 적으면 단일 책임 원칙을 잘 지킨 것 

ui변경하는데 전부 고쳐야하면 잘못 설계... 

 

범위를 너무 좁게하거나 넓게 하는 것이 어렵다 = 객체지향의 묘미 

 

 

가장 중요 

 

확장에는 열려있고 변경에는 닫힌다? 

코드의 변경없이 어떻게 기능을 추가할 수 있나 ?? 구라인가 ??

 

운전자가 트럭 쓰다가 테슬라 쓸 수 있지

공연도  역할이 중요하고 배우는 아무나 가능

 

이게 개방 폐쇠의 원칙 

 

인터페이스를 구현한 새로운 코드 만드는 것은 ?  기존 코드 변경을 주는 게 아니지 ?

 

 

 이거 바뀔 때 변경을 해야하지 ... 클라이언트 코드를 변경을 안 하면 못 바꾸지 ... 

인터페이스 만들고 구현체도 만들었어

다른 거 적용하려니까 ocp가 깨진다 

 

소프트웨어가 주석처리하고 코드 넣고 이걸 해줘야함 ... 그래서 ocp 원칙 지킬 수가 없다

 

그래서 별도의 조립 설정자가 필요하다  === 이걸 스프링 컨테이너가 해준다 이 ocp 원칙을 위해서 여러가지가 좀 필요 !

 

 

 인터페이스가 있고 그 구현체가 있음

자동차 인터페이스가 있고 액셀이 필요 .. 엑셀 밟으면 앞으로 가는데 .. 클래스 만들면서 뒤로 가게 만들면 ?

그래도 컴파일 시 에러 안 남 

 

자동차 인터페이스 의 엑셀은 앞으로 가는건데 뒤로 가게 구현하면 리스코프 치환 원칙을 어김 

 

 

자동차 인터페이스가 하나 있음 

자동차  인터페이스 너무 크니까 정비랑 운전이랑 인터페이스 두개 로나눔

운전자 클라이언트랑 정비사 클라이언트 나눌 수가 있음 

 

이렇게 하면 하나 문제 생길때 그 부분만 보면 됨 

명확해 지고 영향 덜 주고 대체 가능성 높아짐 

 

 

 

OSP  DIP   가장 중요 

 

클라이언트 클래스가 구현 클래스를 바라보는게 아니라 인터페이스를 보란것 

역할에 의존하는 거랑 같음 역할을 봐야함 

 

 

운전자는 자동차 역할에만 충실해야지 

막 테슬라만 보고 ... 그건 아니다 !

 

공연도 

원빈이 김태희랑만 공연연습만 한다고 다른 사람이랑 공연할 때 못하냐 그거 아니지 대체가능성이 없ㅈ ㅣ

 

시스템도 언제든지 갈아끼울 수 잇게 설곟야함 

 

 

즉 역할에 의존해야지 구현에 의존하면 안 됨

배우도 대본에 의존해야지 담당 배우에게 의존하면 다른 배우로 바뀌면 못한다 ?r  공연 폭망 

 

 

 

 

 

 

멤버서비스는 멤버리파지토리 필드 가지고 있고 메모리레파지토리 할당 

즉 멤버서비스 클래스는 멤버 리파지토리랑 메모리 리파지토리 두개에 의존 

 

의존이란 내가 저 코드를 안다 !  알기만하면 의존이라고 함 

 

추상화에 의존해야지 구체화에 의존하면 안됨 

근데 위에 코드는 추상화 구체화 둘 다 의존하니까 dip 위반이고 결국 코드도 변경해야하고 

 

 

멤버 서비스는 클래스 설계시 멤버리파지토리만 바라보도록 설계 했어야함 

 

---

 

스프링 객체 지향 왜 이렇게 많이 나오냐...

 다형성 ocp , dip 되도록 지원해주는게 스프링!! 

 

DI컨테이너 - 자바 객체들을ㅇ 컨테이너에 넣어두고 그 안에서 의존관계를 맺어줌  ... 이런 거 해야 클라이언트코드 변경없이 확장 가능 부품 교체 쉽게 가능 

 

순수하게 자바로 ocp  dip 지키려면 ... 결국 스프링 di 컨테이너를 만들게 됨 아직 잘 몰라도 오케이 

 

 

설계에서 역할과 구현으로 구분 !  자동차와 연극 

 

이상적으로 모든 설계에 인터페이스 부여하는 것이 좋다 = 인터페이스 해 두고 구현체 만들면 ... 어떤 디비 만들지 정해지지 않았지만 그래도 개발은 해야하니 일단 인터페이스로 정해두면 가능하다 ...구현체 선택을 뒤로 미룰수 잇음 ! 

인터페이스 무분별하게 만들면 추상화의 비용이발생 

.... 추상화를 해버리면 개발자가 코드를 한 번 더 열어봐야함 ..  구현 클래스가 먼가 모르니까 코드 한 번 더 봐야함 .. 항상 장점이 단점을 넘어설 때 써야함 

 

기능을 확장 안 해도 되면 그냥 구현체 써도 오케이 .. 확장도 해야할 거 같고 그러면 인터페이스 쓰는 편이 좋음 

 

 

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