OOP의 요점은 무엇입니까?

내가 알 수있는 한, 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 또는 대안 기술과 관련된 모든 단일 논의에서 문제가된다. 정의에 대해 아무도 명확하지 않으며, 모두가 다른 것에 대해 이야기하고 있으므로 합의에 도달 할 수 없다. 나에게 시간 낭비처럼 보인다.

프로그래밍 패러다임 .. 필사자 만이 문제를 더 작고 실행 가능한 부분으로 쉽게 나눌 수 있도록 설계되었습니다.

유용하지 않다면 사용하지 마십시오. 교육비를 지불하지 말고 행복하십시오.

반면에 나는 유용하다고 생각하므로 :)

직접적인 절차 적 프로그래밍과 관련하여 OOP의 첫 번째 기본 원칙은 정보 숨기기 및 캡슐화 개념입니다. 이 아이디어는 인터페이스를 구현에서 분리하는 클래스 의 개념으로 이어집니다 . 이것들은 매우 중요한 개념이며 프로그램 디자인에 대해 다른 방식으로 생각하고 더 나은 방식으로 생각할 수있는 프레임 워크를 구축하기위한 기초입니다. 이러한 속성에 대해 실제로 논쟁 할 수는 없습니다. 트레이드 오프가 없으며 항상 물건을 변조하는 더 확실한 방법입니다.

상속과 다형성을 포함한 OOP의 다른 측면들도 중요하지만, 다른 사람들이 언급했듯이, 그것들은 일반적으로 과도하게 사용됩니다. ie : 때때로 사람들은 상속이나 다형성을 사용해야하기 때문에 할 수 없기 때문에 사용합니다. 그것들은 강력한 개념이며 매우 유용하지만, 현명하게 사용해야하며 OOP의 자동 우승 이점이 아닙니다.

재사용에 상대적. 재사용이 OOP에 대해 초과 판매 된 것에 동의합니다. 이는 일반적으로보다 원시적 / 일반 클래스의 잘 정의 된 객체의 부작용이며 캡슐화 및 정보 숨기기 개념의 직접적인 결과입니다. 잘 정의 된 클래스의 인터페이스는 단순히 더 명확하고 다소 자체 문서화되므로 재사용하기가 더 쉽습니다.

OOP의 문제점은 과매도되었다는 것입니다.

Alan Kay가 처음에 생각한 것처럼 원시 데이터와 전 세계 루틴을 사용하는 이전 관행에 대한 훌륭한 대안이었습니다.

그런 다음 일부 관리 컨설턴트 유형이 소프트웨어의 메신저로 팔아 넘기면서 학계와 산업이 뒤죽박죽이되었습니다.

이제 함수형 프로그래밍과 같은 다른 좋은 아이디어가 과매도가 된 후에는 엉망진창이되었습니다.

그래서 어떻게 다르게할까요? 충분히, 나는 이것에 관한 책을 썼습니다. (그것은 절판입니다 - 나는 한 푼도하지 않는다, 그러나 당신은 여전히 사본을 얻을 수 있습니다.) 아마존

건설적인 대답은 프로그래밍을 실제 환경에서 모델링하는 것이 아니라 요구 사항을 인코딩하는 방식으로 보는 것입니다.

이는 매우 다르며 정보 이론 (모든 사람이 이해할 수있는 수준)을 기반으로합니다. 프로그래밍은 언어를 정의하는 과정으로 간주 될 수 있으며,이를 잘 익히려면 훌륭한 프로그래밍이 필수적입니다.

DSL (Domain-Specific-languages) 개념을 향상시킵니다. DRY에 중점을 둡니다 (반복하지 마십시오). 코드 생성에 큰 도움이됩니다. 따라서 최신 응용 프로그램에 비해 데이터 구조가 훨씬 적은 소프트웨어가 만들어집니다.

앞으로 나아가는 길은 창의성에 있으며, 잘 받아 들여진 아이디어조차도 의문의 여지가 있다는 생각을 다시 활력을 불어 넣으려고합니다.

핸들 (및 나머지 WinAPI)은 OOP입니다!

