객체지향 프로그래밍(OOP)?

1.객체지향 프로그래밍(Object-Oriented Programming)

컴퓨터 프로그램을 객체들의 협력과 결합으로 파악하고자 하는 컴퓨터 프로그래밍의 패러다임
객체지향 프로그래밍은 크게 캡슐화, 상속, 다형성, 추상화 4가지 요소를 가지고있다.

1-1. 추상화

객체의 공통적인 속성과 기능을 추출하여 정의하는것
즉, 테슬라, k3, 벤츠 라는 객체들이 있을 때, 추상 클래스(abstract class)와 인터페이스(interface)를 이용해서 Car라는 공통 개념을 추출하여 정의하는 것

1-2. 캡슐화

변수와 함수를 하나의 단위로 묶어 클래스를 통해 구현
하나의 캡슐(capsule)로 만들어 데이터를 외부로부터 보호하는 개념

• 데이터 보호(data protection)
• 데이터 은닉(data hiding)

즉, 외부로부터 클래스에 정의된 속성과 기능들을 보호하고, 필요한부분만 외부로 노출될 수 있도록 하여 각 객체 고유의 독립성과 책임 영역을 안전하게 지키고자 하는 목적

1-3. 상속

자식 클래스가 부모 클래스의 특성과 기능을 물려받는 것
자식 클래스는 부모에 기능에 자신만의 특성을 추가 가능

• 부모 = 기아 자동차
• 자식 = 모닝, 레이, K3, K5, 스팅어...

오버라이딩(overriding)을 통해 상속받은 기능을 재정의 가능
캡슐화를 유지하면서 코드의 재사용이 가능

1-4. 다형성 ✨

자동차의 역할 = 인터페이스
운전자는 운전면허만 있으면 어떤 자동차든 운전할 수 있다.

운전자는 k3가 어떻게 작동하는지, 테슬라가 어떻게 작동하는지는 중요하지 않다.
운전자는 그 자동차가 자동차의 역할을 수행할 수 있다면,
전기로 가든지, 기름으로 가든지 상관없이 운전자는 그 자동차를 운전할 수 있다.

따라서 운전자는 자동차의 역할만 잘한다면, 자동차의 종류는 무한하더라도 상관없다.

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

유연성과 변경및 확장이 편해지기 위해서 역할과 구현을 분리해야 한다.
어떻게 역할과 구현을 분리하나?

다형성(polymorphism)을 이용

역할: 인터페이스
구현: 인터페이스를 구현한 클래스, 구현 객체

장점

클라이언트를 변경하지않고 서버에서 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작해야한다.
클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

단점

인터페이스가 변하면, 이를 구현하는 구현체 뿐아니라 클라이언트, 서버 모두가 변경되야 한다.
그렇기에 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.

스프링과 객체 지향

1) 다형성이 가장 중요!
2) 스프링은 이러한 다형성의 장점을 극대화한다.
3) 스프링의 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해
역할과 구현을 편리하게 다룰 수 있도록 지원한다.

---

2. 객체지향적 설계 원칙 SOLID

2-1. SRP 단일 책임 원칙(Single responsibility principle)

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

책임이라는 것을 어떻게 판단?
=> 중요한 기준은 변경이다.

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

2-2. OCP 개방-폐쇄 원칙 open close

✨가장 중요!!!!!!!!!!!!!!!!!!!!

확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다.
=> 다형성을 이용

객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요 => 스프링 컨테이너에서 해준다

2-3. LSP 리스코프 치환 원칙 Liskov substitution

하위 클래스는 인터페이스에서 정한 규약을 지켜야 한다는 것

자동차 인터페이스에서 엑셀은 앞으로 가라는 기능.
=> 뒤로가게 구현하면 LSP 위반!!

2-4. ISP 인테페이스 분리 원칙 Interface segregation

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

• 자동차 인터페이스: 운전, 정비 인터페이스로 분리
• 사용자 클라이언트: 운전자, 정비사 클라이언트로 분리
  => 정비 인터페이스가 변해도 운전자 클라이언트에는 영향을 주지 않음

2-5. DIP 의존관계 역전 원칙 Dependency inversion

추상화에만 의존, 구체화에 의존하면 안된다.

즉, 클라이언트 코드가 인터페이스만 바라봐야 한다.
클라이언트는 구현 클래스에 대해 몰라야 한다.
=> 운전자는 자동차의 역할의 대해서만 알면 된다.

의존한다? = 내가 저 안의 코드를 안다! = 내가 저 안의 코드를 썻다.

---

참고

https://www.codestates.com/blog/content/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%ED%8A%B9%EC%A7%95