자연스럽지 않기 때문에 OOP가 어렵습니까?

OOP는 사람들이 세상에 대해 생각하는 방식과 자연스럽게 일치한다는 것을 종종들을 수 있습니다. 그러나 나는이 진술에 강력히 동의하지 않을 것이다. 우리 (또는 적어도 나는) 는 우리가 만나는 것들 사이 의 관계 측면에서 세계를 개념화 하지만, OOP의 초점은 개별 클래스와 계층을 설계하는 것이다.

일상 생활에서 관계와 행동은 대부분 OOP에서 관련없는 클래스의 인스턴스였던 객체 사이에 존재합니다. 이러한 관계의 예는 다음과 같습니다. "내 화면이 테이블 위에 있습니다"; "나는 (인간이) 의자에 앉아있다"; "자동차가 도로에있다"; "키보드에 입력하고 있습니다"; "커피 머신이 물을 끓인다", "텍스트가 터미널 창에 표시됩니다."

동사는 2가 (때로는 "나에게 꽃을 줬다"와 같이 3가) 동사로 생각되는데 여기서 동사는 두 개의 객체에서 작동하여 결과 / 동작을 생성하는 동작 (관계)입니다. 포커스 동작을하고, 두 개의 (또는 세) 문법] 개체 동등한 중요성을 갖는다.

OOP와는 대조적으로 먼저 하나의 오브젝트 (명사)를 찾아서 다른 오브젝트에 대한 조치를 수행하도록 지시해야합니다. 사고 방식은 명사에서 작동하는 동작 / 동사에서 명사에서 작동하는 명사로 이동합니다. 마치 마치 "단말기 창에 텍스트가 표시되는 것과 같이"수동적이거나 재귀적인 목소리로 모든 것이 말하는 것처럼 말입니다. 또는 "텍스트가 터미널 창에 그려집니다".

초점이 명사로 이동되었을뿐만 아니라 명사 중 하나 (문법 주제라고 함)에 다른 명사 (문법적 대상)보다 "중요도"가 높아집니다. 따라서 terminalWindow.show (someText) 또는 someText.show (terminalWindow) 중 어느 것을 말할 것인지 결정해야합니다. 그러나 실제로 show (terminalWindow, someText)를 의미 할 때 운영상의 결과가없는 사소한 결정을 내리는 사람들에게 왜 부담이됩니까? [결과는 운영상 미미합니다. 두 경우 모두 텍스트가 터미널 창에 표시됩니다. 그러나 클래스 계층 구조 디자인에서 매우 심각 할 수 있으며 "잘못된"선택은 코드를 복잡하고 유지하기 어려울 수 있습니다.]

그러므로 나는 OOP (class-based, single-dispatch)를하는 주류 방식은 비 자연적이며 인간이 세상에 대해 어떻게 생각하는지에 맞지 않기 때문에 어렵다고 주장한다. CLOS의 일반적인 방법은 내가 생각하는 방식에 더 가깝지만 아쉽게도 이것은 널리 퍼진 접근법이 아닙니다.

이러한 문제를 감안할 때 현재 OOP를 수행하는 주류 방식이 인기를 얻은 이유는 무엇입니까? 그리고 그것을 막기 위해 무엇을 할 수 있습니까?

일부 문제에는 OOP가 부자연 스럽습니다. 절차 적입니다. 기능적입니다. OOP에는 실제로 어려운 것처럼 보이는 두 가지 문제가 있다고 생각합니다.

1. 어떤 사람들은 프로그램을하는 유일한 방법 인 것처럼 행동하고 다른 모든 패러다임은 잘못되었습니다. IMHO는 모두 다중 패러다임 언어를 사용해야하며 현재 진행중인 하위 문제에 가장 적합한 패러다임을 선택해야합니다. 코드의 일부 부분에는 OO 스타일이 있습니다. 일부는 작동합니다. 일부는 직선형 절차 스타일을 갖습니다. 경험을 통해 패러다임이 무엇에 가장 적합한 지 분명해집니다.

   에이. OO는 일반적으로 동작하는 상태와 강력하게 연결된 동작이있을 때 가장 적합하며 상태의 정확한 특성은 구현 세부 사항이지만 해당 상태의 존재를 쉽게 추상화 할 수는 없습니다. 예 : 컬렉션 클래스

   비. 절차는 특정 데이터와 강력하게 연결되지 않은 동작이 많은 경우에 가장 좋습니다. 예를 들어, 원시 데이터 유형에서 작동 할 수 있습니다. 여기서 행동과 데이터를 별도의 엔티티로 생각하는 것이 가장 쉽습니다. 예 : 숫자 코드

   씨. 어떤 상태라도 존재하면 쉽게 추상화 할 수있는 구현 세부 사항이되도록 선언적으로 작성하기 쉬운 것이있을 때 기능이 가장 좋습니다. 예 : 병렬 처리를 매핑 / 축소합니다.

