모르겠다.
정말 셀 수도 없이 많이 들어본 개념이지만 들을 때 마다 모르겠다.

그치만 오늘은 수업을 들었으니 이번 기회에 진짜 조금이라도 객체지향 프로그래밍이랑 친해져보고자 수업 내용을 바탕으로 몇자 적어본다. 수업도 (1) (2)가 있으니 오늘은 객체지향 프로그래밍이 뭘까?(1)이다.

목표

개발의 방법론을 정의로만 접근하면 너무 추상적이라고 느껴질 때가 많다.
그래서 OOP가 무엇인가 보다 무엇을 이루고자 하는가를 아는 것이 거 와닿을 것 같다.
객체지향 프로그래밍은 여러 객체들이 각자의 책임과 역할을 가지고 서로 협력하여 문제를 해결하도록 하는 것이다.
객체들은 각자의 전문성을 가지고 자신의 역할을 수행하며 자신이 해결할 수 없는 문제의 경우에는 의존하고 있는 객체에게 요청하여 해결한다.
문제를 위임한 객체는 의존하고 있는 객체가 어떤 식으로 문제를 해결하는지는 신경쓰지 않고 완전히 전적으로 위임해야하며, 반대로 위임받은 객체는 문제를 위임한 객체가 결과물을 어떤 식으로 사용하는지 신경쓰지 않고 자율적으로 문제를 처리해야한다.
객체지향 프로그래밍에서 객체들은 의존하는 객체의 변경될 경우 영향을 받을 수 밖에 없다.
이런 변경의 전파를 최소화하여 책임을 분리한 효율을 높이는 것이 객체지향 프로그래밍의 지향점이다.

캡슐화

캡슐화는 앞서 설명한 변경의 전파를 최소화하는 수단 중 하나이다.
강사님께서는 캡슐화가 다른 OOP의 특징들보다 더 핵심ㅈ적인 요소라고 하셨다.
위키피디아에서 캡슐화의 정의를 살펴보면 객체의 속성(data fields)과 행위(메서드, methods)를 하나로 묶고, 실제 구현 내용 일부를 내부에 감추어 은닉한다. 고 나와있다.
위에서와 마찬가지로 캡슐화의 목표는 객체의 외부로부터 일부를 은닉하는 것이다.
그렇다면 무엇으로부터 무엇을 왜 은닉하는 것일까?

소비자가 토마토 직판장에서 토마토를 구입하고 판매한다고 생각해보자

• 무엇을 무엇으로부터 은닉하는가
  OOP에서 객체는 서로 다른 객체에게 의존한다고 했다. 그렇기 때문에 여기서 무엇으로부터 은닉하는가에 대한 대답은 해당 객체를 의존하고 있는 객체(Client 객체)로 부터 은닉하는 것이다.
  무엇을 은닉하는가는 문제를 위임받은 객체가 갖고 있는 것들 중에서 구체적인 것, 변경될 가능성이 높은 것을 은닉한다. 주로 어떻게 문제를 해결할 것인가에 대한 내용이 그것이다.
  위의 그림을 예로 들면 소비자는 토마토 직판장에서 토마토를 몇 개 구입하겠다고 전달했으면 토마토 직판장이 어떤 토마토 농가에서 토마토를 사왔고 그 토마토를 어떻게 운반했고 등의 상세한 내용은 알 필요가 없는 것이다.

• 왜 은닉하는가?
  이것은 앞서 말한 OOP의 지향점과 일맥상통하는 것으로 변경의 전파를 최소화하기 위해서이다.
  앞의 예시로 돌아가서 5개의 토마토를 사기로 하고 직판장에 의사를 전달 했더니 돈을 받고는 대뜸 A 창고로 B 섹터로 가서 5개 가져가시오라고 대답했고 소비자는 A 창고는 어디며 B 섹터는 어딘지 알아내서 기억해뒀다.
  여기서 다음에 다시 토마토를 구입하겠다고 했더니 이번엔 C 창고 D 섹터에서 가져가라고 바뀌었다면 어디로 가야 하는지를 또 다시 알아내야 한다.
  토마토 직판장의 변경점이 소비자(Client 객체)에 전파된 것이다.

추상화

객체 자체가 다른 객체로 대체되거나 확장될 수 있는 상황이 온다면 그 객체는 구체적인 상태이며 좀 더 추상적인 상태로 바꿔줄 필요가 있다.
변경 가능한(구체적인 것) 것의 범위를 객체 내부의 동작에서 객체 자체로 확장시킨 것이다.

다시 토마토 직판장으로 돌아가면 소비자가 토마토만 구입하는 것이 아니라 사과도 먹고 싶고 포도도 먹고 싶어진 상황이 된거다. 그래서 청과상(상위 타입)에서 토마토가 아니라 과일을 구매하는 것(추상화된 동작)이다.
추상화는 얼핏 캡슐화와는 상관이 없어보일 수 있지만 구체적인 것(토마토 구입)을 숨기고 추상적인 것을(과일 구입) 드러낸다는 점에서 같은 목적을 가지고 있다.
앞서 말했듯 OOP에서 객체간의 의존은 불가피한 것이기 때문에 부작용이라고 할 수 있는 변경의 전파를 최소화 하는 것이 주 목적이다.