객체 지향 프로그래밍의 장점

참고 :이 질문은 몇 달 전에 쓴 블로그 게시물 에서 편집 된 발췌 부분입니다 . Programmers.SE 에 대한 의견 에 블로그 링크를 배치 한 후 누군가가 질문에 대한 답변을 얻을 수 있도록 여기에 질문을 게시하도록 요청했습니다. 사람들이 Google에 '개체 지향 프로그래밍을 얻지 못했습니다'라고 입력하는 것처럼 보이므로이 게시물이 가장 인기 가 있습니다 . 여기 또는 Wordpress의 의견에 자유롭게 대답하십시오.

객체 지향 프로그래밍이란 무엇입니까? 아무도 나에게 만족스러운 답변을주지 않았다. 나는 코로 공중에서“물체”와“물체 지향”이라고 말하는 사람에게서 좋은 정의를 얻지 못할 것이라고 생각합니다. 객체 지향 프로그래밍 만 수행 한 사람으로부터 좋은 정의를 얻지 못할 것입니다. 절차 적 프로그래밍과 객체 지향 프로그래밍을 모두 이해하는 사람은 객체 지향 프로그램이 실제로 무엇을하는지 일관된 아이디어를 얻지 못했습니다.

누군가 객체 지향 프로그래밍의 장점에 대한 아이디어를 줄 수 있습니까?

소프트웨어는 컴퓨터 내부에 존재하는 기계 또는 조립 라인으로 생각하십시오. 일부 원자재와 구성품은 기계에 공급되며 일련의 절차에 따라 최종 제품으로 가공합니다. 절차는 특정 원료 또는 구성 요소에 대해 특정 순서로 특정 파라미터 세트 (예를 들어, 시간, 온도, 거리 등)에 대해 특정 작업을 수행하도록 설정된다. 수행 할 작업의 세부 사항이 잘못되었거나 기계의 센서가 올바르게 보정되지 않았거나 일부 원자재 또는 구성 요소가 예상 품질 표준에 포함되지 않은 경우 작업 결과가 변경되어 제품이 나오지 않을 수 있습니다 예상대로.

이러한 기계는 작동 및 허용되는 입력이 매우 견고합니다. 기계는 디자이너의 지능이나 현재 운영 환경에 의문을 제기하지 않습니다. 지시가있는 한 계속 절차를 따릅니다. 원자재 또는 구성품의 변경이 이후 작업에서 발생한 영향에 극적인 영향을 미칠 수 있더라도 기계는 여전히 절차를 수행합니다. 원하는 결과를 보상하고 생산하기 위해 절차에 어떤 변화가 필요한지 확인하려면 프로세스를 검토해야합니다. 제품의 디자인이나 구성을 변경하면 수행 된 작업이나 순서가 크게 변경 될 수도 있습니다. 생산 담당자는 가능한 한 격리 작업의 중요성을 빠르게 배웠지 만 그 사이에 바람직하지 않은 영향을 줄였습니다. 구성 요소가 처리 될 때의 상태에 대해 많은 가정이 이루어집니다. 다른 운영 환경에서 최종 제품이 사용자에게 제공 될 때까지 감지되지 않을 수있는 가정.

그것이 절차 적 프로그래밍과 같습니다.

객체 지향이 제공하는 것은 구성 요소의 상태에 대한 가정을 제거하는 방법입니다. 따라서 해당 구성 요소에 대해 수행 할 작업과 최종 제품에 통합하는 방법입니다. 즉, OOP는 특정 구성 요소를 처리하기 위해 프로세스 세부 정보를 가져 와서 더 작은 컴퓨터에 제공하는 것과 같습니다. 프로세스를 담당하는 더 큰 기계는 구성 요소 특정 기계에게 수행 될 것으로 예상되는 조작을 알려주지 만 단계에 대한 세부 사항은 처리 할 구성 요소 특정 기계에 남겨 둡니다.

객체 지향이 아닌 소프트웨어에 비해 객체 지향의 장점에 대해 :

