OOP 소개

2.1 OOP의 주요 개념

객체 지향 프로그래밍 패러다임은 객체 지향적인 접근 방식의 핵심이야. 프로그램의 모든 엔터티를 객체로 취급하는 거지. 객체는 데이터 + 그 데이터를 다루는 메서드/함수로 이루어져 있어.

또 다른 말로 객체는 상태와 행동을 가지고 있어. 객체의 상태는 객체의 내부 변수에 저장된 데이터에 의해 제공되고, 객체의 행동은 그 메서드들이 수행하는 모든 행동의 합이야.

중간 크기의 프로그램에는 수많은 객체가 있고, 큰 프로그램에는 수백만 개의 객체가 있어. 혼란을 줄이기 위해 객체를 클래스에, 클래스를 계층 구조로 조직하기로 했어.

각 객체는 그 객체를 생성하는 클래스가 있어. 한편으론 클래스는 객체의 템플릿이고, 다른 한편으론 그 자체로서 독립적인 객체지 (자세한 건 아래에 설명할게).

클래스의 개념을 더 잘 이해하려면 다음 정의를 확인해봐:

클래스 — 객체를 생성하기 위한 템플릿이나 스킴이야. 이 클래스는 이 타입의 모든 객체에 공통적인 속성과 메서드를 정의해. 클래스는 데이터를 조직하고 그 데이터와 작동하는 기능을 하나로 결합할 수 있게 해줘.

객체 — 클래스의 인스턴스야. 각 객체는 상태 (속성에 의해 정의됨)와 행동 (메서드에 의해 정의됨)을 가지고 있어.

캡슐화 — 클래스의 내부 구현을 숨기고, 그 객체와 상호작용할 수 있는 인터페이스를 제공하는 것이야. 이는 데이터를 보호하고 그 데이터에 대한 접근을 관리하는 데 도움이 돼.

상속 — 한 클래스(자식 클래스)가 다른 클래스(부모 클래스)의 속성과 메서드를 상속할 수 있게 해줘. 이는 코드의 재사용성을 높이고 유지보수를 쉽게 해줘.

다형성 — 서로 다른 클래스의 객체를 같은 인터페이스로 사용할 수 있게 해줘. 자식 클래스에서 부모 클래스의 메서드를 재정의하여 이를 달성할 수 있어.

추상화 — 객체의 공통적인 특성을 추출하여 이 특성을 표현하는 클래스를 만드는 것이야. 이는 복잡한 시스템을 단순화하고 이해하기 쉽게 만들어줘.

적어도 절반을 이해했다면, 잘 하고 있어. 이제 우리는 각 항목을 자세히 알아볼 거야.

2.2 추상화

현실 세계에서 추상화의 좋은 예는 회사나 조직에서 직무를 설명하는 것이야. 직위의 이름은 하나의 것이지만 그 직위에 따른 업무는 완전히 다른 것이지.

너가 네 미래 회사의 구조를 설계한다고 생각해봐. 비서의 업무를 여러 다른 직위로 나눌 수도 있어. CEO의 직위를 여러 독립적인 직위, 예를 들어, 재무 이사, 기술 이사, 마케팅 이사, 인사 이사 등으로 나눌 수도 있어. 아니면 사무 관리와 채용 직무를 하나로 합칠 수도 있어.

프로그래밍 관점에서 추상화는 프로그램을 올바르게 객체로 분할하는 것이야. 일반적으로 큰 프로그램은 다양한 방식으로 상호작용하는 객체로 표현할 수 있어. 추상화는 주요 특성을 선택하고 부차적인 것을 생략할 수 있게 해줘.

추상화는 군사 전략과 같아. 나쁜 전략은 아무리 탁월한 전술로도 상황을 바로잡을 수 없어.

2.3 캡슐화

캡슐화의 목표는 복잡한 것을 단순하게 만들어 품질을 향상시키는 것이야.

복잡한 것을 간단하게 만들기 위한 최고의 방법은 복잡한 것을 감추는 것이야. 예를 들어, 너가 보잉의 조종석에 앉아 있다면, 바로 어떻게 조종하는지 알 수 없을 거야:

