객체 지향 프로그래밍

1. OOP의 원리 소개

오늘 당신은 새롭고 흥미로운 세계를 발견하게 될 것입니다. 객체 지향 프로그래밍 ( OOP ) 의 세계 . 이전에 클래스와 개체에 대해 배웠습니다. 오늘 당신은 그들에 대해 더 많이 배울 것입니다.

OOP는 프로그램의 복잡성이 증가함에 따라 등장했습니다. 프로그램의 변수와 메서드가 수만 개에 달하기 시작하면서 무언가를 수행해야 한다는 것이 분명해졌습니다. 한 가지 해결책은 데이터와 관련 메서드를 별도의 객체로 결합하는 것이었습니다.

이제 프로그래머는 개체가 외부에서 상호 작용하는 방식과 내부에서 동작하는 방식을 별도로 설명해야 했습니다. 덕분에 프로그램을 이해하고 작성하기가 훨씬 쉬워졌습니다. 그러나 한 가지 질문이 남아 있습니다. 어떤 메서드가 객체 내부에 있어야 하고 어떤 메서드가 다른 객체에서 사용할 수 있어야 합니까?

많은 접근이 시도되었습니다. 그리고 발견된 모범 사례를 바탕으로 OOP 의 4가지 원칙이 등장했습니다. 그것들은 추상화, 캡슐화, 상속 및 다형성 입니다 . 이전에는 세 가지만 있었지만 전문가들은 나중에 추상화도 추가하기로 결정했습니다.

2. 추상화

인터넷상의 사람들은 여전히 ​​OOP 에서 추상화의 정의에 대해 논쟁하고 있습니다 . 문제는 모두가 틀렸다는 것이 아니다. 모두가 옳다는 것입니다 . 프로그램이 작을수록 더 많은 추상화가 Java 언어에 연결됩니다. 프로그램이 클수록 더 많은 추상화가 실제 객체를 모델링/단순화하는 데 연결됩니다.

그러나 최고의 지성인들은 다음 사항에 동의하는 것 같습니다.

추상화는 프로그램에서 개체를 충분히 정확하게 나타내는 개체의 특성만 사용하는 것입니다. 기본 아이디어 는 작업을 동시에 충분한 정확도로 해결할 수 있는 가장 작은 필드 및 메서드 집합으로 개체를 나타내는 것입니다 .

Java에서 추상화는 추상 클래스와 인터페이스를 통해 수행됩니다.

실생활에서의 추상화

실생활에서 추상화의 좋은 예는 회사나 조직의 직무 설명입니다. 직위의 직함은 하나이지만 직위에 할당된 특정 책임은 완전히 다른 문제입니다.

미래 회사의 조직 구조를 설계하고 있다고 상상해 보십시오. 비서 책임을 나누어 여러 직책에 분산시킬 수 있습니다. CEO 직위를 CFO, CTO, CMO, HR 이사 등 여러 직책으로 나눌 수 있습니다. 또는 예를 들어 사무실 관리자와 채용 담당자의 직위를 하나로 결합할 수 있습니다.

당신은 직위를 생각한 다음 이러한 직책에 대한 책임을 나눕니다. 추상화는 개체 전체에서 벗어나 필요한 필수 속성과 구성 요소를 선택하는 것입니다.

프로그래밍 관점에서 추상화는 프로그램을 객체로 올바르게 나누는 것 입니다 . 일반적으로 대규모 프로그램을 상호 작용 개체로 나타내는 방법은 수십 가지가 있습니다. 추상화를 사용하면 필수 특성을 선택하고 중요하지 않은 특성을 무시할 수 있습니다.

3. 캡슐화

캡슐화 의 목표는 개체를 더 단순하게 만들어 상호 작용을 개선하는 것입니다.

그리고 무언가를 단순화하는 가장 좋은 방법은 복잡한 것을 엿보는 눈에서 숨기는 것입니다. 예를 들어, Boeing 점보 제트기의 조종석에 앉으면 작동 방법을 즉시 이해하지 못할 것입니다.