2. OOP는 일반적으로 잘 캡슐화 된 코드 조각이 실제로 필요한 대규모 프로젝트에서 유용성을 보여줍니다. 초보자 프로젝트에서는 그렇게 많이 일어나지 않습니다.

IMHO 그것은 개인적인 취향과 사고 방식의 문제입니다. OO에는 큰 문제가 없습니다.

우리는 (또는 적어도 나는) 우리가 만나는 것들 사이의 관계 측면에서 세계를 개념화하지만, OOP의 초점은 개별 클래스와 계층을 설계하는 것입니다.

IMHO 이것은 일반적인 인식일지도 모르지만, 그렇지 않습니다. OO라는 용어를 발명 한 Alan Kay는 항상 대상 자체가 아니라 대상간에 전송 되는 메시지를 강조 했습니다. 그리고 적어도 나에게 보내는 메시지는 관계를 나타냅니다.

일상 생활에서 관계와 행동은 대부분 OOP에서 관련없는 클래스의 인스턴스였던 객체 사이에 존재합니다.

객체간에 관계가 있으면 정의마다 관련됩니다. OO에서는 두 클래스 간의 연관 / 집계 / 사용 종속성으로 표현할 수 있습니다.

동사는 2가 (때로는 "나에게 꽃을 줬다"와 같이 3가) 동사로 생각되는데 여기서 동사는 두 개의 객체에서 작동하여 결과 / 동작을 생성하는 동작 (관계)입니다. 행동에 중점을두고 있으며, 2 개 (3 개) [문법적] 객체는 동일한 중요성을 가지고 있습니다.

그러나 그들은 여전히 ​​문맥에서 주제, 대상, 행동 등 잘 정의 된 역할을 가지고 있습니다. "나는 당신에게 꽃을 줬습니다"또는 "당신은 나에게 꽃을 줬습니다"는 같지 않습니다 ( "꽃이 당신에게 나에게 줬다"는 말할 것도 없습니다) : -)

OOP와는 대조적으로 먼저 하나의 오브젝트 (명사)를 찾아서 다른 오브젝트에 대한 조치를 수행하도록 지시해야합니다. 사고 방식은 명사에서 작동하는 동작 / 동사에서 명사에서 작동하는 명사로 이동합니다. 마치 마치 "단말기 창에 텍스트가 표시되는 것과 같이"수동적이거나 재귀적인 목소리로 모든 것이 말하는 것처럼 말입니다. 또는 "텍스트가 터미널 창에 그려집니다".

나는 이것에 동의하지 않습니다. 영어 문장 "빌, 지옥에 가서는"같은 프로그램 코드에 더 자연스럽게 읽고 이럴 bill.moveTo(hell)보다는 move(bill, hell). 그리고 전자는 사실 원래의 활성 음성과 더 유사합니다.

따라서 terminalWindow.show (someText) 또는 someText.show (terminalWindow)를 말할 것인지 결정해야합니다.

다시 말하지만 터미널에 텍스트를 표시하도록 요청하거나 터미널에 텍스트를 표시하도록 요청하는 것은 동일하지 않습니다. IMHO 어느 것이 더 자연스러운 지 분명합니다.

이러한 문제를 감안할 때 현재 OOP를 수행하는 주류 방식이 인기를 얻은 이유는 무엇입니까?

OO 개발자 대부분이 OO를 다르게 보는 이유가 있을까요?

일부 프로그래머는 문제를 해결하는 방법이 아니라 컴퓨터의 문제를 해결하는 방법에 대해 생각하기 때문에 OOD를 어렵게 생각합니다.

...하지만 OOP의 초점은 개별 클래스와 해당 계층을 디자인하는 것입니다.

OOD는 그것에 관한 것이 아닙니다. OOD는 사물이 어떻게 행동하고 상호 작용하는지 파악하는 것입니다.

동사는 2가 (때로는 "나에게 꽃을 줬다"와 같이 3가) 동사로 생각되는데 여기서 동사는 두 개의 객체에서 작동하여 결과 / 동작을 생성하는 동작 (관계)입니다. 행동에 중점을두고 있으며, 2 개 (3 개) [문법적] 객체는 동일한 중요성을 가지고 있습니다.

OOD에 중점을 두는 것은 항상 행동이며, 행동은 물체의 행동입니다. 그들의 행동이 없다면 사물은 아무것도 아닙니다. OOD의 유일한 객체 제약은 모든 것이 무언가에 의해 이루어져야한다는 것입니다.

나는 그 행동이 무언가를 한 것보다 더 중요하다고 생각하지 않습니다.

그러나 실제로 show (terminalWindow, someText)를 의미 할 때 운영상의 결과가없는 사소한 결정을 내리는 사람들에게 왜 부담이됩니까?

