내가 알 수있는 한, OOP 교육, 언어 및 도구에 수백만 또는 수십억을 소비했지만 OOP는 개발자 생산성이나 소프트웨어 안정성을 개선하지 않았거나 개발 비용을 절감하지도 않았습니다. 엄격한 의미에서 OOP를 사용하는 사람은 거의 없습니다 (LSP와 같은 원칙을 준수하거나 이해하는 사람은 거의 없음). 사람들이 문제 영역을 모델링하기 위해 취하는 접근 방식에는 일관성이나 일관성이 거의없는 것 같습니다. 너무나도,이 계급은 단순히 구문 설탕으로 만 사용됩니다. 레코드 유형에 대한 함수를 자체의 작은 네임 스페이스에 넣습니다.
다양한 응용 프로그램을 위해 많은 양의 코드를 작성했습니다. 실제 대체 가능한 서브 타이핑이 응용 프로그램에서 중요한 역할을하는 곳이 있었지만, 이들은 상당히 예외적이었습니다. 일반적으로, “재사용”에 대해 이야기하기 위해 많은 립 서비스가 제공되지만, 실제로는 코드가 원하는 것을 정확하게 수행하지 않으면 비용 효율적인 “재사용”이 거의 없다는 것입니다. 클래스를 올바른 방식 으로 확장 할 수 있도록 설계하는 것은 극히 어렵 기 때문에 확장 비용은 일반적으로 너무 커서 “재사용”은 가치가 없습니다.
많은 점에서 이것은 놀라운 일이 아닙니다. 실제 세계는 “OO”가 아니며, OO에 내재 된 개념, 즉 우리가 클래스 분류법으로 물건을 모델링 할 수 있다는 아이디어는 매우 근본적으로 결함이있는 것 같습니다 (테이블, 나무 그루터기, 자동차 보닛에 앉을 수 있음) , 누군가의 무릎-의자 중 하나는 아닙니다). 우리가 더 추상적 인 영역으로 이동하더라도 OO 모델링은 종종 어렵고, 반 직관적이고, 궁극적으로 도움이되지 않습니다 (원형 / 천장 또는 사각형 / 사각형의 고전적인 예를 고려하십시오).
그래서 내가 여기서 무엇을 놓치고 있습니까? OOP의 가치는 어디에 있습니까? 왜 모든 시간과 돈이 소프트웨어를 개선하지 못한 것입니까?
답변
객체 지향이 사람들이 세상에 대해 더 자연스럽게 생각할 수 있다는 것을 암시하는 경험적 증거는 없습니다. 프로그래밍 심리학 분야에서는 OO가 다른 접근법보다 적합하지 않다는 것을 보여주는 연구가 있습니다.
객체 지향 표현은 보편적으로 더 유용하거나 덜 사용 가능한 것으로 보이지 않습니다.
단순히 OO 방법을 채택하는 것만으로는 충분하지 않으며 개발자가 그러한 방법을 사용해야하므로 개발자 생산성과 개발 된 시스템의 품질에 부정적인 영향을 줄 수 있습니다.
이 기사는 2000 년 10 월 ACM의 커뮤니케이션에서 “OO 표현의 유용성”에서 발췌 한 것이다.이 기사는 주로 OO를 프로세스 지향 접근법과 비교한다. OO 방법을 “생각”하는 사람들에 대한 많은 연구가 있습니다 (Int. J. of Human-Computer Studies 2001, Issue 54 또는 Human-Computer Interaction 1995, vol.10은 OO 연구에 대한 전체 주제를 가짐), 그리고 내가 읽은 바에 따르면, 전통적인 절차 적 접근 방식보다 OO 접근 방식에 더 잘 어울리는 자연 스러움을 나타내는 것은 없습니다.
답변
실제 세계는 “OO”가 아니며, OO에 내재 된 개념 (일부 분류법으로 물건을 모델링 할 수 있음)은 근본적으로 결함이있는 것으로 보입니다.
이것이 사실이며 다른 사람들에 의해 관찰되었지만 (STL의 발명가 Stepanov를 복용하십시오) 나머지는 말도 안됩니다. OOP에 결함이있을 수 있으며 확실히 은색 총알은 아니지만 대규모 응용 프로그램은 종속성을 줄이는 좋은 방법이기 때문에 훨씬 간단합니다. 물론 이것은 “좋은”OOP 설계에만 해당됩니다. 거친 디자인은 어떤 이점도 제공하지 않습니다. 그러나 좋은 분리 된 설계는 OOP를 사용하여 잘 모델링 할 수 있으며 다른 기술을 사용하지 않을 수도 있습니다.
훨씬 더 보편적 인 모델 이 있지만 ( Haskell의 유형 모델 을 염두에 두어야 함) 이러한 모델 은 종종 더 복잡하고 효율적으로 구현하기도 어렵습니다. OOP는 극한의 절충점입니다.
답변
OOP는 재사용 가능한 클래스를 만드는 것이 아니라 사용 가능한 클래스를 만드는 것입니다.
답변
너무나도,이 계급은 단순히 구문 설탕으로 만 사용됩니다. 레코드 유형에 대한 함수를 자체의 작은 네임 스페이스에 넣습니다.
네, 이것도 너무 널리 퍼져 있습니다. 이것은 객체 지향 프로그래밍이 아닙니다. 객체 기반 프로그래밍 및 데이터 중심 프로그래밍입니다. OO 언어를 다루는 10 년 동안 사람들이 주로 객체 기반 프로그래밍을하는 것을 봅니다. OBP는 본질적으로 두 단어 중 최악의 단어가 있기 때문에 IMHO를 매우 빠르게 분류합니다. 1) 입증 된 구조적 프로그래밍 방법론을 준수하지 않는 절차 적 프로그래밍 및 2) 입증 된 OOP 방법론을 준수하지 않는 OOP
OOP 제대로 된 것은 아름다운 것입니다. 그것은 매우 어려운 문제를 해결하기 쉽고, 시작되지 않은 (거의 들리지 않게), 거의 마술처럼 보일 수 있습니다. 즉, OOP는 프로그래밍 방법론 도구 상자의 도구 중 하나 일뿐입니다. 모든 방법론이 끝이 아닙니다. 대규모 비즈니스 애플리케이션에 적합합니다.
OOP 언어로 작업하는 대부분의 개발자는 일상적으로 사용하는 프레임 워크 및 유형에서 바로 수행 된 OOP의 예를 활용하고 있지만이를 잘 모르고 있습니다. 다음은 매우 간단한 예입니다. ADO.NET, Hibernate / NHibernate, 로깅 프레임 워크, 다양한 언어 콜렉션 유형, ASP.NET 스택, JSP 스택 등 … 이들은 코드베이스에서 OOP에 크게 의존하는 모든 것입니다.
답변
재사용은 OOP의 목표 나 그 문제에 대한 다른 패러다임이되어서는 안됩니다.
재사용은 좋은 디자인과 적절한 추상화 수준의 부작용입니다. 코드는 유용한 무언가를 수행함으로써 재사용을 달성하지만 유연성이 없어 질만큼 많이하지는 않습니다. 코드가 OO인지 아닌지는 중요하지 않습니다. 우리는 작동하는 것을 재사용하고 사소하지 않습니다. 실용주의입니다.
상속을 통해 재사용 할 수있는 새로운 방법으로 OO를 생각하는 것은 근본적으로 결함이 있습니다. 알다시피 LSP 위반은 많습니다. 대신, OO는 문제 영역의 복잡성을 관리하는 방법으로 올바르게 생각됩니다. 목표는 시간이 지남에 따라 시스템의 유지 관리입니다. 이를 달성하기위한 기본 도구는 개인 인터페이스와 공용 인터페이스를 분리하는 것입니다. 이를 통해 코드 검토가 아니라 컴파일러에서 “… 만 사용하여 수정해야합니다”와 같은 규칙을 사용할 수 있습니다.
이것을 사용하면 매우 복잡한 시스템을 만들고 유지 관리 할 수 있습니다. 그 안에 많은 가치가 있으며 다른 패러다임에서는 쉽게 할 수 없습니다.
답변
종교에 비추어 보았지만 현대 OOP의 상태에 대해 지나치게 어두운 그림을 그리는 중이라고 말하고 싶습니다. 나는 그것이 실제로 있다고 주장 했다 등, 비용 절감 대규모 소프트웨어 프로젝트 관리하게합니다. 그렇다고 소프트웨어 혼란의 근본적인 문제가 해결되었다는 의미는 아니며 일반 개발자가 OOP 전문가라는 의미는 아닙니다. 그러나 기능을 객체 구성 요소로 모듈화하면 세계의 스파게티 코드 양이 확실히 줄어 들었습니다.
아름답게 재사용 할 수 있고 계산할 수없는 시간과 비용을 절약 한 수십 개의 도서관이 내 머리 꼭대기에 있다고 생각할 수 있습니다.
그러나 OOP가 시간 낭비 인 한, 그것은 언어 별 OOP 매핑을 배우는 가파른 학습 곡선으로 인해 프로그래머 교육이 부족하기 때문이라고 말하고 싶습니다. 어떤 사람들은 OOP를 “얻고”다른 사람들은 결코하지 않을 것입니다.
답변
나는 잘 알려진 두 가지 예를 들기 위해 불투명 한 컨텍스트 객체 (Win32의 핸들, C의 FILE *)를 사용한다고 생각합니다. 그것보다 훨씬 더 캡슐화 된) 절차 코드에서도 발견됩니다. 나는 이것이 OOP에 특정한 방법을보기 위해 고심하고 있습니다.
HANDLEs (및 나머지 WinAPI) 는 OOP입니다! C는 OOP를 잘 지원하지 않으므로 특별한 구문은 없지만 동일한 개념을 사용하지 않는다는 의미는 아닙니다. WinAPI는 모든 의미에서 객체 지향 프레임 워크입니다.
이것은 OOP 또는 대안 기술과 관련된 모든 단일 논의에서 문제가된다. 정의에 대해 아무도 명확하지 않으며, 모두가 다른 것에 대해 이야기하고 있으므로 합의에 도달 할 수 없다. 나에게 시간 낭비처럼 보인다.
