OOP가 실제 세계에서 지배적 인 프로그래밍 모델입니까?

결코 개체? 글쎄, 거의

ACM 커뮤니케이션의 VIEWPOINT 섹션에서 " Objects Never? Well, Hardly Ever Ever " 라는 흥미로운 기사를 발견했습니다 . 그것은 객체 우선 또는 객체와는 근본적으로 다른 관점입니다. 그는 "물체를 절대로"또는 "물체 대학원"을 제안합니다.

저자는 OOP에 대해 이야기하고 실제 프로그래밍 환경에서 OOP가 어떻게 사용되는지에 대해 질문했습니다. 그는 OOP가 지배적 인 프로그래밍 모델이 아니라고 생각합니다. 예를 들어, OOP가 실제로 적합하지 않은 임베디드 시스템에 대해 프로그래밍의 70 %가 수행된다고 주장했다.

대학의 일부 교수들은 OOP의 이점에 대해 이야기하고 싶을 때 코드 재사용에 대해 이야기합니다. 또 다른 예로, 그는 이것이 실제 세계에서는 그렇지 않다고 주장한다. 코드 재사용은 대학에서 주장하는 것보다 어렵습니다.

본인은 OOP의 사용이 대부분의 사람들이 생각하는 것만 큼 널리 퍼지지 않았으며, 지지자들이 주장하는 것만 큼 성공적이지 않기 때문에 CS 교과 과정의 중심이 정당화되지 않았다고 주장합니다.

스택 오버플로 사람들이 이것에 대해 어떻게 생각하는지 알고 싶습니다. 프로그래머의 관점에서 OOP가 지배적 인 프로그래밍 모델입니까?

하나의 접근 방식 만 선택 / 학습 / 사용해야한다면 OOP입니까? 왜?

ACM 커뮤니케이션의 VIEWPOINT 섹션에서

실제 프로그래밍에 관심이 있다면 ACM 및 유사 프로그램 의 진행이 마지막으로 읽으려는 소스입니다. 이들은 실세계에서 응용이없는 [의사] 과학 간행물입니다. 이것은 종종 작가가 대중과 자신을 구별하고 자신의 인격을 홍보하기 위해 널리 알려진 정통 의견입니다.

본인은 OOP의 사용이 대부분의 사람들이 생각하는 것만 큼 널리 퍼지지 않았으며, 지지자들이 주장하는 것만 큼 성공적이지 않기 때문에 CS 교과 과정의 중심이 정당화되지 않았다고 주장합니다.

나는 당신의 주장에 동의하지 않는 경향이 있습니다. OOP는 널리 퍼져 있으며 제대로 작동합니다. OOP 기반 프로젝트의 수는 다른 전략으로 수행 한 개발을 능가했을 가능성이 높습니다 (15-20 년 동안 현대에 대해 이야기합시다).

그러나 OOP는 은색 총알이 아닙니다. 일부 개발에서는 작동하지만 다른 개발에서는 작동하지 않습니다. 다른 접근법과 마찬가지로.

그러나 한 가지 언급해야 할 것은 커리큘럼은 다양한 접근 방식에 대한 지식을 전달해야한다는 것입니다. OOP 기반이라면 잘못된 것입니다. FP 기반 인 경우 잘못된 것입니다. 그것들을 모두 다루 거나이 주제를 완전히 만지지 마십시오.

추신 : 왜 지배적 인 것과 그렇지 않은 것을 걱정합니까? 프로젝트에 적합한 것을 취하여 숫자를 "연구자"에게 맡기십시오.

OOP가 당신이 아는 유일한 패러다임이라면, 더 많은 것을 배울 것입니다. 그러나 실제로 OOP 란 무엇을 의미합니까? Java 또는 C ++을 의미합니까? 스몰 토크를 의미합니까? 설정 가능한 가치 슬롯과 폐쇄를 의미합니까? (안녕, 계획!) 그것은 메시지를 보내는 것을 의미 하는가? (안녕하세요!)

요컨대, 물어 보는 것은 흥미없는 질문 인 것 같습니다. "OO가 유용 합니까?" 더 좋은 질문입니다. 그리고, 그렇게 보입니다. (확실히 그것은 나를위한 것입니다.)