나에게 그것은 다른 표기법과 같은 것입니다. 당신은 여전히 ​​누가 쇼어인지 누가 누비인지 결정해야합니다. 일단 알면 OOD에는 아무런 결정이 없습니다. Windows 표시 텍스트-> Window.Show (text).

많은 것들 (특히 레거시 영역에서)은 그렇지 않을 때 OO라고 말합니다. 예를 들어 OOD 그림을 구현하지 않는 방대한 양의 C ++ 코드가 있습니다.

컴퓨터에 대한 문제를 해결한다는 사고 방식을 벗어나면 OOD가 쉽습니다. 당신은 일을하는 일에 대한 문제를 해결하고 있습니다.

어쩌면, 나는 요점을 얻을 수 없지만 :

OOP에 관한 첫 번째 책 (파스칼에 대한 볼랜드의 얇은 매뉴얼 인 90 년대 초)을 읽음으로써 나는 그 단순성과 잠재력에 놀랐습니다. (전에는 Cobol, Fortran, Assembly language 및 기타 선사 시대 자료를 사용했습니다.)

나를 위해, 그것은 분명합니다 : 개는 동물이고, 동물은 먹어야하고, 내 개는 개이므로 먹어야합니다 ...

다른 한편으로, 프로그래밍 자체는 본질적으로 부자연 스럽습니다 (즉, 인공적). 인간의 말은 인공적입니다 (나를 비난하지 말고, 우리 모두는 다른 사람들로부터 우리의 언어를 배웠으며, 영어를 발명 한 사람은 아무도 모릅니다). 일부 과학자들에 따르면, 인간의 마음은 그가 처음 배운 언어에 의해 형성됩니다.

나는 현대 OO 언어의 일부 구조는 약간 어색하지만 그것은 진화 적이라고 인정한다.

나를 어렵게 만든 한 가지는 OOP가 세상을 모델링하는 것이라고 생각했습니다. 나는 그 권리를 얻지 못하면 무언가가 와서 엉덩이에 물릴 수 있다고 생각했습니다 (사실은 사실 이건 아니건). 나는 모든 것을 가장하는 것이 대상이나 실체라는 문제를 잘 알고있었습니다. 이로 인해 OOP 프로그래밍에 대해 잠정적으로 확신을 얻지 못했습니다.

그런 다음 SICP를 읽고 실제로 데이터 유형 및 액세스 제어에 관한 것이라는 새로운 이해를 얻었습니다. 내가 틀린 전제에 기초했기 때문에 내가 녹아 낸 모든 문제는 OOP에서 당신이 세상을 모델링하고 있다는 것입니다.

나는 여전히이 거짓 전제가 내게 준 엄청난 어려움에 감탄하고 있습니다.

그렇습니다. OOP 자체는 매우 부자연 스럽습니다. 실제 세계는 완전히 계층 적 분류법으로 만들어지지 않았습니다. 그것의 일부 작은 부분은 그 재료로 만들어졌으며 그 부분은 OO로 적절하게 표현할 수있는 유일한 것입니다. 나머지는 자연스럽고 제한적인 사고 방식에 자연스럽게 맞지 않습니다. 자연 과학을보고, 현실 세계의 복잡성을 가장 단순하거나 이해하기 쉬운 방식으로 표현하기 위해 몇 가지 다른 수학적 언어가 발명되었는지 살펴보십시오. 그리고 그중 어느 것도 객체와 메시지의 언어로 쉽게 번역 할 수 없습니다.

우리는 (또는 적어도 나는) 우리가 만나는 것들 사이의 관계 측면에서 세계를 개념화하지만, OOP의 초점은 개별 클래스와 계층을 설계하는 것입니다.

당신은 (IMO) 잘못된 전제에서 시작하고 있습니다. 객체 사이의 관계는 객체 자체보다 더 중요합니다. 객체 지향 프로그램 구조를 제공하는 관계입니다. 클래스의 관계인 상속은 물론 개체의 클래스가 해당 개체 가 수행 할 수있는 작업을 결정하므로 중요합니다 . 그러나 개체가 클래스에 의해 정의 된 범위 내에서 실제로 수행 하는 작업과 프로그램의 동작 을 결정하는 것은 개별 개체 간의 관계 입니다.

객체 지향 패러다임은 새로운 범주의 객체를 생각하기가 어렵 기 때문에가 아니라, 객체 그래프를 구상하고 객체 간의 관계가 무엇인지 이해하기가 어렵 기 때문에 특히 어려울 수 있습니다. 이러한 관계를 설명하는 방법. 이것이 바로 디자인 패턴이 유용한 이유입니다. 디자인 패턴은 거의 전적으로 객체 간의 관계에 관한 것입니다. 패턴은 객체 관계를 더 높은 수준으로 디자인하는 데 사용할 수있는 빌딩 블록과 이러한 관계를 설명하는 데 사용할 수있는 언어를 모두 제공합니다.