• 구성 요소 별 동작 -특정 구성 요소를 처리하는 방법에 대한 세부 정보를 작성하면 더 작은 구성 요소 별 시스템의 책임으로 구성 요소를 처리 할 때마다 해당 시스템이 적절하게 처리됩니다.
• 다형성 표현 -컴포넌트 특정 머신이 특정 컴포넌트에 맞게 조작을 수행하므로 다른 머신으로 전송 된 동일한 메시지가 다르게 작동 할 수 있습니다.
• 유형 추상화 -여러 유형의 구성 요소가 기계가 수행하는 작업에 동일한 어휘를 사용하는 것이 종종 의미가 있습니다.
• 우려 사항 분리 -구성 요소 별 세부 사항을 기계에 남겨두면 프로세스 기계는 프로세스에 대한보다 일반적이고 더 큰 관심사 및 프로세스 관리에 필요한 데이터 만 처리하면됩니다. 또한 다른 구성 요소의 변경으로 인해 영향을받을 가능성이 적습니다.
• 적응성 -전문 분야에 중점을 둔 구성 요소는 사용하는 구성 요소를 변경하거나 다른 프로세스 기계에서 사용할 수있게하여 예기치 않은 사용에 맞게 조정할 수 있습니다.
• 코드 재사용 -초점이 좁고 적응성이 뛰어난 구성 요소는 더 자주 사용함으로써 개발 비용을 활용할 수 있습니다.

블로그에서 명령형 및 함수형 프로그래밍에 익숙하고 객체 지향 프로그래밍에 관련된 기본 개념에 익숙한 것 같지만 실제로 "클릭"한 적이 없었습니다. 유용하게 만듭니다. 나는 그 지식의 관점에서 설명하려고 노력할 것이고 그것이 당신에게 도움이되기를 바랍니다.

핵심적으로 OOP는 명령형 패러다임을 사용하여 문제 영역을 모델링하는 "스마트 한"데이터 구조를 만들어 고도의 복잡성을보다 효과적으로 관리하는 방법입니다. (표준 절차 비 객체 지향) 프로그램에는 변수와 변수와 관련이있는 코드라는 두 가지 기본 사항이 있습니다. 이 코드는 사용자 및 다양한 소스로부터 입력을 받아 변수에 저장하고 조작하며 사용자 또는 다양한 다른 위치로가는 출력 데이터를 생성합니다.

객체 지향 프로그래밍은 기본 패턴을 취하고 더 작은 규모로 반복하여 프로그램을 단순화하는 방법입니다. 프로그램이 코드로 수행 할 작업을 알고있는 코드가있는 대량의 데이터 모음 인 것처럼 각 개체는 코드로 수행 할 작업을 알고있는 코드에 바인딩 된 작은 데이터 조각입니다.

문제 영역을 작은 조각으로 나누고 가능한 많은 양의 데이터를 처리 할 수있는 코드에 직접 바인딩함으로써 프로세스 전체와 하위 프로세스에 대해 추론하기가 훨씬 쉬워집니다. 프로세스를 구성하는 문제.

데이터를 객체 클래스로 그룹화하면 해당 데이터와 관련된 코드를 중앙 집중화하여 관련 코드를보다 쉽게 ​​찾고 디버깅 할 수 있습니다. 또한 액세스 지정자 뒤에있는 데이터를 캡슐화하고 메소드 (또는 언어가 지원하는 경우 특성)를 통해서만 액세스하면 데이터 손상 또는 불변의 위반 가능성이 크게 줄어 듭니다.

상속과 다형성을 사용하여 기존 클래스를 재사용하고 원본을 수정하거나 처음부터 모든 것을 다시 작성할 필요없이 특정 요구에 맞게 사용자 정의 할 수 있습니다. ( 피할 수 없다면 절대하지 말아야 할 일 이다 .) 기본 객체를 이해하면 킬러 캥거루가 될 수있다 .

