C ++이 OOP에 적합하지 않습니까? [닫은]

C ++이 객체 지향 프로그래밍에 적합하지 않다는 질문에 대한 답변 중 하나를 읽었습니다 (어떤 것을 기억할 수는 없습니다). 그 기능이나 그와 비슷한 것을 사용할 수 있지만 순수한 OOP 의미는 아닙니다 (실제로 그 사람의 의미를 실제로 이해하지 못했습니다).

이것에 진실이 있습니까? 그렇다면 왜?

에서 설명한 바와 같이 그래서 * 앨런 케이 (Alan Kay)는 정말 용어가 무엇인지 * "를 객체 지향"을 의미 했습니까? Alan Kay는 메시지 전달이 OOP의 중요한 부분이라고 생각했지만 "클래스가있는 C"(나중에 C ++가 됨)에는 부족한 비트입니다. C ++은 약간의 동작을 가진 구조체이지만, Smalltalk 또는 Objective-C의 객체는 전송 된 메시지로 무엇을하는지 결정할 수 있다는 점에서 "지능적"입니다. Smalltalk-esque 객체가 구현하지 않은 메시지를 수신하면 지연 추가, 메시지를 다른 객체로 전달 또는 임의의 작업을 수행 할 수 있습니다.

C ++가 객체 지향 virtual방식으로 제공하는 것은 해당 메소드가 호출되는 방식과 관련된 메소드 및 다형성입니다. 컴파일러 class는 가상 메소드 가있는 데이터 유형 (또는 )을 볼 때 각 가상 메소드에 대한 슬롯이있는 vtable을 구성합니다. 가상 메소드를 구현하는 서브 클래스는 구현을 올바른 슬롯에 배치하므로 클라이언트 코드는 가상 테이블에서 특정 기능으로 코드를 완전히 해석하지 않고 코드를 실행할 위치를 알아야합니다. 이것이 의미하는 것은 효과적으로 ++이 C입니다 않습니다 그것은 모든 컴파일러에서 구현하고, 스몰 토크 - 억양 시스템으로 가능으로하지 않습니다 비록, 여러 파견의 형태를 갖는다.

메시지 전달을 OOP의 기본으로 생각한다면 C ++로 할 수 는 있지만 쉽지는 않습니다. OTOH OOP를 사용하여 데이터를 해당 데이터에 작용하는 함수와 연관시키는 것을 의미한다면 C ++은 괜찮습니다.

이런 종류의 토론은 주석, 성서의 의미 또는 미국 헌법의 의미에 대해 토론하는 사람들, 그리고 원저자 (들)가 의미하는 것처럼 마치 우리 가 중요하지 않다고 생각 하기 때문에 저를 괴롭 힙니다 .

앨런 케이는 똑똑한 사람이었고, 좋은 아이디어를 가지고 있었는데, 다른 좋은 아이디어들과 충돌하여 스몰 토크와 다른 언어로 실현되었다는 것을 알았습니다.

그는 메시아가 아니며 OOP는 하나의 진정한 프로그래밍 패러다임이 아닙니다.

많은 사람들에게 좋은 생각입니다. C ++에는 OOP 사고 방식에서 비롯된 좋은 아이디어가 있습니까? 물론 그렇습니다.

캡슐화, 상속 및 다형성을 의미하도록 OOP를 정의하면 C ++ 는 OOP를 지원합니다 .

그러나 C ++은 실제로 OOP에서 뛰어나지 는 않습니다 . 한 가지 이유는 다형성이 종종 스마트 포인터의 사용에도 불구하고 가비지 수집 언어로 작업하는 것이 더 자연스러운 힙 할당 객체에 의존하기 때문입니다.

그러나 C ++이 탁월한 곳은 일반 프로그래밍입니다. C ++를 사용하면 템플릿 기반 기능 프로그래밍 기술을 통해 고효율의 일반 코드를 쉽게 만들 수 있습니다.

C ++은 Simula에서 OOP 기능을 빌 렸습니다. Simula 개발자 IIRC 중 한 명 이상이 C ++이 생각했던 것이 아니라고 언급했습니다.

C ++에는 추상화를위한 훌륭한 도구가 있지만 객체 지향 언어보다 혼합 패러다임 언어입니다. 객체 지향 기능이 있지만 "엄격한 OOP"가 아닌 선택 사항이 있습니다.

