OOP는 사람들이 세상에 대해 생각하는 방식과 자연스럽게 일치한다는 것을 종종들을 수 있습니다. 그러나 나는이 진술에 강력히 동의하지 않을 것이다. 우리 (또는 적어도 나는) 는 우리가 만나는 것들 사이 의 관계 측면에서 세계를 개념화 하지만, OOP의 초점은 개별 클래스와 계층을 설계하는 것이다.
일상 생활에서 관계와 행동은 대부분 OOP에서 관련없는 클래스의 인스턴스였던 객체 사이에 존재합니다. 이러한 관계의 예는 다음과 같습니다. “내 화면이 테이블 위에 있습니다”; “나는 (인간이) 의자에 앉아있다”; “자동차가 도로에있다”; “키보드에 입력하고 있습니다”; “커피 머신이 물을 끓인다”, “텍스트가 터미널 창에 표시됩니다.”
동사는 2가 (때로는 “나에게 꽃을 줬다”와 같이 3가) 동사로 생각되는데 여기서 동사는 두 개의 객체에서 작동하여 결과 / 동작을 생성하는 동작 (관계)입니다. 포커스 동작을하고, 두 개의 (또는 세) 문법] 개체 동등한 중요성을 갖는다.
OOP와는 대조적으로 먼저 하나의 오브젝트 (명사)를 찾아서 다른 오브젝트에 대한 조치를 수행하도록 지시해야합니다. 사고 방식은 명사에서 작동하는 동작 / 동사에서 명사에서 작동하는 명사로 이동합니다. 마치 마치 “단말기 창에 텍스트가 표시되는 것과 같이”수동적이거나 재귀적인 목소리로 모든 것이 말하는 것처럼 말입니다. 또는 “텍스트가 터미널 창에 그려집니다”.
초점이 명사로 이동되었을뿐만 아니라 명사 중 하나 (문법 주제라고 함)에 다른 명사 (문법적 대상)보다 “중요도”가 높아집니다. 따라서 terminalWindow.show (someText) 또는 someText.show (terminalWindow) 중 어느 것을 말할 것인지 결정해야합니다. 그러나 실제로 show (terminalWindow, someText)를 의미 할 때 운영상의 결과가없는 사소한 결정을 내리는 사람들에게 왜 부담이됩니까? [결과는 운영상 미미합니다. 두 경우 모두 텍스트가 터미널 창에 표시됩니다. 그러나 클래스 계층 구조 디자인에서 매우 심각 할 수 있으며 “잘못된”선택은 코드를 복잡하고 유지하기 어려울 수 있습니다.]
그러므로 나는 OOP (class-based, single-dispatch)를하는 주류 방식은 비 자연적이며 인간이 세상에 대해 어떻게 생각하는지에 맞지 않기 때문에 어렵다고 주장한다. CLOS의 일반적인 방법은 내가 생각하는 방식에 더 가깝지만 아쉽게도 이것은 널리 퍼진 접근법이 아닙니다.
이러한 문제를 감안할 때 현재 OOP를 수행하는 주류 방식이 인기를 얻은 이유는 무엇입니까? 그리고 그것을 막기 위해 무엇을 할 수 있습니까?
답변
일부 문제에는 OOP가 부자연 스럽습니다. 절차 적입니다. 기능적입니다. OOP에는 실제로 어려운 것처럼 보이는 두 가지 문제가 있다고 생각합니다.
-
어떤 사람들은 프로그램을하는 유일한 방법 인 것처럼 행동하고 다른 모든 패러다임은 잘못되었습니다. IMHO는 모두 다중 패러다임 언어를 사용해야하며 현재 진행중인 하위 문제에 가장 적합한 패러다임을 선택해야합니다. 코드의 일부 부분에는 OO 스타일이 있습니다. 일부는 작동합니다. 일부는 직선형 절차 스타일을 갖습니다. 경험을 통해 패러다임이 무엇에 가장 적합한 지 분명해집니다.
에이. OO는 일반적으로 동작하는 상태와 강력하게 연결된 동작이있을 때 가장 적합하며 상태의 정확한 특성은 구현 세부 사항이지만 해당 상태의 존재를 쉽게 추상화 할 수는 없습니다. 예 : 컬렉션 클래스
비. 절차는 특정 데이터와 강력하게 연결되지 않은 동작이 많은 경우에 가장 좋습니다. 예를 들어, 원시 데이터 유형에서 작동 할 수 있습니다. 여기서 행동과 데이터를 별도의 엔티티로 생각하는 것이 가장 쉽습니다. 예 : 숫자 코드
씨. 어떤 상태라도 존재하면 쉽게 추상화 할 수있는 구현 세부 사항이되도록 선언적으로 작성하기 쉬운 것이있을 때 기능이 가장 좋습니다. 예 : 병렬 처리를 매핑 / 축소합니다.
-
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에 익숙해지는 데 어려움이 있다면, 개체가 서로 어떻게 조화를 이루고 책임이 어떻게 배열되는지에 대해 더 많이 생각하는 것이 좋습니다. 아직 디자인 패턴에 대해 읽지 않았다면 이미 읽은 패턴을 보았지만 이름을 지정하면 나무뿐만 아니라 스탠드, 경찰, 덤불, 숲, 숲, 숲, 결국 숲.