그래도 그래요? 상속 할 수없고, 확실히 대체 할 수 없으며, 잘 정의 된 클래스가 부족합니다. "OOP"가 부족하다고 생각합니다.

WinAPI를 사용하여 창을 만든 적이 있습니까? 그런 다음 클래스를 정의하고 ( RegisterClass), 인스턴스를 생성하고 ( CreateWindow), 가상 메소드 ( WndProc) 및 기본 클래스 메소드 ( DefWindowProc) 등을 호출 한다는 것을 알아야합니다 . WinAPI는 SmallTalk OOP의 명명법을 사용하여 "메시지"(윈도우 메시지) 메소드를 호출합니다.

핸들은 상속 할 수 없지만 finalJava에는 있습니다. 그들은이 클래스를 부족하지 않습니다 있는 클래스에 대한 자리 표시 자 : 그 무엇 단어 "핸들"을 의미합니다. MFC 또는 .NET WinForms와 같은 아키텍처를 살펴보면 구문을 제외하고 WinAPI와 크게 다르지 않다는 것이 즉시 명백합니다.

예, OOP가 모든 문제를 해결하지 못했습니다. 죄송합니다. 그러나 우리는 이러한 모든 문제를 해결할 SOA를 연구하고 있습니다.

OOP는 GUI "위젯"과 같은 내부 컴퓨터 구조를 프로그래밍하는 데 적합합니다. 예를 들어 SelectList 및 TextBox는 "move"및 "resize"와 같은 일반적인 방법을 가진 Item의 하위 유형일 수 있습니다.

문제는 우리 중 90 %가 송장, 직원, 직업, 주문과 같은 비즈니스 개념으로 작업하는 비즈니스 세계에서 일한다는 것입니다. 다음은 하지 않는 비즈니스 리엔지니어링에 등등에 따라 "객체"더 성운 때문에, OOP에 잘 변경 될 수를 빌려 준다.

최악의 경우는 SQL 데이터베이스에 대한 OO "강화"를 포함하여 OO가 데이터베이스에 열성적으로 적용되는 경우입니다. 데이터베이스 멍청한 놈은 새로운 것을 사용하여 올바른 방법으로해야한다고 가정하는 경우를 제외하고는 무시됩니다.

필자가 경험 한 코드와 디자인을 검토 한 경험에서 많은 개발자들이 객체 지향 모델 을 제대로 개념화하지 않았기 때문에 OOP의 가치가 완전히 실현 되지 않았습니다 . 따라서 그들은 OO 디자인으로 프로그래밍하지 않으며, 종종 클래스를 꽤 평평한 디자인으로 만드는 하향식 절차 코드를 계속 작성합니다 . (처음에 "디자인"이라고 부를 수 있다면)

비즈니스 요구에 맞게 상속 계층 구조를 올바르게 설계 할뿐 아니라 추상 클래스 나 인터페이스가 무엇인지 아는 동료가 거의 없다는 것을 관찰하는 것은 무섭습니다.

그러나 좋은 OO 디자인이 존재하면 코드를 읽고 자연스럽게 직관적 인 구성 요소 / 클래스에 코드가 들어가는 것을 보는 것은 기쁨입니다. 나는 항상 회사의 다양한 부서와 직원 작업을 디자인하는 것과 같은 시스템 아키텍처와 디자인을 인식 해 왔습니다. 모두 거대한 계획에서 특정 작업을 수행하여 조직 / 시스템을 발전시키는 데 필요한 시너지를 내야합니다.

물론 불행히도 매우 드 rare니다 . 세계에서 아름답게 디자인 된 것과 끔찍하게 디자인 된 물리적 객체의 비율과 마찬가지로 소프트웨어 엔지니어링과 디자인에 대해서도 마찬가지입니다. 좋은 도구를 마음대로 사용한다고해서 반드시 모범 사례와 결과를 얻을 수있는 것은 아닙니다.

보닛, 무릎 또는 나무는 의자가 아니지만 모두 ISittable 일 수 있습니다.

그 현실 세계는 사물이라고 생각합니다

당신은?