C ++에서 얻을 수있는 나쁜 "opt-outs"중 하나는 메서드에 대한 늦은 바인딩보다는 초기에 사용하는 것입니다. 이것이 가능할뿐만 아니라 기본값입니다. Java에서 "final"은 관련되어 있지만 어떤면에서는 더 깔끔합니다 (사소한 성능 오버 헤드를 피하는 것이 아니라 의도를 지정 함) . 이것이 기본값 이 아닙니다 .

어떤면에서 C ++는 아직 여기에있는 초기 실험의 징후를 보여줍니다. 그럼에도 불구하고 다른 OOP 언어로는 얻을 수없는 많은 장점이 있지만 여전히 좋은 도구입니다.

모든 것을 클래스의 일부로 강요한다고해서 반드시 훌륭한 OO 코드가 생성되는 것은 아닙니다.

열악한 절차 적 프로그래머에게 Java로 프로그래밍하도록 요청하면 어딘가에 클래스를 가져 와서 정적 메인 메소드를 제공하고 1000 줄의 코드를 붙일 것입니다. 나는 그것을 보았다는 것을 안다.

Java에는 switch 문이 있습니다. switch( type ) { case typeA: bundles_of_code; break; case typeB: bundles_of_other_code; break }C ++과 Java 코드 모두 에서 등을 보았습니다 .

C ++은 많은 OO 개념을 지원하지만 표준은 그것에 의해 정의되지 않지만 많은 목표가 무엇인지에 달려 있습니다.

C ++의 주요 "가난한"의미는 객체를 다른 객체로 변환하는 클래스의 복사 구성을 허용하는 것입니다. 이것을 비활성화 할 수는 있지만 함수에서 반환 할 수는 없습니다. 다행히도 이것은 C ++ 0x에서 해결되었습니다.

OOP는 모든 것이 수업 중이거나 수업 중임을 확인하는 것이 아닙니다. 비 OO 코드를 "순전히 OO"언어로 작성하는 것은 완벽하게 가능합니다. 예를 들어, "main"은 전역 함수 인 것으로 종종 지적되지만 정적 main 메소드 만 포함하는 클래스를 발명하는 것은 비 OO와 같습니다.

C ++은 다양한 것들을 혼합하여 가장 잘 작동합니다. 이것이 가장 좋은 일이 가장 잘 작동하는 방식이므로 놀라운 일이 아닙니다. 종종 OOP는 매우 유용한 도구 중 하나입니다.

C ++은 OOP에 사용될 수 있지만 스몰 토크처럼 '순수한'것은 아닙니다. C ++에서는 사람들이 이야기하고있는 비 OOP를 수행 할 수도 있습니다.

비록 감정에 동의하지 않지만 C ++의 타입 시스템이 순수한 OOP가 아니라 "모든 것이 객체"가 아니라는 것은 사실입니다. 스몰 토크 에서처럼 숫자 (특히)를 쉽게 확장 할 수는 없습니다. 예를 들어 "2 + 2"의 의미를 재정의 할 수는 없습니다 ( "2 + 2"의 의미를 재정의 할 수는 있지만).

그러나 대부분의 사람들이 무엇을 아마 평균 많은 사람들이 C에서 비 객체 지향 코드를 작성 ++하지만이 "OOP"언어를 사용하고 있기 때문에 믿고 있다는 것입니다, 그들이있는 거 객체 지향. 그건 사실이 아니야. 그러나 내 의견으로는, Smalltalk에서 끔찍한 명령 코드를 작성할 수 있으며 C ++의 괜찮은 OOP 디자인보다 우수하지는 않습니다.

C ++에 대한 Alan Kay의 완벽한 반대 의견은 C의 매크로 언어였습니다.

"메시지 전달"이라는 개념은 단순히 클래스의 인스턴스가 메모리에 유지되고 호출 될 수있는 메소드를 노출한다는 개념입니다. 메시지 전달은 함수에 대한 포인터를 보유하는 vtables를 사용하여 C ++에서 * 시뮬레이션됩니다.

메시지 전달이 C ++에 존재하지 않는다고 말하는 것은 정확하지 않습니다. 더 정확하게 말하면 메시지 전달은 외국어 구문을 사전 처리하지 않고 C에 직접 이식하지 않기 때문에 smalltalk 및 Java와 같은 다른 언어의 필수 요소입니다.

이것은 질문의 경험 수준을 약간 넘어서는 것으로 생각되는 매우 의미 론적 언어 설계 논쟁입니다.

