“OOP가 상태를 숨 깁니다”란 무엇입니까? [닫은]

에서 cat-v.org에 많은 안티 OOP의 호언 장담 한 I 조 암스트롱에 의해 통로 중 하나가 다음되었으며, OOP 모델에 대해 몇 가지 이의를 제기 발견

이의 제기 4 – 객체의 비공개 상태

국가는 모든 악의 근원입니다. 특히 부작용이있는 기능은 피해야합니다.

프로그래밍 언어의 상태는 바람직하지 않지만, 실제 상태는 풍부합니다. 은행 계좌 상태에 관심이 많으며 은행에서 돈을 입금하거나 인출 할 때 은행 계좌 상태가 올바르게 업데이트 될 것으로 기대합니다.

현실 세계에 국가가 존재한다면 프로그래밍 언어는 국가를 다루기 위해 어떤 시설을 제공해야합니까?

OOPL은“프로그래머로부터 상태를 숨 깁니다”라고 말합니다. 상태는 액세스 기능을 통해서만 숨겨지고 표시됩니다. 기존의 프로그래밍 언어 (C, Pascal)는 상태 변수의 가시성이 언어의 범위 규칙에 의해 제어된다고 말합니다. 순수한 선언적 언어는 국가가 없다고 말합니다. 시스템의 전역 상태는 모든 기능으로 수행되며 모든 기능에서 나옵니다. 모나드 (FPL 용) 및 DCG (논리 언어)와 같은 메커니즘은 프로그래머에서 상태를 숨겨서 "상태가 중요하지 않은 것처럼"프로그래밍 할 수 있지만 필요한 경우 시스템 상태에 완전히 액세스 할 수 있습니다.

OOPL이 선택한“프로그래머에서 상태 숨기기”옵션이 더 나쁜 선택입니다. 국가를 밝히고 국가의 성가신 것을 최소화하는 방법을 찾으려고 노력하는 대신, 국가를 숨 깁니다.

이것이 정확히 무엇을 의미합니까? 나는 거의 OOP 수준이 낮거나 절차 적 경험이 거의 없기 때문에 아마도 내가 익숙하지 않은 것을 설명 할 것입니다. 그리고보다 현대적인 관점에서 볼 때, 객체 지향 히스테리의 대부분이 (적어도 내가 알 수있는 한) 전달되었으므로 통과가 얼마나 정확하고 관련이 있다고 생각합니까?

당신의 도움을 주셔서 감사합니다.

이것이 정확히 무엇을 의미합니까?

이와 관련하여 OOP는 프로그램을 프로그래머로부터 숨기고 (누설 된) 접근 자 메소드를 통해 계속 표시함으로써 프로그램의 상태를 모호하게합니다. 논쟁은 국가를 가릴수록 일하기가 더 어려워지고 더 많은 버그를 초래한다는 것입니다.

통과가 얼마나 정확하고 관련이 있다고 생각하십니까?

나는 그것이 관련이 있지만 잘못 지시되었다고 생각합니다. 만약 당신의 클래스가 그것의 상태 개념을 외부 세계로 누설한다면 절대적으로 문제가 있습니다. 만약 당신의 클래스가 외부 세계에 의해 조작되어야 할 때 상태를 모호하게하려는 경우에는 절대적으로 문제가 있습니다. 그러나 OOP 전체가 실패하지는 않지만 클래스의 개별 디자인으로 인해 실패합니다. 상태 자체를 숨기는 것이 문제라고 말하고 싶지는 않습니다. 모나드는 항상 함수형 프로그래밍 에서이 작업을 수행합니다.

최상의 경우, OOP는 함수형 프로그래밍과 절차의 최상의 조합처럼 작동합니다. 사람들은 클래스의 불변을 보호하는 데 사용되는 개인 상태가 숨겨져 있지만 자유가 있기 때문에 "상태가 중요하지 않은 것처럼"클래스를 사용할 수 있습니다. 세부 사항을 추상화하는 클래스의 잘 정의 된 공개 상태를 사용합니다.

OOP가 사람들이이 최고의 사례를 달성하기 어렵게합니까? 혹시. "자바 학교"와 전체 Shape / Circle / Rectangle 또는 Car에는 바퀴를 가르치는 바퀴 학교가 있습니다. OO는 아마도 접근 자체보다 더 많은 비난을받을 것입니다. 현대의 OOP는 함수형 프로그래밍에서 많은 부분을 차지하여 불변의 객체와 순수한 함수를 장려하면서 상속을 권장하지 않고 잘 작동하는 클래스를 쉽게 디자인 할 수 있도록합니다.

