객체 지향 프로그래밍이 주요 프로그래밍 패러다임이 된 역사적 조건은 무엇입니까?

객체 지향 프로그래밍 언어가 영향력을 가지게하는 경제적 요인 (및 기타 역사적 요인)은 무엇입니까? 나는 Simula가 사업을 시작했지만 비즈니스 요구가 계속 증가함에 따라 OOP 언어를 채택 했음을 알고 있습니까? 아니면 OOP 언어로 할 수있는 새로운 일 때문에 채택이 더 되었습니까?

편집 언어에 영향을 미칠 수있는 몇 가지 요인이 언어에 영향을 미치는지 여부에 정말 관심이 있습니다.

짧은 답변

나는 그것이 OO 일 전에 소프트웨어 프로젝트의 이탈이라고 생각합니다. OO는 근본적으로 중요한 개념 인 실제 세계를 모델링 함으로써 도움을 주었다 .

최초의 객체 지향 프로그래밍 언어는 1967 년 에 Simula 방식 이었습니다. 그러나 당시 소프트웨어 개발은 ​​여전히 ​​실험실에서 이루어졌으며 대부분의 패러다임은 여전히 하드웨어 사례에 더 가깝습니다 .

엔터프라이즈 응용 프로그램을위한 소프트웨어의 전체 개발 10 년 동안 다른 상업용 응용 프로그램이 커졌고 1970 년대 전체에 걸쳐 소프트웨어 개발이 크게 진행되었습니다. 그 시대 (1980 년 이전)의 오늘날에도 여전히 살아남은 언어는 C, Cobol, Fortran 등입니다. 이러한 언어의 대부분은 절차 적입니다. Lisp도 그날부터 존재했지만 상업적 개발을위한 탁월한 범용 언어인지 확실하지 않습니다. 유명한 폭포 모델 이라는 용어는 1970 년대 초에 만들어졌습니다.

대부분의 상업 환경에서 소프트웨어 개발에서 가장 중요한 요소는 프로젝트 관리였습니다. 프로젝트가 결승선에 합당하게 도달 할 수 있도록 예산을 고정하고 최소한 예측 가능한 예산과 관리 요구 사항이 필요했습니다. 이시기에는 1975 년에 신화적인 한 달이 되었습니다.

절차 적 언어가 그러한 약속을 지키지 않았기 때문에 70 년대 말까지 사람들이 타 버린 것 같습니다. 그리고 그 이후로 존재했던 새로운 패러다임 객체 지향 이 그것을 크게 만들었습니다. 사람들이 동의하지 않을 수도 있지만, 1983 년에 친숙하고 입증 된 경험과 C에 도움이되는 C ++과 1983 년에 객체 지향의 약속 (클래스 이름이 C 인 클래스)이 객체 지향 프로그래밍의 성공의 초석이라고 생각합니다.

더 많은 관점에 대한 참고 자료 -http : //journal.thedacs.com/issue/43/88

왜 OO?

그 당시 (프로젝트 성공 관점을 보면) 더 잘 이해할 수있는 것이 더 잘 관리 될 수 있다고 생각했습니다. "삶의 모든 것은 대상이다" 라는 약속을 가진 객체 지향 방법론 은 의미가 입증되기 전에도 상식과 비슷해 보였다. 이 요소의 실질적인 성공은 총을 뛰어 넘기 전에 실제 세계와 문제 를 충분히 모델링 하는 개념이었습니다. 저는 OO가 제공 한 근본적으로 새로운 것이 그 당시까지 다른 패러다임이 제공하지 않은 것으로 생각합니다. 그리고이 패러다임 은 절차 적 언어보다 더 많은 코드를 작성하기 전에 채택한 소프트웨어 프로젝트에서 눈에 띄는 성공을 보여준 이후에 그들이 생각한 것을 강요 했습니다!

편집
나는 또한 프로그래밍 언어가 이러한 기본 개념 (OO 패러다임, Aspect, 가상 머신)과 동시에 동시에 진화했다는 것을 덧붙일 것입니다. 각각 새로운 개념과 신선한 사고는 새로운 새로운 프로그래밍 언어가 그것을 마스터했을 때만 나타납니다. 핵심! 동시에 이러한 새로운 개념과 새로운 언어는 새로운 비즈니스 문제로 인해 등장했습니다. 1980 년대-대규모 소프트웨어를위한 OO, 인터넷 시대의 1990 Java, PHP / ASP 및 웹을위한 기타 여러 가지. 프로그래밍 언어의 혁신은 또한 불연속적인 시장 요구에 의해 주도되었습니다.