실제 세계에서 작동하는 창조적 인 분야에서도 마찬가지입니다. 누구나 방을 모아 건물이라고 부를 수 있습니다. 객실에는 최신 시설이 모두 갖추어져 있지만 건물이 작동하지는 않습니다. 건축가의 임무는 해당 회의실을 사용하는 사람들의 요구 사항과 건물 환경에 따라 해당 회의실 간의 관계를 최적화하는 것입니다. 이러한 관계를 올바르게하는 것이 기능적 및 미적 관점 모두에서 건물을 작동시키는 것입니다.

OOP에 익숙해지는 데 어려움이 있다면, 개체가 서로 어떻게 조화를 이루고 책임이 어떻게 배열되는지에 대해 더 많이 생각하는 것이 좋습니다. 아직 디자인 패턴에 대해 읽지 않았다면 이미 읽은 패턴을 보았지만 이름을 지정하면 나무뿐만 아니라 스탠드, 경찰, 덤불, 숲, 숲, 숲, 결국 숲.

이것은 OOP의 문제점 중 일부일뿐입니다.

본질적으로 기능은 2 급 시민이되며 이는 나쁘다.

현대 언어 (루비 / 파이썬)는이 문제를 겪지 않으며 함수를 일급 객체로 제공 할뿐만 아니라 클래스 계층 구조를 구축하지 않고도 프로그램을 만들 수 있습니다.

OOP는 어렵지 않습니다. 잘 사용하기 어려운 점은 무엇이 좋은지, 프로그래머가 무작위 최대 값을 듣고, 숨쉬는 동안 자신을 반복하여 축복받은 마틴 파울러, 또는 축복받은 마틴 파울러 또는 그들이 읽고 있던 다른 사람.

편집

우선, 나는 다른 프로그래밍 패러다임보다 OOP를 어렵거나 어렵게 생각하지 않았다고 말하고 싶습니다. 프로그래밍은 현실 세계의 문제를 해결하려고 시도하기 때문에 본질적으로 어렵고 현실 세계는 매우 복잡합니다. 반면에,이 질문을 읽을 때 나는 스스로에게 물었다 : OOP는 다른 패러다임보다 "자연적"인가? 따라서 더 효과적입니까?

한 번은 명령형 프로그래밍 (IP)과 객체 지향 프로그래밍 (OOP)의 비교 연구에 관한 기사를 찾았습니다. 그들은 기본적으로 다른 프로젝트에서 IP와 OOP를 사용하는 전문 프로그래머의 생산성을 측정했으며 그 결과 큰 차이를 보지 못했습니다. 따라서 두 그룹간에 생산성에 큰 차이가 없으며 실제로 중요한 것은 경험이라고 주장합니다.

다른 한편으로, 객체 지향의 지지자들은 시스템의 초기 개발 과정에서 OOP가 명령보다 더 많은 시간이 걸릴 수 있지만 장기적으로 데이터와 데이터 사이의 긴밀한 통합으로 인해 코드를 유지 및 확장하기가 더 쉽다고 주장합니다. 작업.

나는 주로 OOP 언어 (C ++, Java)로 작업했지만 대규모 프로젝트에서 사용해 본 적이 없어도 Pascal 또는 Ada를 사용하여 생산성을 높일 수 있다는 느낌이 듭니다.

OOP와는 대조적으로 먼저 하나의 오브젝트 (명사)를 찾아서 다른 오브젝트에 대한 조치를 수행하도록 지시해야합니다.

[절단]

그러므로 나는 OOP (class-based, single-dispatch)를하는 주류 방식은 비 자연적이며 인간이 세상에 대해 어떻게 생각하는지에 맞지 않기 때문에 어렵다고 주장한다. CLOS의 일반적인 방법은 내가 생각하는 방식에 더 가깝지만 아쉽게도 이것은 널리 퍼진 접근법이 아닙니다.

이 마지막 단락을 더 자세히 읽으면 마침내 질문의 요점을 이해했으며 내 대답을 처음부터 다시 작성해야했습니다. :-)

여러 개체가 하나 대신 메시지를받는 다른 OO 제안을 알고 있습니다. 즉, 여러 개체가 메시지를받을 때 대칭 역할을합니다. 그렇습니다. 이것은 나에게 더 일반적이고 제한적인 OOP 접근 방식으로 보입니다.

한편, "단일 디스패치"를 사용하여 "다중 디스패치"를 쉽게 시뮬레이션 할 수 있고 "단일 디스패치"를 구현하기가 더 쉽다. 아마도 이것이 "다중 디스패치"가 주류가되지 않은 이유 일 것입니다.

독점적으로 OOP 패러다임을 찾지 말고 JavaScript를 사용해보십시오.