나에게 이것은 객체 지향 프로그래밍의 기본 원칙입니다. 복잡성 관리, 코드 중앙 집중화 및 객체 클래스 생성을 통한 문제 도메인 모델링, 상속 및 다형성, 캡슐화 및 속성. 이것이 많은 프로그래머가 왜 유용한 지 이해하는 데 도움이되기를 바랍니다.

편집 : 의견에서 Joel의 질문에 대한 답변으로,

명령형 프로그램과 근본적으로 다른 "개체 지향 프로그램"에 포함 된 내용 (설명한 멋진 정의 제외)을 설명 할 수 있습니까? "공 구르는 방법은?"

여기에 약간의 면책 조항이 있습니다. "객체 지향 프로그램"의 내 모델은 기본적으로 델파이 모델이며, 이전 델파이 팀 멤버가 만든 C # /. NET 모델과 매우 유사합니다. 내가 여기서 말하는 것은 다른 OO 언어에서는 적용되지 않거나 많이 적용되지 않을 수 있습니다.

객체 지향 프로그램은 모든 논리가 객체를 중심으로 구성되는 프로그램입니다. 물론 이것은 어딘가에 부트 스트랩되어야합니다. 일반적인 Delphi 프로그램에는이라는 단일 객체를 생성하는 초기화 코드가 포함되어 있습니다 Application. 프로그램을 시작할 때을 호출 Application.Initialize한 다음 Application.CreateForm처음부터 메모리에로드하려는 모든 양식을 호출 한 다음 Application.Run,화면에 기본 양식을 표시하고 핵심 구성 요소 인 입력 / 이벤트 루프를 시작합니다. 대화 형 컴퓨터 프로그램.

응용 프로그램과 폼은 OS에서 들어오는 이벤트를 폴링하여 개체의 메서드 호출로 변환합니다. 매우 일반적인 한 가지는 이벤트 처리기 또는 .NET에서 "대리인"을 사용하는 것입니다. 객체에는 "X와 Y를 수행하지만이 특정 이벤트 핸들러가 할당되어 있는지 확인하고있는 경우 호출하십시오"라는 메소드가 있습니다. 이벤트 핸들러는 객체의 동작을 확장하는 데 사용되는 메소드 포인터 (메소드에 대한 참조와 객체 인스턴스에 대한 참조를 포함하는 매우 간단한 클로저)입니다. 예를 들어 양식에 버튼 객체가있는 경우 버튼을 클릭 할 때 다른 객체가 메소드를 실행하게하는 OnClick 이벤트 핸들러를 연결하여 해당 동작을 사용자 정의합니다.

따라서 객체 지향 프로그램에서 대부분의 작업은 특정 책임을 가진 객체를 정의하고 메소드 포인터를 통해 또는 한 객체가 다른 객체의 공용 인터페이스에 정의 된 메소드를 직접 호출하여 연결함으로써 수행됩니다. (그리고 이제 우리는 캡슐화로 돌아 왔습니다.) 이것은 대학에서 OOP 수업을 받기 전에는 다시는 개념이 없었습니다.

나는 OOP가 기본적으로 내가 그랬던 것처럼 유혹을 받았을 수도있는 이름이라고 생각합니다.

내가 아기 프로그래머 였을 때 돌아 왔는데, 심지어 포트란에서도 서브 루틴에 대한 포인터와 같은 것이있었습니다. 서브 루틴에 대한 포인터를 다른 서브 루틴에 대한 인수로 전달할 수 있으면 정말 유용합니다.

다음으로 실제로 유용한 것은 데이터 구조의 레코드 안에 서브 루틴에 대한 포인터를 저장하는 것입니다. 이렇게하면 레코드가 자체적으로 작업을 수행하는 방법을 "알고"말할 수 있습니다.

그들이 Fortran에 내장했는지 확실하지 않지만 C와 그 하위 항목에서 쉽게 수행 할 수 있습니다.

