[Spring] 객체 지향 프로그래밍

 

스프링의 핵심은 객체지향을 잘 살릴 수 있도록 최적화 됨 

이므로 좋은 객체지향 프로그래밍 방식을 따르는 것이 스프링을 잘 사용할 수 있는 방법 

 

 

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

• 객체지향
• 다형성 
  • 예시 (비유)
  • 자바의 다형성
  • 장점
  • 한계

 

 

객체 지향 프로그래밍?

 

객체 지향 특징

• 추상화
• 캡슐화
• 상속
• 다형성 ★

 

 

객체 지향 프로그래밍?

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다. (협력)

객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프 트웨어 개발에 많이 사용된다

 

 

유연하고 변경에 용이 하다는 것은 "다형성"과 연관된 개념이다 

 

 

다형성

유연하고 변경에 용이

 

( 레고조립, 부품조립 처럼 ) 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법 

 

예시)

세상을 역할(인터페이스) / 구현(인터페이스를 구현한 구현체)으로

 

1. 자동차와 운전자(클라이언트)

자동차(구현체)가 바뀌어도 운전자에게 영향을 주지 않음 

자동차 역할을 갈아끼워도 운전자는 별도의 변경없이 그냥 사용가능 

왜 일까?

운전자는 자동차 구현체가 아닌 자동차 역할(인터페이스)만 제대로 이해해두었으며(= 자동차 역할에만 의존),

자동차 구현체(K3, 아반떼, 테슬라 모델3)는 자동차 역할(인터페이스)을 그대로 받아들여 제작되었기 때문,

 

그 뿐만 아님, 전기차가 나와도 태양열 발전 차가 나와도 자동차의 역할만 따른다면 운전자는 신경쓰지 않아도된다!

→ 이는 운전자(클라이언트)를 위해서 이렇게 구성을 한 것임!

클라이언트에게 영향을 주지 않고 새로운 기능을 무한하게 확장해서 제공할 수 있다! 

 

 

 

2. 배우(구현체)와 배역(인터페이스)

 

배우(구현체)는 대체가 가능, 변경 가능해야한다.

각자 역할에만 충실하게 자신의 기능만 제대로 수행할 수 있다면, 상대 역할을(의존관계에 있지만) 누가할지도 영향을 받지 않는다.

무슨 뜻이냐면, 줄리엣 역할을 누가 맡든, 알 수 없어도 로미오 역할을 맡은 배우는 지장이 없음 (자신의 로미오 역할만 제대로 하면되기 때문)

 

로미오 : 클라이언트 / 줄리엣 : 서버 라고 하면, 줄리엣의 구현이 바뀐다고해도 로미오에 영향을 주지 않음

 

또 다른 예시) 

• 운전자 - 자동차
• 공연 무대
• 키보드, 마우스, 세상의 표준 인터페이스들 ( 마우스를 교체해도 컴퓨터쓰는데 문제 x)
• 정렬 알고리즘( 정렬 기능만 하면 무슨 알고리즘을 써도 대체가능)
• 할인 정책 로직

 

 

 

 

역할과 구현을 분리했을 떄의 장점

인터페이스와 구현체를 사용할 때의 장점 (핵심은 클라이언트)

역할 / 구현 두가지로 만 나누면 모든 것이 단순해짐 → 유연 / 변경 편리

• 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
• 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다. 
• 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

 

 

자바는 다형성을 지원하는 언어이므로, 이를 활용해야한다

자바 언어의 다형성을 활용

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

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

객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

 

*일반 상속관계도 다형성 가능 but 인터페이스로 하는 것이 좋음 / 클래스끼리의 상속은 제약이 많다

구현보다 역할이 더 중요하다! 

 

 

객체 설계시 역할(인터페이스)를 잘 구성하는 것이 어렵다. 

특히, 클라이언트를 간과하기 떄문인데, 잘 구성하는 팁

객체 설계 시 고려사항

객체의 협력이라는 관계부터 생각

혼자 있는 객체는 없다.
클라이언트: 요청, 서버: 응답
수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.

*단순히 공부할 때 요청하는 입장을 항상 잊고, 응답/제공부터 생각하고 구현하는 일이 많다. 그래서 다형성(인터페이스/구현체)개념이 헷갈리는 것! 클라이언트 부터 고려 즉 클라이언트가 무슨 요청을 할지(무엇을 제공할지) 부터 먼저 고려하고 개발해야 인터페이스/구현체를 잘 나눌 수 있음 

 

*클라이언트는 요청 / 서버는 응답 (절대적인 개념이 아니다-> 하나가 요청과 응답을 둘다 할수있으니 클라이언트인 동시에 서버도가능) 

 

 

자바의 다형성
- 자바 언어 자체의 다형성

 

 

오버라이딩

오버라이딩은 자바 기본 문법으로, 오버라이딩 된 메서드가 실행

 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경(같은 메소드가 여러개인데..)할 수 있 다.

물론 클래스 상속 관계도 다형성, 오버 라이딩 적용가능

클라이언트는 MemberRepository를 의존함(알고있다) 

MemberRepository를 2가지 로 구현했다. 둘중 무엇이든 저 자리에 할당이 가능하다 

 

둘다 가능

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

무엇을 할당 했느냐에 따라 save()메소드를 호출했을 때, 어디의 save()메소드 함수가 호출될지가 다르다. 

(하지만 사실 하는 역할은 똑같음 → 데이터베이스에 접근하는 역할을 함, 그런 역할 함수들이 구현되어있음)

 

 

다형성의 본질

인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.

 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야함 (클라이언트를 잊지말아야함)

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

 

 

 

 

정리

역할과 구현을 분리 정리

• 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음 
• 유연하고, 변경이 용이
• 확장 가능한 설계
• 클라이언트에 영향을 주지 않는 변경 가능 (무한하게 확장 가능한 설계)
• 인터페이스를 안정적으로 잘 설계하는 것이 중요★

 

 

한계점

역할(인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다. 

 

예시)

자동차를 비행기로 변경해야 한다면?
대본 자체가 변경된다면?
USB 인터페이스가 변경된다면?

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

 

 

스프링과 객체 지향

• 다형성이 가장 중요하다!
  → 스프링은 다형성을 극대화해서 이용할 수 있게 도와주는 것.
• 스프링에서 이야기하는 제어의 역전(IoC), 의존 관계의 주입(DI)는 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
• 스프링을 사용하면 마치 레고 블럭 조립하듯이! 공연 무대의 배우를 선택하듯이! 구현을 편리하게 변경할 수 있다.