[Spring] 02. 좋은 객체 지향 프로그래밍이란?

해당 글은 김영한님의 스프링 핵심 원리 - 기본편 - 인프런 | 강의를 수강하고 정리한 게시글입니다.
+참고 : https://www.byfuls.com/programming/read?id=62

객체 지향 프로그래밍(Object Oriented Programming, OOP)

• 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 객체들의 모임으로 파악하고자 하는것. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.(협력)
• 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

유연하고, 변경이 용이?

• 레고 블럭 조립하듯
• 키보드, 마우스 갈아 끼우듯
• 컴퓨터 부품 갈아 끼우듯
• 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법

객체 지향 특징

1. 추상화 : 어떤 실체로부터 공통적인 부분이나 관심있는 특성들만 한곳에 모은것을 의미 (객체지향에서의 추상화는 어떤 하위클래스들에 존재하는 공통적인 메서드들을 인터페이스로 정의하는 것)
2. 캡슐화 : 비슷한 역할을 하는 속성과 메소드들을 하나의 클래스로 모은것 (관련있는 함수와 변수를 하나의 클래스안에 묶은 것)
3. 상속 : 기존에 정의해 놓은 클래스의 재활용을 목적으로 만들어진 요소 (이미 작성된 클래스를 이어 받아 새로운 클래스를 만드는 기법으로 생산성이 높아지고, 유지보수가 좋아진다.)
4. 다형성 : 같은 모양의 함수가 상황에 따라 다르게 동작하는 것을 의미 (오버로딩(Overloading) 오버라이딩(Overriding)이 가능하다는 얘기)
   • 오버로딩(Overloading) : 함수의 이름은 같으나 함수의 매개변수의 개수, 타입등을 달리해서 다르게 사용하는 것
   • 오버라이딩(Overriding) : 상위 클래스의 메소드를 하위 클래스에서 똑같은 이름으로 재정의 하는 것(덮어쓰기)

다형성의 실세계 비유

• 실세계와 객체 지향을 1:1로 매칭X
• 그래도 실세계의 비유로 이해하기에는 좋음
• 역활과 구현으로 세상을 구분

운전자 - 자동차

자동차가 바뀌어도 운전자에게 영향을 주지 않는다! 운전자(client)를 위해 구현과 역할을 분리한 것!

공연 무대 - 로미오와 줄리엣 공연

로미오 역할을 하는 사람은 변경이 용이하고 유연해야함..

역할과 구현을 분리

• 역활과 구현으로 구분하면 세상이 단순해지고, 우연해지며 변경도 편리해진다.
• 장점
  • 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
  • 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
  • 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
  • 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
• 자바 언어
  • 자바 언어의 다형성을 활용
    • 역할 = 인터페이스
    • 구현 = 인터페이스를 구현한 클래스, 구현 객체
  • 객체를 설계할 때 역할과 구현을 명확히 분리
  • 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기

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

SOLID

클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리

1. SRP: 단일 책임 원칙(single responsibility principle)
2. OCP 개방-폐쇄 원칙(Open/closed principle)
3. LSP 리스코프 치환 원칙(Liskov substitution principle)
4. ISP 인터페이스 분리 원칙(Interface segregation principle)
5. DIP 의존관계 역전 원칙(Dependency inversion principle)

1. SRP: 단일 책임 원칙(single responsibility principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 중요한 기준은 변경!! 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것.

2. OCP 개방-폐쇄 원칙(Open/closed principle)

• 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다. (다형성을 활용!!)
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현(역할과 구현의 분리!!)
• 이 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자 설정을 Spring이 해준다.

3. LSP 리스코프 치환 원칙(Liskov substitution principle)

• 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다. 다형성을 지원하기 위한 원칙. 인터페이스를 구현한 구현체를 믿고 사용하기위한 원칙!
• 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP위반!

4. ISP 인터페이스 분리 원칙(Interface segregation principle)

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다
• 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
• 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
• 인터페이스가 명확해지고, 대체 가능성이 높아진다.

5. DIP 의존관계 역전 원칙(Dependency inversion principle)

• 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. (인터페이스에 의존!)
• 구현 클래스에 의존하지 말고, 역할(인터페이스)에 의존하게 해야한다는 것과 같다.
• 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다!

[정리]
- 객체 지향의 핵심은 다형성
- 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
- 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
- 다형성 만으로는 OCP, DIP를 지킬 수 없다.

객체 지향설계와 스프링

• 스프링은 다형성을 극대화해서 이용할 수 있게 해준다.
• 스프링은 제어의 역전(IoC), 의존관계 주입(DI)등을 이용해 다형성 + OCP, DIP를 가능하게 지원한다.
  • DI(Dependency Injection): 의존관계, 의존성 주입
  • DI 컨테이너 제공
• 클라이언트 코드의 변경 없이 기능 확장
• 스프링을 사용하면 마치 레고 블럭 조립하듯이, 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다.

[의존관계 주입 DI(Dependency Injection)]
구현체는 인터페이스에 의존하고 실제 어떤 구현 객체가 사용될지 모른다.
의존관계는 정적인 클래스 의존 관계와 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각!

[제어의 역전 IoC(Inversion of Control)]
기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성, 연결, 실행 한다.
한마디로 구현 객체가 프로그램의 제어 흐름을 스스로 조종하는 것. 개발자 입장에서는 자연스러운 흐름.
하지만, AppConfig가 등장 이후 구현 객체는 자신의 로직을 실행하는 역할만 담당.
즉, 프로그램의 제어 흐름을 AppConfig가 가지게 된 것.
한마디로 프레임워크같은 외부에서 제어 흐름을 관리하는 것을 제어의 역전(IoC) 라고 한다!

[프레임워크 vs 라이브러리]
내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크이다.
내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 라이브러리이다.