"70 %의 프로그래밍"을 수행하는 모든 개발자는 어디에 있습니까? 내가 알고있는 모든 개발자 중 1 % 미만이 임베디드 시스템에서 작업하고 있습니다.

따라서 3 가지 옵션이 있습니다.

1. 나는 독특하고 모든 친구들이 실제로 임베디드 프로그래밍을한다
2. 지하실에 갇힌 개발자의 군대가 70 % 나됩니다
3. 이 통계는 만들어지고 기사는 헛소리입니다

옵션 1 또는 2가 실제로 사실이라는 증거가 없다면 옵션 3을 사용하겠습니다.

(BTW, 나는 현대적인 모바일 개발 임베디드 프로그래밍을 고려하지 않으며, 모든 Apple이 iPhone을 위해 * Objective * C를 사용하도록 강요 한 후 모바일 개발은 종종 OO입니다)

나는 그것을 따를 사실이 없지만 OOP는 지배적 인 프로그래밍 모델이 아닙니다. Visual Basic 과정을 수강하거나 Excel에서 매크로 프로그래밍을 한 사람이 개발 한 모든 사내 앱을 상상해보십시오.

많은 응용 프로그램이 모든 논리가 단일 클래스 또는 뷰로 쌓이는 명령형 프로그래밍을 수행하고 있습니다. 이것은 아마도 전사적으로 실행되는 대부분의 내부 단순 응용 프로그램 일 것입니다.

동일한 문제를 해결하는 방법에는 여러 가지가 있습니다. 일부는 다른 것보다 더 적합합니다.

또한 지적했듯이 OOP가 모든 시나리오에 유용하지는 않습니다. 다른 모델도 있습니다.

OOP가 지배적 인 프로그래밍 모델인지 여부는 관계가 없습니다. 단순히 다른 모델을 다른 경우에 맞추십시오.

은 총알이 없습니다.

모티 벤 아리 (Moti Ben Ari)가 논박하고있는 것은 이미 무의미한 학문적 주장이다. 그러나 그는 자신이 OOP를 "이해하기"위해 결코 찾지 못했으며 수천 명의 개발자와 소프트웨어 엔지니어들에게 분명히 해냈으며 많은 시스템에서 사용되어 왔다고 스스로 주장합니다 ...

그러나 실제로 내 대답의 요점은 이것입니다. 하나의 모델 또는 다른 모델이 지배적이거나 그렇지 않다는 것을 언급하는 것이 얼마나 좋은지, 맹목적으로 그것을 사용하는 좋은 근거는 무엇입니까? 물론 그렇지 않습니다.

이것은 실제로 신뢰할만한 대답을하기 어려운 질문입니다. 가장 큰 이유는 나와 같은 사람들이 사내 응용 프로그램에서 작업하며 코드가 건물을 떠나지 않는 것입니다. 우리는 여기서 OO를 사용합니까? 나는 말하고 있지 않다. 비슷한 직업을 가진 다른 프로그래머는 몇 명입니까? 그들은 또한 말하고 있지 않습니다. 채용 정보 사이트가 있지만 모든 채용 정보가 게시되는 것은 아니며 이름 목록을 수집하려는 채용 담당자와는 달리 모든 채용 정보가 실제 일자리를위한 것은 아닙니다.

내가 일하는 곳에서 OO를 사용한다고 말 했는데도 링크 된 기사 (Objects, Classes, Inheritance)의 전통적인 정의를 의미합니까? 아니면 코드를 구성하는 수단으로 객체를 주로 사용한다는 의미입니까? 아니면 인터페이스에 프로그래밍하고 상속을 거의 사용하지 않는다는 것을 의미합니까? 나는 아직도 말하고 있지 않지만, 이것들 중 어느 것이 실제로 OO로 간주됩니까?

OO가 유용한 지 여부를 묻는 것도 의미가 없습니다.

물론 경영진이 가장 최근에 유행 한 유행어이기 때문입니다. 또한 명령형 프로그래밍보다 더 나은 캡슐화 및 추상화를 제공하므로 oop에서 다음에 오는 것으로의 도약이 oop take에 대한 명령보다 훨씬 오래 걸릴 수 있다고 생각합니다.