그러나 비행기 승객에게는 모든 것이 더 간단합니다. 티켓을 구입하고 비행기에 타면 이륙하고 착륙합니다. "티켓 구매"와 "비행기 탑승" 기능만 있으면 한 대륙에서 다른 대륙으로 쉽게 이동할 수 있습니다. 비행, 이륙, 착륙 및 다양한 비상 상황을 위해 항공기를 준비하는 모든 복잡성이 숨겨져 있습니다. 위성 내비게이션, 자동 조종 장치 및 항공 교통 관제 센터는 말할 것도 없습니다. 그리고 이것은 우리의 삶을 단순화합니다.

프로그래밍 관점에서 캡슐화는 "구현을 숨기는 것"입니다. 나는 이 정의를 좋아한다. 우리 클래스는 수백 개의 메서드를 포함할 수 있으며 다양한 상황에서 매우 복잡한 동작을 구현할 수 있습니다. 그러나 우리는 (private 한정자로 표시하여) 엿보는 눈으로부터 모든 메서드를 숨길 수 있고 다른 클래스와 상호 작용하는 메서드를 2~3개만 남길 수 있습니다(public 한정자로 표시). 그런 다음 우리 프로그램의 다른 모든 클래스는 세 가지 공개 메서드만 보고 호출 하지만 다른 클래스는 호출하지 않습니다. 그리고 조종석이 행복한 승객에게 숨겨져 있는 것처럼 모든 복잡성이 클래스 내부에 숨겨질 것입니다.

4. 상속

상속 에는 양면이 있습니다 . 프로그래밍에서의 상속과 실생활에서의 상속. 프로그래밍에서 상속은 두 클래스 간의 특별한 관계 입니다 . 그러나 실생활에서의 상속은 훨씬 더 흥미롭습니다.

실생활에서 무언가를 만들어야 하는 경우 두 가지 옵션이 있습니다.

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

최적의 전략은 기존의 좋은 솔루션을 가져와 약간 수정하고 필요에 맞게 조정한 다음 사용하는 것입니다.

인류의 역사를 시작까지 거슬러 올라가면 지구에 생명이 시작된 지 수십억 년이 지났음을 알게 됩니다. 그러나 우리가 인간의 출발점을 우리의 영장류 조상으로 간주한다면(즉, 인간은 영장류 조상에 "기반"을 두고 있음) 불과 2백만 년이 지난 것입니다. 처음부터 빌드하는 데 시간이 더 걸립니다. 더 길게.

프로그래밍에서 다른 클래스를 기반으로 하나의 클래스를 생성하여 유사한 작업을 수행할 수 있습니다. 새 클래스는 기존 클래스의 후손(상속)입니다. 이는 기존 클래스에 필요한 데이터 및 메서드의 80-90%가 있을 때 매우 유용합니다. 적절한 클래스를 새 클래스의 부모로 선언하기만 하면 부모 클래스의 모든 데이터와 메서드가 자동으로 새 클래스에 나타납니다. 편리하죠?

5. 다형성

다형성은 프로그래밍 개념입니다. 단일 인터페이스 뒤에 다른 구현이 숨겨져 있는 상황을 설명합니다. 상대방의 실생활을 살펴보면 차량을 운영하는 것이 적합하다는 것을 알 수 있습니다.

누군가가 트럭을 운전할 수 있다면 구급차나 스포츠카의 운전대를 잡을 수도 있습니다. 모든 자동차는 스티어링 휠, 페달 및 기어 변속과 같은 동일한 제어 인터페이스를 가지고 있기 때문에 자동차의 종류에 관계없이 사람이 자동차를 운전할 수 있습니다. 자동차의 내부는 다르지만 모두 동일한 제어 인터페이스를 가지고 있습니다.

프로그래밍의 세계로 돌아가서, 다형성은 서로 다른 클래스(일반적으로 공통 조상을 가짐)의 객체에 동일한 방식으로 액세스할 수 있도록 하며, 그 가치는 거의 과장될 수 없습니다. 프로그램이 커질수록 그 가치는 커집니다.

OOP는 원칙을 의미합니다. 내부법. 그들 각각은 어떤 식으로든 우리를 제한 하지만 프로그램이 커지면 그 대가로 큰 이점을 제공합니다. OOP 의 네 가지 원칙은 테이블의 네 다리와 같습니다. 하나를 빼면 전체 시스템이 불안정해집니다.