요약하자면, 80 년대 초반에는 대규모 상용 소프트웨어가 시작된 시대였습니다. 절차 언어가있는 프로젝트에는 문제가 있었지만, OO는 더 나은 조명을 보여주고 프로젝트를 더 성공적으로 만들었습니다.

가장 큰 이유는 X 및 Windows와 같은 그래픽 사용자 인터페이스의 성공 때문이라고 생각합니다. GUI는 자체적으로 동작을하는 여러 개체로 구성되며, OO가 밀접하게 나타낼 수있는 것입니다.

반면에 GUI와 유사한 텍스트 기반 사용자 인터페이스는 종종 명령 응답 패턴을 따르기 때문에 절차 언어로 쉽게 구현할 수 있습니다. 비즈니스 규칙 및 이와 유사한 내용은 너무 많은 문제없이 수십 년 동안 절차 언어로 구현되어 왔으며 오늘날에도 비즈니스 응용 프로그램을위한 많은 OO 프로그램은 다소 절차 적입니다. 데이터를 보유하는 어리석은 개체와 비즈니스 규칙을 포함하는 상태 비 저장 개체 첫 번째는 절차 적 언어로 기록 될 수 있고, 나중에는 절차 일 수 있습니다.

OOP는 절차 코드에서 자연스럽게 진화하는 단계라고 생각합니다.

1. 절차 코드 : 기계에 A를 수행하도록 지시 한 다음 B에 지시하십시오.
2. OOP : 인터페이스 / 입력 / 출력을 정의하여 절차 지침을 재사용 가능한 청크로 구성합니다. (경고 : 단순화)

더 넓은 시야를 가진 사람이 차임 할 것이라고 확신하지만, 프로그래머가 코드를 더 빨리 생성 할 수있게하는 자연스러운 진보 인 것 같습니다. 즉, 더 큰 코드 재사용을 허용합니다.

이 관점에서 가장 큰 외부 요인은 프로세서 마력 비용 (일반적인 프로그램을 작성하는 데 개발자 인건비 대비)이 줄어드는 것입니다. OOP 클래스를 사용하는 데 드는 오버 헤드 계산은 개발자 시간 절약보다 문제가되지 않았습니다. (CPU 비용과 프로그래머 비용의 동일한 트레이드 오프는 프로그래밍의 다른 많은 측면에 영향을 미쳤습니다.)

처음에는 명령형 프로그래밍이있었습니다 (당신이 그것을 호출 할 수 있다면). 메인 프레임에게 무엇을 어떻게 계산해야하는지 알려주는 간단한 지침. 이러한 프로그래밍 언어는 무조건 점프와 기타 "비 구조적"명령어를 사용했으며, 대부분 오늘날의 표준에 따라 이색적입니다.

그런 다음 누군가 프로그래밍을위한 구조를 고안했습니다. 우리가 오늘 알고있는 동안,하는 동안 그리고하는 동안. 비교적 복잡한 흐름을 가진 응용 프로그램을 쉽게 작성하고 이해할 수 있었기 때문에 큰 혁신이었습니다. 따라서 구조화 된 프로그래밍이 탄생했습니다.

그런 다음 여기에 많은 코드를 반복해야한다고 말한 다른 사람들이 왔으며 코드를 재사용하는 방법을 발명 해야하는 것은 악몽이었습니다. 사람들은 재사용 가능한 코드 비트를 구분하기위한 절차와 기능을 고안했습니다. 이것은 또한 캡슐화와 단일 책임 원칙을 낳았습니다.

그런 다음 일부 학자들은 기능이 작업중인 데이터와 밀접하게 연결되어야한다고 말했습니다. 그런 다음 코드 재사용 및 다형성에 대한 상속 개념을 추가하여 실제 작업에서 논리적으로 분류 된 방식과 일치하도록했습니다. 따라서 3 세대 프로그래밍 언어와 OOP가 탄생했습니다.