객체지향 설계와 스프링

onyoo·2023년 1월 30일

스프링부트

Spring-Boot

목록 보기

1/6

주의

이 시리즈는 스프링 핵심 원리 를 수강하며 작성한 필기 내용 아카이브입니다.

EJB ?

금융권에 표준적인 자바 기술이라고 영업을 ..?

ORM 기술 entity bean이라는 것을 가지고 있었음

근데, 비쌈

단, 개발자들에게 너무 힘들었음 복잡하고 어려운데 느림

POJO ?

ejb를 비판하면서 스프링이 나옴 → ejb 컨테이너를 대체함, 단순함의 승리,현재 사실상 표준 기술

하이버네이트 → entity bean 기술을 대체 JPA의 새로운 표준 정의

필드에 있던 개발자들이 좋다고 생각하던것들을 만든 것 → 하이버네이트 JPA

스프링의 역사

예제코드에서 얼마나 대단했길래 오픈소스하자고 제안한것일까?

왜 여기에 열광했는지? 왜 스프링을 많은 사람들이 쓰게되었는지?

스프링 부트 ? 스프링 ?

스프링이 다 좋은데 설정이 너무 힘들다! 톰캣을 올려서 스프링을 올리고 별짓을 다해야함..서버를 내장해서 나온게 스프링부트

리액티브 프로그래밍 → 비동기 논블록킹 처럼 개발할 수 있음 (노드처럼)

스프링이란 ?

여러가지 기술들의 모음

스프링 프레임워크 , 스프링부트 , 데이터,세션,,,등등

핵심기술 : 스프링 DI 컨테이너 , AOP , 이벤트

스프링 DI 컨테이너 기술

스프링 프레임워크

스프링 부트 , 스프링 프레임워크 등을 모두 포함한 스프링 생태계

스프링은 왜 만들었을까?

핵심개념

이 기술을 왜 만들었는가 ? 이 기술의 핵심 컨셉은 ?

스프링은 자바 언어 기반의 프레임워크

자바 언어의 가장 큰 특징은 객체지향 언어라는 것이다.

스프링은 좋은 객체지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

순수한 JAVA 스타일로 돌아가자! 제대로된 객체지향을 하자!

좋은 객체지향 프로그래밍 ?

객체지향특징

추상화 캡슐화 상속 다형성

객체 지향 프로그래밍

객체들의 모임

객체는 메시지를 주고받고, 데이터를 처리할 수 있다(협력)

프로그램을 유연하고 변경이 용이하게 만드는 것

레고 블럭을 조립하듯이

컴퓨터 부품을 갈아끼우듯이

컴포넌트를 쉽고 유연하게 변경가능

다형성

역할과 구현으로 세상을 구분해보자

운전자와 자동차를 에시로 들어보자.

운전자 - 자동차 - K3,아반떼,테슬라모델

자동차의 종류가 바뀌어도 운전자에게 영향을 주지 않음

즉, 자동차의 종류는 운전자는 아무 상관이 없다.. 운전면허만 있으면 되니까

이게 가능한 것은 자동차 인터페이스는 같기 때문이다

운전자는 자동차의 역할만 그대로 하고 있으면 운전자는 자동차에 대해서 알 필요가 없다 !

즉, 이런식으로 구현을 하면 자동차 세상을 확장할 수 있다.

운전자의 영향을 받지않고 자동차 세상을 확장할 수 있다.

연극도 이와 비슷하다.

로미오와 줄리엣이라는 연극을 한다고 가정했을때, 우리는 역할을 맡는 배우가 변경되어도 상관없다. 왜냐하면 해당 배역에 대한 설정은 변하지 않기 때문이다.

역할과 구현으로 세상을 구분하면 세상이 단순해지고 유연해지며 변경도 편리해진다

클라이언트는 대상의 역할(인터페이스)만 알면 된다.

클라이언트는 구현 대상의 내부구조를 몰라도 된다.