반면에, 승객들에게 모든 것이 더 간단해 보이지: 티켓을 사고, 비행기에 타고, 이륙하고 착륙하지. 기본적인 "티켓을 사고"와 "비행기에 타는" 기술만으로 대륙 간 이동이 가능해. 비행기 준비, 이륙, 착륙 및 다양한 비상 상황의 복잡함은 우리에게서 숨겨져 있어. 이 모든 것이 우리의 삶을 더 편리하게 만들어줘.

프로그래밍 관점에서 캡슐화는 "구현의 숨김"이야. 나는 이런 정의가 좋아. 우리의 클래스는 수백 개의 메서드를 포함하고, 다양한 상황에서 매우 복잡한 행동을 구현할 수 있어. 그러나 우리는 이 클래스의 모든 메서드를 감추고 (이름 양쪽에 "__"로 둘러싸기), 다른 클래스와 상호작용하기 위해 몇 개의 메서드만 남길 수 있어. 그렇다면 우리 프로그램의 다른 모든 클래스는 이 클래스에서 단지 세 개의 메서드만 보게 될 것이고, 그들만 호출하게 될 거야. 복잡한 부분은 클래스 내부에 숨겨져 있어, 마치 행복한 승객에게서 조종석이 숨겨져 있는 것처럼.

2.4 상속

상속은 두 가지 측면이 있어: 프로그래밍 측면과 현실 세계 측면. 프로그래밍 관점에서 상속은 두 클래스 사이의 특별한 관계야. 하지만 더 재미있는 것은 현실 세계에서 상속이란 무엇인지야.

현실 세계에서 무언가를 만들어야 한다면 두 가지 해결책이 있어:

1. 필요한 것을 처음부터 만들어 시간과 노력을 많이 소비하거나;
2. 기존의 것을 기반으로 필요한 것을 만들어.

가장 최적의 전략은 기존의 좋은 해결책을 가져와서 조금 수정하고, 우리의 필요에 맞게 조정하여 사용하는 것이야.

인간의 기원을 추적해보면, 지구상에서 생명이 시작된 후 수십억 년이 지났어. 그런데 인간이 원숭이로부터 (원숭이를 기반으로) 등장했다고 가정하면, 불과 몇 백만 년 밖에 안 된 거지. 처음부터 만드는 게 더 오래 걸려. 훨씬 오래.

프로그래밍에서도 하나의 클래스를 다른 클래스를 기반으로 만들어낼 수 있어. 새로운 클래스는 기존의 클래스의 후손(상속자)이 되는 거야. 이는 우리에게 필요한 데이터와 메서드의 80%-90%를 포함한 클래스가 있을 때 매우 유용해. 우리는 적절한 클래스를 우리의 새로운 클래스의 부모로 선언하면, 새로운 클래스는 부모 클래스의 모든 데이터와 메서드를 자동으로 갖게 돼. 아주 편리하지 않아?

2.5 다형성

다형성은 프로그래밍 분야의 개념이야. 이는 한 인터페이스 뒤에 숨겨진 다양한 구현을 설명해. 현실 세계에서 그와 유사한 것을 찾으려 한다면, 차량을 운전하는 과정이 그 예 중 하나야.

만약 사람이 트럭을 운전할 수 있다면, 앰뷸런스나 스포츠카도 운전할 수 있어. 모든 차량은 운전 인터페이스가 동일하기 때문에 어떤 차량인지 상관없이 운전할 수 있어: 핸들, 페달, 기어 레버 등이야. 차량의 내부 구조는 다르지만, 모두 동일한 운전 인터페이스를 가지고 있어.

프로그래밍으로 돌아오면, 다형성은 다양한 클래스(일반적으로 공통 조상을 가진)의 객체에 일관되게 접근할 수 있게 해줘 — 이는 과소평가하기 어려운 가치가 있어. 프로그램이 클수록 그 가치는 더 커져.

OOP는 원칙이야. 내부 법칙이지. 각각이 우리를 어떤 면에서 제한하지만, 프로그램이 커질 때 큰 이점을 가져다줘. 네 가지 OOP 원칙은 의자의 네 발과 같아. 하나라도 제거하면, 전체 시스템이 불안정해질 거야.