현재 UI 객체가 이벤트 중심 인터페이스에서 작동하는 체계가 있습니다. 다시 말해, 해고 될 때 내부적으로 정의 된 동작이 발생하는 일반적인 공개 방법처럼 보입니다. 그러나 발생하면 실제로 객체 자체에서 이벤트를 트리거하고 해당 객체 내부의 사전 정의 된 핸들러가 응답합니다. 이 이벤트와 다른 리스너에게 전달되는 속성을 첨부 할 수있는 이벤트 객체는 듣고 자하는 모든 것에 의해들을 수 있습니다. 객체를 직접 듣거나 해당 이벤트 유형을 일반적으로 수신 할 수 있습니다 (공장에서 만든 모든 객체가들을 수있는 일반 객체에서 이벤트가 트리거 됨). 예를 들어 드롭 다운 목록에서 새 항목을 선택할 수있는 콤보 상자가 있습니다.

원하는 경우 (그리고 일반적으로 원하지 않는 것을 발견했다는 사실에 놀랐습니다. 이벤트가 어디서 발생했는지 알 수없는 경우 가독성 문제입니다) 객체 분리를 완료하고 전달 된 이벤트 객체를 통해 컨텍스트를 설정할 수 있습니다. 그럼에도 불구하고 여러 응답자를 등록 할 수있어 단일 디스패치를 ​​계속 피할 수 있습니다.

그러나 OOP만으로는이 작업을 수행하지 않으며 JS는 일부 정의에 의해 '올바로'OOP되지 않습니다. 제 생각에는 앱 개발 수준이 높을수록 상황에 맞는 패러다임을 구부릴 수있는 능력이 있으며 관심이 있다면 수업을 잘 모방 할 수 있습니다. 그러나이 경우에는 함수 (전달 핸들러)의 측면을 OOP와 혼합하고 있습니다.

더 중요한 것은, 내가 가지고있는 것이 꽤 강력하다는 것입니다. 한 물체가 다른 물체에 작용하는 것으로 생각하지 않습니다. 나는 기본적으로 객체가 무엇을 신경 쓰는지 결정하고 물건을 정리하는 데 필요한 도구를 제공하고 믹서에 떨어 뜨리고 서로 반응하게합니다.

그래서 내가 말하는 것은 이것입니다 : 그것은 스위치 문 종류의 문제가 아닙니다. 믹스 앤 매치입니다. 문제는 언어와 유행이며, 이것이 당신이 생각하는 것 중 하나라고 생각합니다. 예를 들어, 주니어 자바 개발자는 항상 기본적으로 항상 제대로하고 있다고 생각할 때 어떻게 OOP를 높이 평가할 수 있습니까?

그것이 나에게 설명 된 방식은 토스터와 자동차였습니다. 둘 다 스프링이 있으므로 "스프링"오브젝트가 있고 크기, 강도 등이 다르지만 둘 다 "스프링"이되어 차에 그 은유를 확장시킵니다. (바퀴에 스티어링 휠을 더한듯한 느낌) 그리고 그것은 많은 의미가있었습니다.

그런 다음 프로그램을 객체 목록으로 생각할 수 있으며 "작업을 수행하는 작업의 목록이므로 이전에 본 지침 목록과 같지 않습니다"라고 시각화하는 것이 훨씬 간단합니다.

OOP의 실제 문제는 사람들에게 설명하는 방법이라고 생각합니다. 종종 (내 유니 클래스에서) 나는 "그것은 거의 일을하지 않는 많은 클래스에 관한 것이고, 당신은 그로부터 객체를 만들 수 있습니다"라고 말하면서 설명되는 것을 본다. 사람들이 레고를 가지고 노는 5 살 때 파악한 구체적인 아이디어보다는 오히려 이러한 개념을 설명하는 용어입니다.

분류를 통해 세상을 생각하는 자연스러운 방법입니다. 그것은 OO에 관한 것입니다. 프로그래밍이 어렵 기 때문에 OOP는 어렵다.

사람들이 현실을 표현하기 위해 OOP를 사용하려고 할 때 어려움이 있다고 생각합니다. 차에는 4 개의 바퀴와 엔진이 있다는 것을 모두 알고 있습니다. 모두가 알고있는 자동차 수 Start(), Move()과 SoundHorn().

내가 항상이 일을 멈춰야한다는 것을 깨달았을 때 머리에 불이 들어왔다. 객체는 이름을 공유하는 것이 아닙니다. 목적은 문제의 범위와 관련된 충분히 상세한 데이터 파티션이다. 그것은 ought문제에 대한 해결책이 필요로하는 것을 정확히, 더 이상 갖지 않게하는 것입니다. 어떤 행동을 담당하는 물체를 만드는 것이 같은 행동이 끔찍한 제 3 자의 일인 것보다 더 많은 코드 줄을 초래한다면 (일부는 '폴 터지 스트'라고 부를 수 있음), 폴트 르게 이스트는 칩을 얻습니다.

복잡성을 관리하려면 기능을 모듈로 그룹화해야하며 이는 일반적으로 어려운 문제입니다. 자본주의에 대한 오래된 말처럼 OOP는 우리가 시도한 다른 모든 것을 제외하고는 소프트웨어를 구성하는 최악의 시스템입니다.