클라이언트는 내부 구조가 변경되어도 영향을 받지않는다.

자바 언어의 다형성을 활용

역할 = 인터페이스

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

객체를 설계할 때 역할과 구현을 명확히 분리

자바언어의 다형성 → 오버라이딩

다형성의 본질 → 클라이언트를 변경하지 않고, 서버의 구현기능을 유연하게 변경할 수 있는 것

역할과 구현을 분리

실세계의 역할을 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음

유연하고, 변경이 용이

확장가능한 설계

인터페이스를 안정적으로 잘 설계하는 것이 중요하다

한계점?

대본자체가 변경된다면?

인터페이스가 변경된다면?

인터페이스를 안정적으로 잘 설계하는 것이 중요하다.

스프링과 객체지향

다형성이 가장 중요하다

스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.

스프링에서 이야기하는 제어의 역전,의존관계 주입은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.

스프링을 사용하면 마치 레고 블럭 조립하듯이 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다.

SOLID 좋은 객체 지향 설계의 5가지 원칙

좋은 객체지향 설계의 5가지 원리!

단일 책임 원칙

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

하나의 책임이라는 것은 모호하다? → 클수도,작을수도,,문맥과 상황에 따라 다르다…

중요한 기준은 변경이다 ! 변경이 있을때 파급효과가 적으면 단일 책임 원칙을 잘 따른것

예) 객체의 생성과 사용을 분리

개방 폐쇄 원칙

확장에는 열여있으나 변경에는 닫혀있어야한다 ?

확장을 하려면 기존 코드를 변경해야한다.. 근데 변경에는 닫혀있어야한다 ?

어떻게 코드의 변경없이 기능을 추가 ? → 다형성을 활용해보자!

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

역할과 구현의 분리 ! 이것이 핵심이다.

구현체를 사용하여 구현 클래스를 변경할 때 클라이언트에서 코드 수정이 이루어져야한다.

구현 객체를 변경하려면 클라이언트 코드를 변경해야한다

이 문제를 어떻게 해결해야할까? → 객체를 생성하고,연관관계를 맺어주는 별도의 조립 설정자가 필요하다.

요것이 바로 DI 컨테이너!!

리스코프 치환 원칙

자동차 인터페이스에서 악셀이라는 기능을 구현한다고 가정해보자, 악셀을 이용해서 앞으로 가는것이 기본적이나, 뒤로가는 기능을 만들수는 있다 이러한 경우가 바로 리스코프 치환 원칙을 위반하는 경우이다.

즉, 다형성에서 하위 클래스는 인터페이스의 규약을 다 지켜야 한다는 것이다. 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면 이 원칙이 필요하다!

인터페이스 분리 원칙

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

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

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

정비와 관련된 기능을 바꿀때 정비 인터페이스 부분만 바꾸면 된다.

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

의존관계 역전원칙

추상화에 의존해야지 ! 구체화에 의존하면 안된다 → 이를 따르는 방법 중 하나다 !

클라이언트코드가 구현체를 바라보는 것이 아닌! 인터페이스를 바라보아야 한다는 것이다.

역할과 구현의 분리를 철저하게

의존한다 = 내가 저 코드에 대해서 안다?

private MemberRepository memberRepository = new JdbcMemberRepository();

요 코드를 보면 MemberRepository에 정확하게 new를 이용하여 JdbcMemberRepository 를 할당하고있다.

인터페이스만 알고있는 것뿐만이 아니라 JdbcMemberRepository도 알고있는것이 문제가 된다.

MemberService 클라이언트가 구현 클래스를 직접 선택함 → 구체화에 의존하고 있는 상태

그래서 어쩌라는거지 ?

객체지향의 핵심은 다형성이다.

하지만 다형성 하나로는 쉽게 부품갈아끼우듯이 개발할 수는 없다.

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

뭔가 더 필요하다 !