명확한 "소유자"가없는 변경 가능한 상태 조각이 있으면 시스템에 대한 추론이 어려울 수 있습니다. 즉, 객체가 변경 가능한 상태를 가져서는 안된다는 의미는 아니지만 변경 가능한 상태를 갖는 객체는 소유권이 명확하지 않은 방식으로 사용되어서는 안되며 반대로 소유권을 추적하지 않고 자유롭게 전달해야하는 객체는 사용해야합니다. 불변이다

실제로, 효율적인 프로그래밍은 종종 일부 객체가 변경 가능한 상태를 갖도록 요구합니다. 그러나 이러한 상태는 공유되지 않은 작업자 객체 로 제한되어야 합니다. .NET 의 IEnumerable/ IEnumerator인터페이스를 고려하십시오 . 컬렉션이를 구현 IEnumerable하면 항목을 한 번에 하나씩 읽을 수 있습니다. 컬렉션을 읽는 실제 프로세스는 종종 어떤 항목이 읽혔는지 (변경 가능한 상태)를 추적해야하지만 이러한 상태는의 구현에 포함되지 않습니다 IEnumerable. 대신, 컬렉션에서 항목을 읽을 수 있도록 충분한 상태를 구현 하고 포함 하는 객체를 반환하는 IEnumerable메소드를 제공합니다 . 객체가 그러한 상태를 포함한다는 사실은 문제가되지 않습니다.GetEnumeratorIEnumerator객체가 구현하는 경우 IEnumerator공유되지 않습니다 .

대부분의 경우 가장 좋은 패턴은 자유롭게 공유되지만 수정되지 않는 개체 (적어도 공유 한 후에는 안 됨)와 소유자가 분명하고 해당 소유자가 자유롭게 수정할 수있는 개체를 혼합하여 사용하는 것입니다. 하지만 다른 사람과 공유되지 않습니다.

질문에 대답하는 것 이상으로 위험에 처할 때 OOP 아이디어에 결함이 있음을 쉽게 알 수 있지만 아이디어의 힘이 남용 될 수있는 능력에 반영된다고 생각합니다.

결국, 모든 사람들은 자신이 가장 좋아하는 언어를 가지고 있으며, "매우 강력하다"는 용어를 사용하여 실제로 좋아 한다는 것을 의미 합니다 . 그러나 전산 보편성에 대한 놀라운 점은 언어가 아무리 영광 스럽더라도 정말 강력하면 어셈블리 언어를 시뮬레이션 할 수 있다는 것입니다. 그리고 가능하다면 누군가 그렇게 할 것입니다. (조립 언어에 문제가있는 것은 아닙니다.)

OOP 밴드 왜건에 대한 나의 개인적인 느낌은 이것이 소프트웨어 공학 / 컴퓨터 과학에 대한 사람들의 교육을 방해한다는 것입니다. 그들은 데이터 구조에 관한 모든 것을 생각하는 수준에서 스턴트됩니다. 클래스, 상속, 컨테이너, 이터레이터, 해시 맵, 속성, 상태 숨기기 등-데이터 구조에 관한 모든 것-더 많은 장점.

저는 개인적으로 사람들이 언어 적으로 문제를보고 문제를 해결하는 법을 배우는 다음 단계를보고 싶습니다. 도메인 별 언어의 개념을 이해하는 경우,이를 쉽게 만들고 생성을 문제 해결의 필수 부분으로 만드는 방법. 데이터 구조 가 언어 라고 말하는 것은 올바르지 않습니다 . 사람들은 그러한 언어 디자인 기술을 가지고 있어야하므로 언어를 능숙하게 다루지 않습니다.

다음 단계로 인공 지능이 활기를 되찾고 싶습니다. 프로그래머가 바이트 및 스레드와 가상 함수 테이블 및 CUDA를 넘어서 기계를 추론하고 배우고 생성하는 방법으로 이동하고 싶습니다. 나는 이것이 필드의 작은 구석에서 아주 멀리 발전했지만 아무리 넓게도 갈 수 없다는 것을 알고 있습니다.

접근성은 OOP의 기능이 아니며 Java 및 Microsoft dotNET과 같은 구현에만 해당됩니다. OOP를 정의하는 주요 기능은 다형성입니다.

어쨌든 객체 상태를 숨기면 의미있는 API를 만들 수있는 방법이 없습니다. 프레젠테이션은 실제 OOP의 핵심 구성 요소입니다. 의견이 맞지 않는 사람들은 소프트웨어 산업에 대한 비이성적 인 적대감을 가지고 있기 때문에 본인의 견해와는 관련이 없습니다.

링크 한 웹 사이트와 같은 웹 사이트는 새로운 기술에 대한 매우 엄격한 생각과 비판으로 유명합니다. 어떤 사람들은 그것을 얻지 못합니다.