인보이스에는 어떤 방법이 있습니까? 아 잠깐만 그것은 스스로를 지불 할 수없고, 스스로를 보낼 수 없으며, 공급 업체가 실제로 배달 한 품목과 비교할 수 없습니다. 전혀 방법이 없습니다. 완전히 비활성이며 작동하지 않습니다. 객체가 아닌 레코드 유형 (원하는 경우 구조체)입니다.

당신이 언급 한 다른 것들도 마찬가지입니다.

무언가가 실제이기 때문에 단어의 의미에서 대상이되지 않습니다. OO 객체는 고유 한 조건으로 작동 할 수있는 상태와 동작의 고유 한 결합입니다. 그것은 현실 세계에 풍부한 것이 아닙니다.

지난 9 년 동안 OO 코드를 작성해 왔습니다. 메시징을 사용하는 것 외에는 다른 접근법을 상상하기가 어렵습니다. CodingTheWheel의 말과 완전히 일치하는 주요 이점은 모듈화입니다. OO는 자연스럽게 깔끔한 인터페이스와 명확한 책임을 가진 모듈 식 구성 요소 (예를 들어, 명확하게 분리 된 느슨하게 결합 된 응집력있는 코드)로 응용 프로그램을 구성하도록 이끌어줍니다.

OO가 고장 나는 곳은 사람들이 깊이 중첩 된 클래스 계층 구조를 만들 때입니다. 이것은 복잡성을 초래할 수 있습니다. 그러나 공통된 가상 성을 기본 클래스로 고려한 다음 다른 하위 클래스에서 재사용하는 것은 매우 우아한 일입니다. IMHO!

처음에는 관측치가 다소 조잡합니다. 나는 소프트웨어 생산성에 대한 수치가 없으며 그것이 올라가지 않을 것이라고 믿을만한 충분한 이유가 없다. 또한, OO를 남용하는 사람들이 많으므로 땅콩 버터 이후 OO가 가장 큰 경우에도 OO를 잘 사용하면 생산성 향상이 반드시 필요한 것은 아닙니다. 결국, 무능한 뇌 외과 의사는 그 어느 누구보다 나빠질 가능성이 있지만 유능한 뇌 외과 의사는 귀중 할 수 있습니다.

즉, OO는 절차 코드가 데이터에서 작동하는 대신 절차 코드를 데이터에 첨부하는 방식으로 사물을 배열하는 다른 방법입니다. OO 접근 방식이 더 자연스러운 경우가 있기 때문에 이는 최소한 자체적으로 작은 승리가되어야합니다. 결국 C ++에서 절차 적 API를 작성하는 것을 막을 수있는 것은 없으므로 객체를 제공하는 옵션이 언어를보다 다양하게 만듭니다.

또한 OO가하는 일이 아주 많습니다. 기존 코드가 변경없이 새 코드를 자동으로 호출 할 수 있습니다. 절차 적으로 사물을 관리하는 코드가 있고 이전 코드와 유사하지만 동일하지 않은 새로운 종류의 항목을 추가하는 경우 절차 코드를 변경해야합니다. OO 시스템에서는 기능을 상속하고 좋아하는 것을 변경하며 다형성으로 인해 새 코드가 자동으로 사용됩니다. 이것은 변화의 지역성을 증가 시키며 이는 좋은 일입니다.

단점은 좋은 OO가 무료가 아니라는 것입니다. 제대로 배우려면 시간과 노력이 필요합니다. 중요한 유행어이기 때문에, 그것을하기 위해 그것을 잘못하는 많은 사람들과 제품들이 있습니다. 좋은 절차 적 API보다 좋은 클래스 인터페이스를 디자인하는 것은 쉽지 않으며 모든 종류의 만들기 쉬운 오류 (심층 클래스 계층 구조와 같은)가 있습니다.

일반적으로 더 나은 것은 아니지만 다른 종류의 도구로 생각하십시오. 스크루 드라이버 외에 망치가 있다고합니다. 아마도 우리는 나사를 망치는 데 사용할 렌치를 아는 것으로 소프트웨어 엔지니어링의 실습에서 벗어날 것입니다.

@Sean

그러나 공통된 가상 성을 기본 클래스로 고려한 다음 다른 하위 클래스에서 재사용하는 것은 매우 우아한 일입니다. IMHO!