따라서 그 아래에는 자신이하고 싶은 유혹을 받았을지도 모르는 간단하고 유용한 아이디어가 있으며, 일부 사람들이 무서운 유행어로 가득 찬 거대한 악대 차로 변신하더라도 최신 언어로 수행하기가 더 쉽습니다.

다양한 종류의 OO 시스템이 있으며 모든 사람이 동의 할만한 정의를 얻기가 어렵습니다. Java의 OO가 Common Lisp Object System과 어떻게 다른지 보여주기보다는 좀 더 일반적인 단계부터 시작하겠습니다.

분산 된 데이터로 존재하는 많은 객체가 있다고 가정합니다. 예를 들어 점은 X, Y 및 Z 배열의 요소 일 수 있습니다. 점 자체를 고려하기 위해 모든 데이터를 C와 같은 것으로 모으는 것이 struct좋습니다.

이제 모든 데이터 객체에 대해 데이터를 모두 모았습니다. 그러나 절차 적 프로그램에서는 코드가 흩어져 있습니다. 우리가 기하학적 모양을 다루고 있다고 가정하십시오. 도형을 그리는 큰 기능이 있으며 모든 도형에 대해 알아야합니다. 면적을 찾는 큰 기능과 주변을위한 다른 기능이 있습니다. 원의 코드는 여러 함수를 통해 흩어져 있으며 다른 유형의 모양을 추가하려면 변경할 함수를 알아야합니다. 객체 지향 시스템에서 함수를 class데이터 와 같은 종류 ( )로 수집합니다. 따라서 우리는 모든 원 코드를보고 싶다면 Circle정의에 있으며, 코드 를 추가하려면 Quartercircle단순히 클래스를 작성하면됩니다.

이것의 한 가지 이점은 클래스 불변량을 유지할 수 있다는 것입니다. 클래스의 각 구성원에 대해 사실입니다. 클래스 외부의 코드가 클래스 데이터 멤버를 직접 엉망으로 만들지 않도록 제한함으로써 클래스 데이터를 한 곳에서 변경할 수있는 모든 코드를 얻었으며, 한 쪽 다리가있는 삼각형이있는 것처럼 엉성한 일이 없음을 확인할 수 있습니다. 다른 두 개의 결합보다 길다). 즉, 클래스의 모든 멤버의 일부 속성을 사용할 수 있으며 사용할 때마다 개체가 제정신인지 확인할 필요가 없습니다.

주요 이점은 상속 및 다형성과 함께 제공됩니다. 이러한 다양한 모양을 모두라는 클래스의 하위 클래스로 정의하면 Shape코드를 조작 할 수 있으며 Shape모양 하위 객체는 조작에 의해 호출되는 모든 작업을 수행합니다. 즉, 새로운 모양을 추가하거나 이전 모양을 수정하면 이전에 테스트 한 코드를 건드릴 필요가 없습니다. 새로운 코드를 직접 활용할 수있는 오래된 코드가 자동으로 생성됩니다. 제어 코드가 가능한 모든 다른 모양을 인식하고 가능한 모든 다른 모양을 인식하는 함수를 유지 관리하는 대신, Shape서브 클래스 를 유지하면서 모양과 해당 속성을 처리 할뿐입니다 . 이것은 제어 코드를 단순화합니다.

여기에는 몇 가지 장점이 있습니다. 클래스 불변 값이 있으므로 내장 유형에 대해 추론하는 것과 같은 방식으로 더 큰 데이터 객체에 대해 추론 할 수 있습니다. 즉, 복잡한 개념을 더 간단한 개념으로 나눌 수 있습니다. 서클 코드는에 주로 포함되어 있으므로 Circle지역성이 향상되었습니다. 서로 다른 위치에 여러 가지 다른 기능을 통해 흩어져있는 원 개념이 없기 때문에 루틴 간 연결이 적어지고 동기화를 유지할 필요가 없습니다. 클래스는 사실상 유형이기 때문에 기존 유형 시스템을 사용하여 클래스의 호환되지 않는 사용을 잡을 수 있습니다.

