객체지향 프로그래밍 - 캡슐화, 추상화

특강시간에 공부한 것을 바탕으로 내용 정리! ヽ（≧□≦）ノ

개인적으로 개념적인 이해만 하고 있었던 터라, 이런 강의를 여유가 있을 때 듣는것이 얼마나 좋은 일인지…

---

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

OOP, Object-Oriented Programming

객체지향 프로그래밍은 컴퓨터 프로그래밍의 패러다임 중 하나.

객체지향 프로그래밍이란, 각자의 책임을 지는 객체들이 서로 협력함으로써 문제를 해결하는 것.

* 패러다임 : 어떤 한 시대 사람들의 견해나 사고를 근본적으로 규정하고 있는 테두리로서의 인식의 체계, 또는 사물에 대한 이론적인 틀이나 체계를 의미하는 개념

→ 프로그래밍 패러다임
ex) 객체지향 프로그래밍 : 프로그래머들이 프로그램을 상호작용하는 객체들의 집합
      함수형 프로그래밍 : 상태값을 지니지 않는 함수값들의 연속

 

객체 프로그래밍의 핵심 가치

• 협력에 참여하는 객체는 전문가로써 각자의 책임을 가짐
• 목표는 하나의 객체의 지휘하에 달성되는 것이 아니라, 객체들이 협력함으로써 이루어져야함
  • ex. main fun에 모든 기능을 몰아두는 식의 코드가 아닌, 여러 객체들로 기능을 나누어 사용한다.
• 객체가 못하는 것이 있다면, 다른 객체에게 요청해 해결. 단, 그 객체가 어떻게 처리하는지에 대해는 전적으로 믿고 위임해야함.
• 책임을 가지는 객체들은 자율성을 갖고 그 책임을 수행함. 해당 객체들은 전문가로써, 누군가가 믿고 맡길만한 전문성을 가져야함.

 

 

의존성과 변경의 전파

의존성이란?

“알고 있다.” = 협력에서 요청할 수 있다. = “의존하고 있다.”

의존성은 변경을 전파한다는 문제점이 있다. 하지만, 의존성을 없앨수는 없다.

⇒ 의존성이 변경을 전파하는것을 최소화해야한다! (객체지향 원리의 근본적인 WHY)

 

 

객체 지향의 핵심은 캡슐화

객체 지향의 4대 특징 : 상속, 추상화, 캡슐화, 다형성

→ 이번 포스터에서 다룰 것 : 캡슐화, 추상화

캡슐화 : Client 객체가 구체적인 것을 의존하지 못하도록 숨기고, 추상적인 것만 의존하도록 하는 모든 과정.

다음과 같이 객체가 있을 때, 누가 Client 객체인가?
   A객체 → B객체 → C 객체

A⇒B: A가 client 객체
B⇒C: C가 client 객체

구체적인 것 vs 추상적인 것

• 구체적인 것
  • 변경될 가능 성이 높은 것.
  • 메소드가 어떻게 동작하는지에 대한 How가 대표적인 구체적인 것.
• 추상적인 것
  • 변경될 가능성이 낮은 것.
  • 메소드 이름 파라미터 반환값 등 What에 대한 것이 대표적인 추상적인 것.

 

OOP에서는 이렇게 부르기도 한다.

• 구체적인 것 = 낮은 수준
• 추상적인 것 = 높은 수준

 

구체적인것과 추상적인 것은 상대적인 것이고 상황에 따라서 다르게 판단할 수 있다.

 

그렇다면 왜 구체적인 것에 의존하면 안되는가? → 구체적 의존 = 결합도 ↑

• 캡슐화를 통해 구체적인 것을 Client 객체로 부터 숨긴다.
• 구체적인 것의 변경이 Client로 전파되지 않아 변경에 유연해진다.
• 이 상태를 캡슐화를 통해 Client 객체와의 낮은 결합도를 구현했다고 할 수 있다.

⇒ 의존성과 변경의 전파로부터 캡슐화로 이어져오는 이 맥락을 이해하는게 가장 핵심

 

상속, 추상화, 다형성을 이러한 캡슐화를 구현해주는 객체지향프로그래밍언어의 도구.

⇒ 캡슐화를 이해하면 상속, 추상화, 다형성이 왜 필요한지 알 수 있다.

 