C ++를 싫어하는 수천 가지 이유와 C ++을 좋아할 이유는 거의 없습니다.

완벽한 망치와 완벽한 못을 찾는 대신, 완벽한 집을 찾고 경험이 필요한 올바른 도구를 찾으십시오.

Alan Kay가 두려워하는 것은 시스템 프로그래밍에서 "순수한 OOP"가 아니라는 것이 실제로 C ++의 강점이라는 것을 기억하는 것이 중요합니다. 각자 자신에게 ...

내 생각에 그것은 유용성 문제와 같은 정의 문제가 아닙니다.

객체는 복잡한 프로그램에 대한 읽기, 쓰기 및 추론을보다 쉽게하기위한 추상화입니다. 실용적인 프로그래머에게는 언어가 "객체 지향"에 대한 특정 공식 정의의 모든 기준을 충족시키는 지 여부 (여러 경쟁 언어가있는 것 같습니다!)가 제공하는 도구가 즉, OOP의 생산성 이점을 실제로 활용할 수 있습니다.

C ++에서 객체는 굉장히 누출되는 추상화로, 프로그래머가 객체에서 메모리가 어떻게 구성되어 있는지와 관련된 불쾌한 문제, 즉 다른 OOP 언어보다 C 언어로 코딩하는 것을 연상시키는 문제에 빠지게하는 경우가 많습니다. 예를 들어 C ++ FAQ (질문과 대답) 는 다음과 같은 비판을 제공합니다.

실무자는 C ++ 이외의 OO 시스템과 C ++을 "OO"로 간주 할 수있는 특별한 방식으로 해석되는 "캡슐화, 상속, 다형성"삼위 일체 이외의 OO 정의에 익숙해지는 것이 매우 유리합니다. 예를 들어, 경계 검사 또는 가비지 수집이없는 환경이 OO 환경이 아니라는 주장은 C ++에 익숙한 사람들에게는 터무니없는 소리입니다. 그러나 많은 관점에서 보면 이치에 맞습니다. 누구든지 객체를 덮어 쓸 수 있다면 "캡슐화"는 어디에 있습니까? 객체를 배치하면 댕글 링 참조 또는 메모리 누수가 발생할 수있는 경우 시스템은 어떻게 "객체 지향"입니까? ? 주어진 장소와 시간에 어떤 종류의 물체가 있는지 말할 수있는 능력은 어떻습니까? 소프트웨어가 객체와 함께 작동한다고 말하면 어디에 있습니까? 그리고 찾을 수 없다면 소프트웨어를 어떻게 디버깅해야합니까?

C ++는 객체 지향적이지만 불쾌하고 불완전합니다. 사용자는 데이터가 실제로 잘못된 비트가 아닌 "실제"객체처럼 동작 하도록 많은 노력을 기울여야합니다 . 즉, 수명이 다할 때까지 많은 코드가 C ++로 작성되었으며, 대부분은 클래스와 동적 디스패치 를 사용하므로 실제 OOP에 사용할 수 있는 것은 자명 한 것 입니다.

그레이엄 리가 가장 찬성 한 이유가 여기 있습니다. 다시 말하면, C ++ 클래스는 실제로 메시지 전달을 수행하지 않는다는 의미에서 객체가 아닙니다. 이것이 사람들이 C ++ 또는 oop을 배울 때 많은 것을 여행한다고 생각합니다. 사람들은 객체 지향이 'this'라고 말한 다음 C ++이 다르게 작동한다고 들었습니다. C ++은 OOP를 다르게하지 않았다. 이런 식으로 생각하면 C ++ 클래스가 의도 한 바에 대해 결코 감사하지 않을 것입니다. 즉, 추상화와 역동적 인 행동을 통합하여 절차 적 패러다임을 개선하는 것입니다. 따라서 C ++ 클래스는 기본적으로 절차 적이며 절차 적 패러다임을 개선하거나 오히려 C 구조의 고급 버전입니다.

Steve Yegge 가 가장 잘 말했습니다 .

C ++는 지구상에서 가장 멍청한 언어로, 가장 덜 지각 적이라는 의미입니다. 자체에 대해서는 모른다.

C ++의 객체 시스템은 컴파일 타임에 매우 결선 되어 고정되어있어 메시지 전달, 내부 검사, 반영, 동적 디스패치 및 지연 바인딩과 같은 OOP의 원래 개념과는 거리가 멀다. C ++과 스몰 토크가 공통적으로 가지고있는 것은 약간의 어휘입니다.