OO에는 여러 가지 다른 정의가 있습니다. 나는 당신이 스스로 이것들을 많이 찾을 수 있다고 확신합니다. 나는 개인적 으로 그들을 이해하는 방법으로 Rees Re : OO 를 좋아 한다. 폴 그레이엄 (Paul Graham)을 인용 한 이후 이미 읽은 것 같습니다. (OO에 관심이있는 모든 사람에게 권장합니다.) {1,2,3,7,8,9}에서 Java 정의를 어느 정도 채택하려고합니다.

OO의 유용성, 특히 내가 접근하는 방법에 대한 질문은 수천 줄의 코드로 부분적으로 많은 답변을받을 가치가 있습니다 (부분적으로 단언이되지 않기 위해). 그러나 여기에 가상의 문서가 요약되어 있습니다.

OO가 수백 줄 정도의 소규모로별로 유용하지 않다고 생각합니다. 특히, 기능적 영향이없는 OO 언어는 모든 종류의 수집 또는 많은 데이터 유형이 필요한 모든 작업으로 간단한 작업을 수행하는 것이 매우 고통스러운 경향이 있습니다. 이것은 대부분의 디자인 패턴이 작용하는 곳입니다. 그들은 기초 언어의 낮은 힘에 반창고입니다 .

약 수천 라인에서 모든 작업 및 데이터 구조와 그 관계를 추적하기가 더 어려워집니다. 이 시점에서 데이터 구조와 작업을 명시 적으로 구성하고, 모듈 경계를 작성하고 책임을 정의하고, 정의를 프로그래밍하는 동안 이러한 정의를 이해하는 편리한 방법을 갖는 것이 도움이됩니다.

Java-ish OO는 인기 콘테스트에서 우승 한 이러한 문제에 대한 중간 해결책입니다. Java 사람들이 저조한 언어로 생성 된 소규모 문제에 적용하는 것과 동일한 메커니즘이기 때문에 체계적인 방법보다는 모든 것에 대한 마법의 솔루션처럼 보이기 시작합니다. 함수형 프로그래밍에 익숙한 사람들은 CL ++ 또는 Haskell의 유형 클래스와 같은 다른 솔루션을 선호하는 경향이 있거나 C ++에 갇혀있을 때 템플릿 메타 프로그래밍을 사용하거나 C #에서 매일 일하는 나와 같은 OO를 사용하지만 모든 것을 흥분 시키지는 않습니다. .

OOP는 객체와 객체 간의 상호 작용 측면에서 실제 컨셉을 모델링하려고 시도합니다. 인간으로서 우리는 세상을 사물 측면에서 처리하는 경향이 있습니다. 세계는 특정 속성을 가진 다른 객체로 가득 차 있으며 다른 객체와 상호 작용하는 것과 같은 일을 할 수 있습니다. OOP를 사용하면 세계를 유사한 용어로 모델링 할 수 있습니다. 예를 들어

• 사람은 객체입니다. 사람은 나이와 성별과 같은 특성을 가지고 있습니다. 사람은 일을 할 수 있습니다 : 먹고, 자고, 차를 운전하십시오.
• 자동차는 다른 유형이지만 객체입니다. 또한 제조업체, 모델 및 연도와 같은 속성이 있습니다. 자동차는 일을 할 수 있습니다 : 움직입니다.

그러나 자동차는 스스로 움직일 수 없으며 자동차를 운전할 사람이 필요합니다.

OOP = 데이터 구조 + 메시지 전달 + 상속, 모두 프로그래밍 모델에서 논리적 진화입니다.

OOP는 (프로그래머에 의해) 약 90 초 안에 이해 될 수 있습니다 (링크는 내 프로파일 참조). 개념은 매우 간단합니다.

그것을 적용하는 방법은 또 다른 문제입니다. 망치를 돌리는 방법을 알고 있다고해서 집을 설계하고 건축하는 방법을 아는 것은 아닙니다. ;-)

나는 당신이 도움이 될만한 블로그 게시물을 썼다 : 절차 적 대 OOP 설명 .