명사 내에서 상호 작용을 그룹화하는 이유는 두 명사 중 어느 명사와 함께 모호해야하는지 모호하지만 종종 명사 수는 관리 가능한 크기의 클래스로 해결되는 반면 동사별로 그룹화하면 일회용과 같은 매우 작은 그룹 또는 show 와 같은 기능을위한 매우 큰 그룹 . 상속과 같은 재사용 개념은 명사별로 그룹화 할 때 훨씬 쉽게 해결됩니다.

또한, 창으로 보여줄 것인지 텍스트로 보여줄지 를 결정하는 문제는 이론보다 실제로 항상 훨씬 더 명확합니다. 예를 들어, 거의 모든 GUI 툴킷 그룹 이 컨테이너와 함께 추가 되지만 위젯과 함께 표시 됩니다. 다른 방법으로 코드를 작성하려고하면 추상적으로 생각할 때 두 가지 방법이 서로 호환되는 것처럼 보이지만 그 이유는 상당히 빠릅니다.

없음 . 프로그래밍을 사용하여 문제를 해결하는 방법에는 기능, 절차, 논리, OOP 등 여러 가지가 있습니다.

현실 세계에서 때때로 사람들은 기능적 패러다임을 사용하고 때로는 절차 적 패러다임 등을 사용하기도합니다. 그리고 때때로 우리는 뒤섞였다. 그리고 결국 우리는 그것들을 특정한 스타일이나 프로그래밍 패러다임으로 표현합니다.

LISP에서 사용되는 "모든 것이 목록이나 아이템"이라는 패러다임도 있습니다. 함수형 프로그래밍과 다른 점을 언급하고 싶습니다 . PHP는 이것을 연관 배열에서 사용합니다.

OOP와 "Everything is a list or item"패러다임은 일부 인공 지능 클래스에서 기억하는 것처럼 NATURAL 프로그래밍 스타일 중 2 가지를 고려 합니다.

"OOP는 자연스럽지 않습니다.", 어쩌면 당신이 배우는 방식, 또는 OOP에 대해 배운 방식이 잘못되었지만 OOP 자체는 아닙니다.

이러한 문제를 감안할 때 현재 OOP를 수행하는 주류 방식이 인기를 얻은 이유는 무엇입니까? 그리고 그것을 막기 위해 무엇을 할 수 있습니까?

OOP는 이전의 인기있는 절차 언어보다 높은 수준의 추상화로 프로그램을 구성 할 수있는 도구를 제공하기 때문에 인기를 얻었습니다. 또한 메소드 내부에 절차 적 구조를 갖는 언어와이를 둘러싼 객체 지향 구조를 만드는 것이 상대적으로 쉬웠다. 이를 통해 이미 프로그래밍 방식으로 프로그래밍하는 방법을 알고있는 프로그래머는 한 번에 하나씩 OO 원칙을 선택할 수 있습니다. 이것은 또한 하나 또는 두 개의 클래스로 싸인 절차 적 프로그램 인 많은 OO-in-name-only 프로그램으로 이어졌습니다.

OO를 막으려면 오늘날 대부분의 프로그래머가 알고있는 것 (주로 절차 적이며 약간의 OO)에서 선호하는 패러다임으로 쉽게 전환 할 수있는 언어를 구축하십시오. 일반적인 작업을 수행하고 잘 홍보 할 수있는 편리한 API를 제공해야합니다. 사람들은 곧 당신의 언어로 X-in-name-only 프로그램을 만들 것입니다. 그러면 사람들이 실제로 X를 잘하는 데 몇 년과 몇 년이 걸릴 것으로 예상 할 수 있습니다.

OOP와 OOP 언어에도 문제가 있다고 생각합니다.

올바르게 이해하면 OOP는 블랙 박스 (개체)에 관한 것으로 푸시 버튼이있는 블랙 박스 (개체)에 관한 것입니다 (방법). 이 블랙 박스를 구성하는 데 도움이되는 수업이 있습니다.

프로그래머가 푸시 버튼을 잘못된 물체에 놓을 때 문제가 발생합니다. 터미널 자체에 텍스트를 표시 할 수없고 텍스트가 터미널에 자체를 표시 할 수 없습니다. 이를 수행 할 수있는 운영 체제의 창 관리자 구성 요소. 터미널 창과 텍스트는 수동적 인 엔터티입니다. 그러나 우리가 이런 방식으로 생각한다면 우리는 대부분의 실체가 수동적 인 것임을 깨닫고 실제로 어떤 일 (또는 단순히 하나 의 컴퓨터 )을 하는 아주 적은 객체를 가질 것 입니다. 실제로 C를 사용할 때이를 모듈로 구성하면 이러한 모듈은 해당 객체를 거의 나타내지 않습니다.