그러나 "절차"개발자들은 어쨌든 수십 년 동안 그 일을 해왔습니다. 구문과 용어는 다를 수 있지만 효과는 동일합니다. "기본 클래스에서 공통 기능 재사용"보다 OOP에 더 많은 것이 있으며, OOP로 설명하기가 어렵다고 말할 수도 있습니다. 다른 코드의 비트에서 동일한 함수를 호출하는 것은 하위 프로 시저 자체만큼 오래된 기술입니다.

K

OOP에 결함이있을 수 있으며 확실히 은총 알은 아니지만 대규모 응용 프로그램은 종속성을 줄이는 좋은 방법이기 때문에 훨씬 간단합니다.

이것이 교리입니다. 구식 절차 적 프로그래밍보다 OOP가 훨씬 더 나은 점을 보지 못했습니다. 프로 시저 호출을 할 때마다 구현의 세부 사항에서 자신을 격리시킵니다.

나에게는 OOP 구문 자체에 많은 가치가 있습니다. 실제 사물 또는 데이터 구조를 나타내는 객체를 사용하는 것은 동일한 데이터로 동일한 일을하기 위해 여러 가지 플랫 (또는 "플로팅") 함수를 사용하는 것보다 훨씬 유용합니다. 좋은 OOP를 가진 것들에는 특정한 자연적인 흐름이 있으며, 장기적으로 읽고 쓰고 유지하는 것이 더 합리적입니다.

청구서가 실제로 자체적으로 수행 할 수있는 기능을 가진 "객체"가 아니더라도 상관 없습니다. 개체 인스턴스는 실제로 어떤 유형의 데이터가 있는지 알 필요없이 데이터에 대해 기능을 수행하기 위해 존재할 수 있습니다. "invoice.toJson ()"함수는 "invoice"데이터의 종류를 알 필요없이 성공적으로 호출 할 수 있습니다. 결과는 데이터베이스, XML, CSV 또는 다른 JSON 객체에서 온 것이 든 Json이됩니다. . 절차 함수를 사용하면 갑자기 데이터에 대해 더 많이 알고 "xmlToJson ()", "csvToJson ()", "dbToJson ()"등과 같은 함수로 끝납니다. 결국에는 완전한 혼란과 기본 데이터 유형을 변경하면 엄청난 두통이 발생합니다.

OOP의 요점은 실제 구현을 추상화하여 숨기는 것입니다. 이 목표를 달성하려면 공용 인터페이스를 작성해야합니다. 공용 인터페이스를 작성하면서 작업을보다 쉽게하고 DRY를 유지하려면 추상 클래스, 상속, 다형성 및 디자인 패턴과 같은 개념을 사용해야합니다.

따라서 OOP의 가장 중요한 목표는 향후 코드 유지 관리 및 변경을보다 쉽게 ​​만드는 것입니다. 그러나 그 이상으로도 절차 코드가 결코 할 수없는 방식으로 올바르게 수행하면 일을 크게 단순화 할 수 있습니다. "실제 세계"와 일치하지 않더라도 문제가되지 않습니다. 코드를 사용한 프로그래밍은 실제 개체와 상호 작용하지 않습니다. OOP는 작업을보다 쉽고 빠르게 수행 할 수있는 도구 일뿐입니다. 하루 하루 갈 것입니다.

짤방 백업 봇

그러나 OOP가 시간 낭비 인 한, 그것은 언어 별 OOP 매핑을 배우는 가파른 학습 곡선으로 인해 프로그래머 교육이 부족하기 때문이라고 말하고 싶습니다. 어떤 사람들은 OOP를 "얻고"다른 사람들은 결코하지 않을 것입니다.

그래도 정말 놀랍다면 몰라요. 기술적으로 건전한 접근 방식 (LSP가 명백한 것임) 을 사용하기 가 어렵다고 생각합니다. 하지만, 우리가 그러한 접근법을 사용하지 않으면 코드가 부서지기 쉽고 확장 할 수 없게됩니다 (더 이상 추론을 할 수 없기 때문에). 그리고 OOP가 우리에게 사람들이 그것을 선택하지 않는 것을 놀라게 만드는 반 직관적 인 결과라고 생각합니다.