내가 처음 이해 한 방법은 다음과 같습니다.

객체 지향 프로그래밍 이전에는 구조적 프로그래밍 이있었습니다 . 모든 과정이 중심에 있습니다. 가장 먼저 물어보아야 할 질문은 "정보로 무엇을하고 싶은가? "입니다.

객체 지향 프로그래밍을 사용하면 데이터를 중심으로합니다. 첫 번째 질문은 " 내가 다루어야 할 마녀 정보? "입니다. 이것은 추상화를 더 쉽게 만듭니다.

구조체를 이해하고 함수 포인터를 이해하고 함수 포인터를 사용하여 구조체를 이해하므로 객체 지향 프로그래밍을 단순히 "함수 포인터가있는 구조체를 많이 사용하여 프로그래밍"으로 정의합니다. 여전히 전통적인 의미로 프로그래밍 중입니다. 모든 데이터와 데이터에 작용하는 코드입니다. 차이점은 단순히 모든 정보가 어떻게 정의되고 어떻게 정보를 정의하는지에 관한 것입니다.

아마도 단순화는 전통적인 프로그래밍은 "일부 데이터 구조를 가진 코드"이고 객체 지향 프로그래밍은 "일부 코드를 가진 데이터 구조"입니다. 둘 다 여전히 데이터 구조를 가지고 있으며 여전히 코드를 가지고 있습니다. 따라서 객체 지향 프로그래밍은 데이터 유형을 미리 정의하고 일련의 기능을 통해 통신하는 방식에 대한 계약을 시행하는 행위에 지나지 않습니다.

관찰 한 바와 같이, 솔루션을 구현하기에 좋은 방법이 아닌 방대한 종류의 응용 프로그램이 있습니다. 당신은 그러한 응용들로 주로 구성된 세상에 사는 것 같습니다. 블로그 게시물에서 "99 병의 맥주"문제 ( "좋아하는 프로그래밍 쇼케이스")의 구현을 살펴 보는 것을 언급합니다. 맥주 99 병은 확실히 그 범주에 속합니다. 99 병의 맥주 구현을 살펴봄으로써 객체 지향 프로그래밍을 이해하는 것은 나무 위의 집을 보면서 고층 건축을 이해하는 것과 조금 같습니다. 아주 잘 지어진 나무 위의 집조차 당신에게 많은 것을 가르쳐 줄 수 있습니다.

TL; DR : OO 프로그래밍은 기존 프로그래밍과 같습니다. 데이터 구조를 미리 정의하는 데 더 많은 노력을 기울이고 이러한 데이터 구조가 함수 포인터를 통해 서로 통신하도록한다는 점을 제외하면.

Wikipedia 페이지는 기본 사항을 얻을 수있는 좋은 장소라고 생각합니다.
http://en.wikipedia.org/wiki/Object-oriented_programming

기본적으로 아이디어는 OOP가 개선하려는 절차 적 프로그래밍이 모델링되는 프로세스에 초점을 맞춘다는 것입니다. OOP는 모델링중인 "사물"에 중점을 둔 모델로 전환하고 해당 사물의 프로세스 및 데이터가 해당 사물 내에 포함됩니다.

예를 들어, 작업 목록을 추적하는 응용 프로그램을 설계했다고 가정 해 보겠습니다. 절차 적 프로그래밍에서 모델의 최상위 엔터티는 작업 생성, 작업 제거, 작업 정보 변경 등과 같은 프로세스가됩니다. OOP 모델에서는 작업 생성에 집중하고 Task가 어떤 데이터와 프로세스를 담당해야하는지 생각하십시오. 그런 다음 작업에 대한 메모를 유지하려는 경우 메모 또는 다른 작업과 같이 작업과 상호 작용해야하는 다른 개체에 중점을 둡니다.

도움이 되길 바랍니다. 계속 읽고 코드를 살펴보면 갑자기 "클릭"됩니다. 그게 내 경험이었습니다.