또 다른 요점은 컴퓨터가 명령을 순차적으로 실행 한다는 것입니다. 의 당신이 있다고 가정하자 VCR와 Television비디오를 재생 얼마나, 오브젝트를? 아마도 다음과 같이 쓸 것입니다.

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

이것은 간단하지만 최소한 3 개의 프로세서 ( 또는 프로세스 )가 필요합니다. 하나는 자신의 역할을하고, 두 번째는 VCR이고, 세 번째는 TV입니다. 그러나 일반적으로 하나의 코어 만 있습니다 (적어도 모든 객체에 충분하지는 않습니다). 대학에서는 많은 반 친구들이 푸시 버튼이 비싼 작업을 수행 할 때 GUI가 정지되는 이유를 이해하지 못했습니다.

따라서 객체 지향 디자인이 세상을 잘 묘사한다고 생각하지만 컴퓨터에 가장 적합한 추상화는 아닙니다.

MVC 패턴의 발명자가 발명 한 DCI (데이터, 컨텍스트 및 상호 작용)를 살펴보십시오 .

DCI의 목표는 다음과 같습니다 (Wikipedia에서 인용).

• 객체 (명사) 위에 시스템 동작 에 일류 상태를 제공 합니다 .
• 하나의 클래스 인터페이스에서 둘을 결합하는 대신, 시스템 동작을 빠르게 변경하기위한 코드 (시스템이하는 일)와 도메인 지식을 천천히 변경하기위한 코드 (시스템이있는 것)를 깨끗하게 분리합니다.
• 계급적 사고 방식보다는 사람들의 정신적 모델에 가까운 사고 방식을지지한다.

다음 은 저자가 작성한 좋은 기사 이며 일부 코드를보고 싶다면 작은 예제 구현 (.NET) 입니다. 소리보다 훨씬 단순하고 매우 자연 스럽습니다.

OOP는 사람들이 세상에 대해 생각하는 방식과 자연스럽게 일치한다는 것을 종종들을 수 있습니다. 그러나 나는이 진술에 강력하게 동의하지 않을 것입니다 (...)

그것이 책과 다른 곳에서 수십 년 동안 복음화됨에 따라 나는 그것에 동의하지 않습니다. 그럼에도 불구하고, 나는 Nygaard와 Dahl이 그것을 그렇게 생각한 사람들이라고 생각하며, 그들은 시간의 대안과 비교하여 시뮬레이션을 설계하는 것이 얼마나 쉬운 지에 집중하고 있다고 생각합니다.

(...) 그러나 OOP의 초점은 개별 클래스와 해당 계층을 디자인하는 것입니다.

이 주장은 OOP에 대한 대중적인 오해와 OO가 정의에 얼마나 민감한 지에 따라 합리적인 영역으로 들어갑니다. 이 분야에서 10 년 넘게 산업 분야와 학계 연구를 모두 수행했습니다. 언어, 그리고 나는 "주류 OO"를 배우는 데 오랜 시간을 보냈다는 것을 알 수 있습니다. 왜냐하면 나는 초기 제작자들이 목표로하는 것이 얼마나 다른지 (그리고 열등한 지) 알기 시작했기 때문입니다. 이 주제에 대한 최신의 최신 치료를 위해 W. Cook의 최근 노력을 언급합니다.

"개체"및 "개체 지향"에 대한 단순화 된 최신 정의를위한 제안 http://wcook.blogspot.com.br/2012/07/proposal-for-simplified-modern.html

이러한 문제를 감안할 때 현재 OOP를 수행하는 주류 방식이 인기를 얻은 이유는 무엇입니까?

QWERTY 키보드가 인기를 얻은 것과 같은 이유 또는 DOS 운영 체제가 인기를 얻은 것과 같은 이유입니다. 물건은 속성에도 불구하고 인기있는 차량을 타고 인기를 얻습니다. 그리고 때로는 유사하지만 더 나쁜 버전의 것이 실제적인 것으로 간주됩니다.

그리고 그것을 막기 위해 무엇을 할 수 있습니까?

우수한 접근 방식을 사용하여 프로그램을 작성하십시오. OO 접근 방식을 사용하여 동일한 프로그램을 작성하십시오. 전자는 중요한 모든 측면에서 후자보다 우수한 특성을 나타냅니다 (시스템 자체의 특성 및 엔지니어링 특성). 선택한 프로그램이 관련성이 있고 제안 된 접근 방식이 다른 종류의 프로그램에 적용되는 경우 높은 속성 품질을 유지함을 보여줍니다. 분석에 엄격하고 필요할 때 정확하고 수용 가능한 정의를 사용하십시오.

마지막으로, 발견 한 내용을 저희와 공유하십시오.