더 중요한 것은 소프트웨어가 이미 기본적으로 인간이 신뢰할 수 있고 정확하게 작성하기에 너무 어렵 기 때문에 지속적으로 잘못 학습되고 배우기 어려운 기술을 옹호해야 하는가? 이점이 분명하다면 어려움에도 불구하고 인내 할 가치가 있을지 모르지만, 그렇지 않은 것 같습니다.

J

직접적인 절차 적 프로그래밍과 관련하여 OOP의 첫 번째 기본 원칙은 정보 숨기기 및 캡슐화 개념입니다. 이 아이디어는 인터페이스를 구현에서 분리하는 클래스의 개념으로 이어집니다.

C ++의 iostream 또는 C의 FILE * 중 더 숨겨진 구현은 무엇입니까?

나는 잘 알려진 두 가지 예를 들기 위해 불투명 한 컨텍스트 객체 (Win32의 핸들, C의 FILE *)를 사용한다고 생각합니다. 그것보다 훨씬 더 캡슐화 된) 절차 코드에서도 발견됩니다. 나는 이것이 OOP에 특정한 방법을보기 위해 고심하고 있습니다.

나는 그것이 이점을보기 위해 고투하고있는 이유 중 일부 일 수 있다고 생각합니다 : 분명히 좋은 부분은 OOP에만 국한되지 않지만 OOP에 특정한 부분은 분명히 좋지 않습니다! (이것은 그들이 반드시 나쁘다는 것을 말하는 것이 아니라 오히려 그들이 광범위하게 적용 가능하고 지속적으로 유익하다는 증거를 보지 못했다는 것입니다).

필자가 읽은 유일한 개발자 블로그 에서 Joel-On-Software-Founder-of-SO 담당자는 OO가 생산성 향상으로 이어지지 않는다는 것을 오래 전에 읽었습니다. 자동 메모리 관리가 수행합니다. 멋있는. 누가 데이터를 거부 할 수 있습니까?

나는 여전히 OO가 함수가 아닌 프로그래밍이 모든 것을 인라인으로 프로그래밍하는 것이 아닌 비 OO라고 생각합니다.

함수가없는 코드가 메소드가있는 코드가되면 몇 마일의 코드를 삭제하게됩니다.

당신이 할 코드를 리팩토링 할 때 정말 OO, b, c, q, 및 Z가 this, this, this와 this. 그리고 this키워드 사용을 믿지 않기 때문에 수 마일의 코드를 삭제할 수 있습니다. 실제로을 사용하더라도 그렇게 할 수 있습니다 this.

나는 OO가 자연적인 은유라고 생각하지 않습니다.

예를 들어, 항공사 예약 시스템을 수행 할 때 예약이라고하는 것은 법적 / 비즈니스 예약과 전혀 일치하지 않을 수 있습니다.

기본 개념 중 일부는 정말 멋진 도구입니다

OOP의 요점은 무엇입니까?

OOP는 대부분의 개발자들에 의해 오해 될 예정입니다

미니 에세이 / 질문에 대하여

네 말이 옳다고 언급하고 싶었다. 재사용 가능성은 대부분의 꿈입니다. 여기에 (화려한) 그 주제에 대한 앤더스 Hejilsberg에서 인용이다 여기에서는 :

초보 프로그래머에게 달력 컨트롤을 작성하도록 요청하는 경우 종종 자신에게 다음과 같이 생각합니다. "세계 최고의 달력 컨트롤을 작성하겠습니다! 달력의 종류와 관련하여 다형성이 될 것입니다. "분쇄기, 이것, 저것 그리고 다른 것" 그들은 두 달 안에 달력 응용 프로그램을 배송해야합니다. 이들은이 모든 인프라를 제어 시스템에 배치 한 다음 이틀에 달력 일정 응용 프로그램을 작성하는 데 이틀을 보냅니다. "다음 버전의 응용 프로그램에서는 더 많은 작업을 수행 할 것입니다."라고 생각합니다.