PS2 : 하나의 접근 방식 만 선택 / 학습 / 사용해야한다면 OOP입니까? 왜?

하나만 배우려면 다른 분야를 선택해야합니다.

유형과 캡슐화 및 OOP의 다른 모든 이점에 대해 배우고 기능적 스타일의 프로그래밍을 사용하여 동일한 일을 수행하는 방법을 배워야합니다.

OOP는 확실히 실제 세계에서 가장 지배적 인 프로그래밍 모델 중 하나입니다.

디지털 하드웨어를 디자인하는 사람들, 칩 디자이너들조차도 SystemVerilog와 SystemC의 듀오로 전환하고 있습니다. 이들은 객체 지향 프로그래밍 언어입니다.

OOP는 어디에 사용되지 않습니까? 장치 드라이버를 코딩하는 경우 일반 프로그래밍이나 다중 상속이 필요한 이유를 상상하기 어렵거나 AI 기능 프로그래밍 기술을 사용하는 경우 헤드에서 훨씬 쉽게 만들 수 있습니다. OOP가 oligopolistic programming 세계에 있기에 꽤 강력한 장소라고 말하면 충분합니다.

나는 아니오라고 말할 것입니다.

나는 '개체 지향적'언어를 사용하여 작성된 엄청난 양의 코드가 있다는 것을 이해하지만 일반적으로 코드는 절차 적으로 클래스로 싸여 있음을 알았습니다. (이것이 반드시 나쁜 것은 아닙니다). 내가 본 언어에서 이러한 언어로 OO로 작성된 코드는 일반적으로 유지 관리 할 수없는 클래스 간의 종속성을 끔찍하게 혼란스럽게하는 경향이 있습니다.

OO는 완전히 독립적 인 객체 사이의 메시지 전달에 관한 것으로, 오늘날의 코드에서는 훨씬 더 세분화 된 수준에서 dll 또는 어셈블리 또는 COM 객체로 구현 된 객체를 볼 수 있습니다. '구성 요소'라고 들었습니다.

따라서 OO를 사용하는지 여부는 실제로 중요하지 않다고 생각합니다. 코드가 수명 동안 유지 관리 가능하고 설계된 범위까지 재사용 가능하고 신속하게 개발할 수 있다면 신경 쓰지 않습니다. 순전히 절차 적이거나 반 객체 지향적이거나 완전히 OO 인 경우. 나는 누구든지 우세한 스타일이 이것들 중 하나인지 말할 수는 없지만, 절차 적 스타일이 함수 대신 클래스로 잘 리더라도 가장 일반적 일 것이라고 추측 할 위험이 있습니다.

Object Oriented Approach를 적용하여 얻은 솔루션과 Object Oriented Paradigm을 사용하여 구현 된 솔루션을 차별화하는 것이 중요하다고 생각합니다. 좋은 객체 지향 소프트웨어에 대한 나의 의견은 두 솔루션을 결합하는 것입니다. 객체를 생각하고 객체 정의와 상호 작용을 존중하고이 구조를 사용하도록 문제를 조정할 수 있다면 유연하고 강력한 코드를 갖게됩니다. 그러나 절차 적 패러다임을 사용하여 코드를 해결하기 위해 객체를 사용하는 경우 객체 전문가로부터 이점을 얻지 못하는 불쾌한 믹스가 생깁니다.

나는 코드가 객체 지향 인 것을 정말로 선호하며, 처음에는 좋은 구조를 만드는 것이 조금 더 성 가실 수 있다는 것을 깨닫게되었지만 오늘날의 유연성과 클라이언트 플래시 요구 사항을 처리 할 때 가치가 있다고 생각합니다. 노력.

나는 정확한 수를 아는 척하거나 심지어 추측하기는 쉽지 않지만 OOP를 포함하지 않는 많은 프로그래밍 프로젝트가 있습니다. 산업용 로봇과 함께 일합니다. 프로그램은 매우 간단하고 간단한 절차 코드입니다. 실제 로봇 운영 체제는 훨씬 더 그렇습니다.

우리가 사용하는 많은 "도구"는 OOP 기반이지만 로봇 컨트롤러가 아닌 PC에서 실행됩니다. 여기에는 편집기, 시뮬레이션 및 유틸리티가 포함됩니다.