캡슐화를 어떻게 하는가?

캡슐화는 정해진 것이 없다. 다만, 추구해야하는 방향성이자 관점이다.

그렇기 때문에 캡슐화의 본질이 무엇인지 기억하는 것이 중요하다.

Step 1 / 자주 변경되는 것과 그렇지 않은 것을 분리하자.
Step 2 / 자주 변경되는 구체적인 것을 Client 객체로 부터 숨긴다.
   → 숨기는 과정에서 상속, 추상화, 다형성 등이 사용되기도 한다.

 

구체적인 것을 가능한 늦게 결정하자!

→ 구체적인 것이 결정되지 않은 상태에서는 CLient 객체가 구체적인 것에 의존할 수 있다.

• 실천 TIP : 호출하는 쪽 코드, Client 객체의 코드를 먼저 작성할 것.

 

 

더 높은 수준의 캡슐화를 위한 추상화 타입

“변경” 에는 특정 객체의 구체적인 코드가 일부 변경되는 경우도 있지만, 객체 자체가 다른 객체로 대체/확정되는 변경도 있다.

e.g ) 사용자의 요청을 받아 소셜 로그인을 처리해준다.

SocialLoginService는 KaKaoOAuth2Client가 어떻게 카카오와 대화하는지 모름.

⇒ 이미 캡슐화가 구현되어 있다

⇒ 다른 말로, SocialLoginService와 KakaoOAuth2Client의 결합도가 낮다고 할 수 있다.

SocialLoginService가 KakaoOAuth2Client를 모르게 만들 것. → 더 높은 수준의 캡슐화, 더 낮은 결합도!

 

방법 → 추상화 타입 사용

Step 1 / 추상적인 것들만 모아 상위타입을 만든다.

     ⇒ 일반적인 행위에 대한 what. 하지만, 그 외에도 추가 가능하다.

          행위에 대한 what만 존재한다면 Interface

          다른것이 포함되어 있다면 Abstract Class

Step 2 / Client 객체가 추상화 타입만 알도록(의존) 만든다.

 

추상화 타입을 만드는 것은 변경 가능한 것에 대한 범위를 객체 자체로 넓히겠다는 뜻.

 

추상화 타입을 쓰는 이유

• 객체 하나의 구체적인 것 뿐만 아니라, 객체 자체가 대체/확장 되는 변경에도 유연하게 대응 가능. ( OCP )
• 요청을 보내는 Client 객체와 그 작업을 처리하는 객체의 관심사를 명확히 분리할 수 있음.
• 다형성 구현 가능
• Client 객체보다 Client 객체가 의존하는 객체가 더 낮은 수준의 구체적인 것일 경우 의존성 역전 → DIP 구현.

 

정리

1. 객체지향 프로그래밍은 객체 사이의 협력을 만들어나가는 과정이고, 그 과정에서 의존성은 반드시 필요하다.
2. 하지만 의존성은 변경을 전파해 변경에 유연한 프로그램을 만드는데 방해한다.
3. 따라서 우리는 의존성이 변경을 전파하는 것을 최소화하기위해 노력해야한다.
4. 변경의 전파를 최소화하기 위해서는 Client객체가 자주 변경되는것을 의존해서는 안된다.
5. 자주 변경되는 것, 즉 구체적인 것을 Client 객체가 의존하지 못하도록 캡슐화를 해야한다.
6. 객체의 일부가 자주 변경되는 것이 아니라(OCP, Open-closed Principle : 개방 폐쇄 원칙) 객체 자체가 변경될 수 있다면 객체 자체를 구체적인것으로 봐야한다.
7. 추상적인 것들을 모아 상위타입으로 추상화시키고, Client 객체는 높은 수준의 추상화 타입(DIP, Dependency Inversion Principle : 의존 역전 원칙)만 의존하도록 해 더 높은 수준의 캡슐화가 가능하다.

---

아직 포스트에는 올리지 못했지만, 지금 TodoList 앱 백엔드 서버를 구현중이다. WebLayer와 ServiceLayer의 관계 부분이 캡슐화와 추상화 설명의 예시와 아주 잘 맞아 떨어져 이해가 더 빨리 된 것 같다. 다음주에 이어서 다형성과 상속에 대해 알려주신다고 했는데, 개인적으로 매우 기대된다!