그러나 그들이 추상 디자인의 다른 모든 concretization을 실제로 어떻게 구현할 것인지에 대해 생각하기 시작하면, 그들의 디자인은 완전히 틀린 것으로 판명되었습니다. 그리고 그들은 스스로를 모퉁이에 페인트했고 모든 것을 버려야합니다. 나는 그것을 계속해서 보았다. 나는 미니멀리즘에 대한 강한 신자입니다. 실제로 일반적인 문제를 해결하지 않는 한 특정 프레임 워크를 해결하기위한 프레임 워크를 시도하지 마십시오. 프레임 워크의 모양을 모르기 때문입니다.

WinAPI를 사용하여 창을 만든 적이 있습니까?

내가 기억하는 것보다 더 많은 시간.

그런 다음 클래스를 정의하고 (RegisterClass), 인스턴스를 작성하고 (CreateWindow), 가상 메소드 (WndProc) 및 기본 클래스 메소드 (DefWindowProc) 등을 호출해야합니다. WinAPI는 SmallTalk OOP의 명명법을 사용하여 "메시지"(윈도우 메시지) 메소드를 호출합니다.

그런 다음 자체 메시지 전달이 없다는 것을 알 수 있습니다. 이는 큰 공백입니다. 또한 크 래피 서브 클래 싱이 있습니다.

핸들은 상속 할 수 없지만 Java에는 최종이 있습니다. 그들은 수업이 부족하지 않고 수업의 자리 표시 자입니다. "핸들"이라는 단어의 의미입니다. MFC 또는 .NET WinForms와 같은 아키텍처를 살펴보면 구문을 제외하고 WinAPI와 크게 다르지 않다는 것이 즉시 명백합니다.

인터페이스 또는 구현에서 상속 할 수 없으며 최소한으로 대체 가능하며 절차 적 코더가 영원히 수행 한 것과 크게 다르지 않습니다.

이게 진짜입니까? OOP의 가장 좋은 점은 단지 ... 전통적인 절차 코드입니까? 그게 큰 문제 야?

InSciTek Jeff 의 답변에 전적으로 동의 합니다. 다음과 같은 개선 사항을 추가하겠습니다.

• 정보 숨기기 및 캡슐화 : 유지 관리 가능한 코드에 중요합니다. 모든 프로그래밍 언어에서주의를 기울여 수행 할 수 있으며 OO 기능이 필요하지 않지만 코드를 약간 OO처럼 만들 수 있습니다.
• 상속 : 모든 OO 가 다양 하고 포함 된 관계가 완벽하게 맞는 중요한 응용 프로그램 도메인이 있습니다 . 그래픽 사용자 인터페이스. OO 언어 지원없이 GUI를 빌드하려고하면 어쨌든 OO와 유사한 기능을 구축하게되며 언어 지원 없이는 오류가 발생하기가 더욱 어려워집니다. 예를 들어 글 레이드 (최근)와 X11 Xt (역사적)입니다.

포인트가 없을 때 OO 기능 (특히 깊게 중첩 된 추상 계층)을 사용하는 것은 의미가 없습니다. 그러나 일부 응용 분야의 경우 실제로 요점이 있습니다.

OOP의 가장 유리한 품질은 데이터 숨기기 / 관리라고 생각합니다. 그러나 OOP가 잘못 사용되는 사례가 많이 있으며 이것이 혼란이 발생한 곳이라고 생각합니다.

무언가를 물건으로 만들 수 있다고해서 꼭해야하는 것은 아닙니다. 그러나 그렇게하면 코드를보다 체계적이고 쉽게 읽을 수있게해야합니다.

OOP가 도움이되는 실질적인 예는 웹 사이트에서 사용하는 "제품"클래스와 객체입니다. 모든 페이지는 제품이며 모든 제품에는 다른 제품에 대한 참조가 있으므로 데이터를 참조하는 제품에 대해 매우 혼란 스러울 수 있습니다. 이 "strURL"변수가 현재 페이지, 홈 페이지 또는 통계 페이지에 대한 링크입니까? 물론 동일한 정보를 참조하는 모든 종류의 다른 변수를 만들 수는 있지만 proCurrentPage-> strURL은 개발자가 이해하기 훨씬 쉽습니다.

