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

2.1 OOP의 기본 개념

객체 지향 프로그래밍의 기본은 OOP 패러다임에 있어. 이건 모든 프로그램의 엔터티들이 객체로 간주된다는 것이야. 객체는 데이터 + 그 데이터에 뭔가를 수행하는 메소드/함수야.

또한 객체에는 상태와 행동이 있다고 말할 수도 있어. 객체의 상태는 그 내부 변수에 저장된 데이터로 보장돼. 객체의 행동은 메소드가 수행하는 모든 행동의 총합이야.

중간 규모 프로그램에는 수천 개의 객체가 있고, 대규모 프로그램에는 수백만 개가 있어. 그래서 혼란을 줄이기 위해 객체들을 클래스에, 그리고 그 클래스를 계층 구조에 조직하기로 했어.

재밌는 사실! 클래스 계층 구조의 개념은 동물계에서 비롯되었어. 인간은 영장류이고, 영장류는 포유류야, 그리고 쭉 이어져.

각 객체에는 그 객체를 만드는 클래스가 있어. 한편으로 클래스는 객체의 일종의 템플릿이고, 다른 한편으로는 자체적인 특성을 가진 독립적인 객체야. (아래에서 다룰 예정이야.)

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

클래스:

클래스는 객체 생성에 대한 템플릿이나 스키마로, 이 타입의 모든 객체에 대해 특성화된 속성과 메소드를 정의해. 클래스는 데이터를 조직하고 그 데이터와 작업하는 함수를 하나의 전체로 조직할 수 있도록 해.

객체:

객체는 클래스의 인스턴스야. 각 객체는 상태 (속성으로 정의됨)와 행동 (메소드로 정의됨)을 갖고 있어.

캡슐화:

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

상속:

상속은 한 클래스(자식 클래스)가 다른 클래스(부모 클래스)의 속성과 메소드를 상속받을 수 있도록 해. 이건 코드 재사용과 그 유지보수를 용이하게 해.

다형성:

다형성은 다른 클래스의 객체들과 작업하기 위해 단일 인터페이스를 사용하는 것을 가능하게 해. 이는 자식 클래스에서 부모 클래스로부터 메소드를 재정의함으로써 이루어져.

추상화:

추상화는 객체의 공통된 특징을 강조하고 그 공통 특징을 나타내는 클래스를 창조하는 것이야. 이는 복잡한 시스템을 단순화하고 그 이해를 높이는 데 도움이 돼.

이 중 절반이라도 이해했으면 좋겠어. 다음으로 각 항목을 더 자세히 살펴볼거야.

2.2 추상화

현실에서의 추상화의 좋은 예시는 회사나 조직 내의 직무 설명이야. 직무 명은 하나고, 각 특정 직무의 의무는 완전히 다른 것이지.

네가 미래 회사의 구조를 설계한다고 상상해봐. 비서의 의무를 여러 다른 직무에 나눌 수도 있고, 최고경영자의 직무를 여러 독립된 직위로 나눌 수도 있어: 재무 이사, 기술 이사, 마케팅 이사, 인사 이사 등으로. 아니면 예를 들어, 사무 관리직과 채용 담당자 직무를 하나로 통합할 수도 있어.

프로그래밍 관점에서 추상화는, 말하자면, 프로그램을 객체로 적절히 나누는 것이야. 일반적으로 어떤 큰 프로그램이든 서로 상호작용하는 객체로 수십 가지 방식으로 표현할 수 있어. 추상화는 주요 특징을 골라내고 부차적인 것을 생략할 수 있게 해줘.

추상화는 전술의 전략 같은 거야. 나쁜 전략은 아무리 뛰어난 전술로도 해결할 수 없어.

2.3 캡슐화

캡슐화의 목적은 요소 간의 상호작용을 단순화하여 상호작용의 질을 개선하는 거야.

무엇인가를 간소화하는 가장 좋은 방법은 그것의 복잡한 부분을 외부의 눈에서 숨기는 거야. 예를 들어, 네가 보잉 비행기 조종석에 앉는다면, 바로 그걸 조종하는 방법을 이해할 수 없을 거야:

반면에, 승객에게는 모든 것이 더 간단하게 보여: 티켓을 사고, 비행기에 타고, 이륙하고 착륙해. 네가 '티켓을 사기'와 '비행기에 타기'만 알면 쉽게 대륙 간을 여행할 수 있어. 비행기 비행 준비, 이륙, 착륙, 다양한 비상 상황은 우리에게 다 숨겨져 있어. 위성 네비게이션, 자동 조종 장치, 공항 관제센터 등은 말할 것도 없어. 그리고 이것은 우리 삶을 더 쉽게 만들어줘.

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

2.4 상속

상속에는 두 가지 측면이 있어. 프로그래밍 측면과 현실 생활 측면. 프로그래밍 측면에서 상속은 두 클래스 간의 특수한 관계야. 현실 생활 측면에서 상속이란 무엇인지가 더 흥미롭지.

만약 우리가 현실에서 뭔가를 창조해야 한다면, 두 가지 방법이 있어:

1. 필요한 것을 처음부터 만들어 많은 시간과 노력을 쓰기
2. 이미 존재하는 것을 기반으로 필요한 것을 만들기

가장 최적의 전략은 이렇게 보여: 이미 존재하는 좋은 해결책을 가져와 약간 수정하고, 우리의 필요에 맞게 조정하고 사용하는 것.

만약 우리가 인간의 기원을 추적한다면, 행성의 삶이 시작된 이후 수십억 년이 흘렀다는 것을 알 수 있어. 그리고 인간이 원숭이(원숭이를 기반으로)에서 나온 것이라고 상상한다면, 겨우 수백만 년이 흘렀을 뿐이야. 처음부터 창조하는 건 더 오래 걸려. 훨씬 더 오래.

프로그래밍에서도 다른 클래스를 기반으로 새로운 클래스를 만들 수 있는 기능이 있어. 새로운 클래스는 이미 존재하는 클래스의 후손(상속자)이 돼. 이건 특히 80%–90%의 필요한 데이터와 메소드를 포함하는 클래스가 있을 때 매우 유용해. 우리는 적절한 클래스를 새 클래스의 부모로 선언하고, 그러면 새 클래스에 부모 클래스의 모든 데이터와 메소드가 자동으로 나타나게 돼. 정말 편리하지?

2.5 다형성

다형성은 프로그래밍에서의 개념이야. 이는 하나의 인터페이스 뒤에 다양한 구현이 숨겨진 상황을 설명해. 현실 생활에서 이와 유사한 것으로는 자동차 운전 과정이 있을 수 있어.

만약 누군가가 트럭을 운전할 수 있다면, 그는 구급차 운전석에 앉거나 스포츠카 핸들에도 앉을 수 있어. 사람은 핸들, 페달, 변속 레버라는 동일한 인터페이스를 사용하기 때문에 차가 무슨 종류인지에 관계없이 운전할 수 있어. 내부 기계가 다르지만, 모든 자동차는 동일한 인터페이스를 가지고 있어.

다시 프로그래밍으로 돌아가면, 다형성은 다양한 클래스의 객체들(보통 공통 조상을 가진)과 일관되게 상호작용할 수 있게 해. 프로그램이 커질수록 그 가치는 더 커져.

OOP는 원칙들이야. 내부의 법칙들. 이 중 하나라도 제거하면 전체 시스템이 불안정해질 수 있어. OOP의 네 가지 원칙은 마치 의자의 네 다리와 같아. 하나라도 빼면, 전체 시스템이 불안정해질 수 있어.