Java 사용 : 객체는 일종의 추상화 병목 현상이며 대부분의 "사물"은 객체의 하위 구성 요소이거나 하위 구성 요소로 사용됩니다. 객체는이 두 가지 유형의 사물 사이에서 전체 추상화 계층에 충분히 다목적이어야합니다. 다목적은 의미하는 은유가 없음을 의미합니다. 특히 Java는 객체 (& 클래스)를 코드를 호출 / 배포하는 유일한 계층으로 만듭니다. 솔직히 말해서 객체가 구현하는이 정도의 양은 너무 복잡합니다. 그것들에 대한 유용한 설명은 전문화되거나 제한된 형태로 제한되어야합니다.

상속 및 인터페이스 계층은 개체를 하위 구성 요소로 사용하는 "사물"입니다. 이것은 객체에 대한 일반적인 이해를 유도하는 방법이 아니라 객체를 설명하는 특수한 방법입니다.

"객체"는 "OO Langauge"에서 다소 보편적 인 다목적 추상화이기 때문에 많은 것을 가지고 있거나 말할 수 있습니다. 그것들이 로컬 변경 가능 상태를 포함하거나 외부 세계 상태에 액세스하는 데 사용되는 경우 "명사"와 매우 유사합니다.

반대로 프로세스를 나타내는 개체 (예 : "암호화"또는 "압축"또는 "정렬")는 "동사"처럼 보입니다.

일부 객체는 네임 스페이스로서의 역할 (예 : Java에서 "정적"기능을 배치하는 장소)로 사용됩니다.

Java가 객체에 대한 디스패치와 함께 객체 메소드 호출에 너무 무겁다는 주장에 동의하는 경향이 있습니다. 아마도 디스패치 제어에 Haskell의 유형 클래스를 선호하기 때문일 수 있습니다. 이것은 디스패치 제한이며 Java의 기능이지만 대부분의 언어 또는 대부분의 OO 언어는 아닙니다.

OOP에 대한 많은 온라인 토론을 목격하고 참여했습니다. OOP의 지지자들은 보통 적절한 절차 적 코드를 작성하는 방법을 모른다. 고도로 모듈화 된 절차 코드를 작성할 수 있습니다. 코드와 데이터를 분리하고 함수가 자신의 데이터 저장소에만 쓸 수 있도록 보장 할 수 있습니다. 절차 코드를 사용하여 상속 개념을 구현할 수 있습니다. 더 중요한 것은 절차 코드가 더 얇고 더 빠르고 디버깅하기 쉽다는 것입니다.

엄격한 이름 지정 규칙을 사용하여 단일 파일 모듈을 빌드하면 절차 코드가 OO보다 작성 및 유지 관리가 더 쉽고 동일하거나 더 빨리 수행됩니다. 응용 프로그램이 실행될 때 스크립트에 몇 개의 클래스 기능이 있더라도 항상 절차 적이라는 것을 잊지 마십시오.

그렇다면 PHP와 같은 언어 문제가 있습니다. PHP는 진정한 객체 지향적이지 않으며 여러 상속과 같은 가짜 물건에 대한 해킹에 의존합니다. 언어의 방향에 영향을 미치는 큰 장면은 PHP를 처음에는 의도 한 것보다 너무 큰 일관성이없는 규칙의 패치 워크로 바 꾸었습니다. 개발자가 절차 적 템플릿 언어로 의도 된 것에 대한 거대한 템플릿 클래스를 작성하는 것을 볼 때 나는 웃을 수밖에 없습니다.

제대로 작성된 OO 코드를 잘못 작성된 절차 코드와 비교하면 항상 잘못된 결론에 도달하게됩니다. 객체 지향 디자인을 보증하는 프로젝트는 거의 없습니다. IBM이고 여러 개발자가 수년간 유지해야하는 대규모 프로젝트를 관리하는 경우 Object Oriented로 이동하십시오. 고객을 위해 작은 블로그 나 쇼핑 웹 사이트를 작성하는 경우 두 번 생각하십시오.

원래 질문에 대답하기 위해 OOP는 실제보다 100 배 더 복잡한 솔루션에 의존하지 않고 실제 프로그래밍 딜레마를 해결하지 않기 때문에 어렵다. 많은 프로그래밍 문제에 대한 가장 강력한 솔루션 중 하나는 글로벌 데이터를 신중하게 사용하는 것입니다. 그러나 새로운 파동 대학 졸업생들은 그것이 큰 아니오라고 말할 것입니다. 전 세계적으로 사용 가능한 데이터는 서투른 프로그래밍 토끼 인 경우에만 위험합니다. 엄격한 규칙 집합과 적절한 명명 규칙이 있으면 모든 데이터를 전역으로 가져갈 수 있습니다.

최대 16K의 사용 가능한 메모리를 위해 어셈블러에서 체스 게임 응용 프로그램을 작성하는 방법을 알고 있어야하는 객체 지향 프로그래머는 필수 요구 사항이어야합니다. 그런 다음 지방을 다듬고 게으름을 줄이고 독창적 인 해결책을 만드는 방법을 배웁니다.