또한 해당 페이지에 기능을 첨부하는 것이 훨씬 깔끔합니다. proCurrentPage-> CleanCache ()를 할 수 있습니다. 다음에 proDisplayItem-> RenderPromo (); 방금 그 함수를 호출하고 현재 데이터를 사용할 수 있다고 가정하면 누가 어떤 종류의 악이 일어날 지 알고 있습니다. 또한 올바른 변수를 해당 함수에 전달 해야하는 경우 다른 제품에 대해 모든 종류의 변수를 갖는 문제로 돌아갑니다.

대신 객체를 사용하면 모든 제품 데이터와 기능이 훌륭하고 깨끗하며 이해하기 쉽습니다.

하나. OOP의 큰 문제는 누군가가 모든 것이 OOP 여야한다고 믿는 경우입니다. 이로 인해 많은 문제가 발생합니다. 데이터베이스에 88 개의 테이블이 있습니다. 나는 약 6 개의 수업이 있고 아마도 약 10 개의 수업이 있어야합니다. 88 개의 수업이 필요하지 않습니다. 대부분의 경우 해당 테이블에 직접 액세스하는 것은 내가 사용하는 환경에서 완벽하게 이해할 수 있으며 OOP는 실제로 발생하는 핵심 기능에 도달하기가 더 어려워지고 지루합니다.

유용하고 절차적인 실제 객체가 가장 효과적인 코딩 방법 인 하이브리드 객체 모델을 믿습니다. 사람들이 다른 방법을 희생하여 한 가지 방법을 사용하여 옹호하는 이러한 모든 종교적 전쟁이 부끄러운 일입니다. 그들은 둘 다 좋고 둘 다 자리가 있습니다. 대부분의 경우 모든 큰 프로젝트에서 두 가지 방법을 모두 사용합니다 (일부 작은 프로젝트에서는 단일 개체 또는 몇 가지 절차만으로도 충분할 수 있습니다).

가독성을 위해하는 것만 큼 재사용을 신경 쓰지 않습니다. 후자는 코드 변경이 더 쉽다는 것을 의미합니다. 그 자체만으로도 소프트웨어 제작 기술에서 금의 가치가 있습니다.

그리고 OO는 프로그램을 읽을 수있게하는 아주 효과적인 방법입니다. 재사용 또는 재사용 금지.

"실제 세계는"OO "가 아닙니다."

정말? 내 세상은 사물로 가득합니다. 나는 지금 하나를 사용하고 있습니다. 소프트웨어 "객체"를 실제 객체로 모델링하는 것은 그리 나쁘지 않다고 생각합니다.

개념적인 것들을위한 OO 디자인 (실제 윈도우는 아니지만 Windows 컴퓨터 모니터의 디스플레이 패널)은 종종 많은 것을 요구합니다. 그러나 송장, 운송 주문, 보험 청구 및 기타 사실과 같은 실제 상황에서는 실제 상황이 대상이라고 생각합니다. 책상 위에 쌓아 놓았으므로 반드시 실재해야합니다.

OOP의 요점은 프로그래머에게 기계 및 사람에게 코드의 문제에 대한 솔루션을 설명하고 전달하는 또 다른 수단을 제공하는 것입니다. 그 중 가장 중요한 부분은 사람들과의 의사 소통입니다. 프로그래머는 OOP를 통해 OO 언어로 시행되는 규칙을 통해 코드에서 의미하는 바를 선언 할 수 있습니다.

이 주제에 대한 많은 주장과는 달리, OOP 및 OO 개념은 C와 같은 비 OOP 언어의 코드를 포함하여 모든 코드에 널리 퍼져 있습니다. 많은 고급 비 OO 프로그래머는 비 OO 언어에서도 객체의 기능을 대략적으로 반영합니다.

언어에 OO를 내장하면 프로그래머에게 또 다른 표현 수단을 제공 할 수 있습니다.

코드 작성의 가장 큰 부분은 기계와의 통신이 아니며, 그 부분은 쉬우 며, 가장 큰 부분은 인간 프로그래머와의 통신입니다.