OOP의 요점은 무엇입니까?

Question

내가 아는 한, OOP 교육, 언어 및 도구에 수백만 또는 수십억 달러를 지출했음에도 불구하고 OOP는 개발자 생산성이나 소프트웨어 안정성을 향상시키지 못했고 개발 비용도 줄이지 않았습니다.엄격한 의미에서 OOP를 사용하는 사람은 거의 없습니다(LSP와 같은 원칙을 고수하거나 이해하는 사람은 거의 없습니다).문제 영역을 모델링하기 위해 사람들이 취하는 접근 방식에는 통일성이나 일관성이 거의 없는 것 같습니다.클래스는 단지 문법적 편의를 위해 사용되는 경우가 많습니다.레코드 유형에 대한 함수를 자체의 작은 네임스페이스에 넣습니다.

저는 다양한 애플리케이션을 위해 많은 양의 코드를 작성했습니다.실제 대체 가능한 하위 유형 지정이 응용 프로그램에서 중요한 역할을 한 곳이 있었지만 이는 매우 예외적이었습니다.일반적으로 "재사용"에 대해 많은 립서비스가 제공되지만 현실은 코드 조각이 재사용되지 않는 한 정확히 원하는 대로 수행하려면 비용 효율적인 "재사용"이 거의 없습니다.확장 가능하도록 클래스를 설계하는 것은 매우 어렵습니다. 올바른 방법으로, 따라서 확장 비용은 일반적으로 너무 커서 "재사용"할 가치가 없습니다.

여러 면에서 이것은 나에게 놀라운 일이 아니다.현실 세계는 "OO"가 아니며, OO에 내포된 아이디어(일부 클래스 분류로 사물을 모델링할 수 있음)는 근본적으로 결함이 있는 것 같습니다(테이블, 나무 그루터기, 자동차 보닛 위에 앉을 수 있음). , 누군가의 무릎-그러나 그 중 하나는 의자가 아닙니다).보다 추상적인 영역으로 이동하더라도 OO 모델링은 종종 어렵고 직관에 어긋나며 궁극적으로 도움이 되지 않습니다(원/타원 또는 정사각형/직사각형의 고전적인 예를 고려).

그렇다면 내가 여기서 무엇을 놓치고 있는 걸까요?OOP의 가치는 어디에 있으며, 소프트웨어를 더 좋게 만드는 데 왜 모든 시간과 돈이 실패했습니까?

Answer 1

객체지향이 사람들이 세상에 대해 생각하는 더 자연스러운 방식이라는 것을 시사하는 경험적 증거는 없습니다.프로그래밍 심리학 분야에는 OO가 다른 접근 방식보다 더 적합하지 않다는 것을 보여주는 일부 연구가 있습니다.

객체 지향 표현은 보편적으로 더 유용하거나 덜 유용하지 않은 것으로 보입니다.

단순히 OO 방식을 채택하고 개발자에게 그러한 방식을 사용하도록 요구하는 것만으로는 충분하지 않습니다. 왜냐하면 이는 개발된 시스템의 품질은 물론 개발자의 생산성에도 부정적인 영향을 미칠 수 있기 때문입니다.

10월 ACM 커뮤니케이션즈의 "On the Usability of OO Representation"에서 발췌한 내용입니다.2000.이 기사에서는 주로 OO를 프로세스 지향 접근 방식과 비교합니다.OO 방법으로 작업하는 사람들이 어떻게 "생각"하는지에 대한 많은 연구가 있습니다(Int.제이.of Human-Computer Studies 2001, 54호 또는 Human-Computer Interaction 1995, vol.10에는 OO 연구에 대한 전체 주제가 있습니다). 제가 읽은 바에 따르면 OO 접근 방식이 보다 전통적인 절차적 접근 방식보다 더 적합하다는 일종의 자연스러움을 나타내는 것은 없습니다.

Answer 2

현실 세계는 "OO"가 아니며 OO에 내재된 아이디어(일부 클래스 분류를 사용하여 사물을 모델링할 수 있음)는 근본적으로 결함이 있는 것 같습니다.

이것이 사실이고 다른 사람들이 관찰한 반면(STL의 발명가인 Stepanov를 예로 들겠습니다), 나머지는 말도 안 됩니다.OOP에는 결함이 있을 수 있으며 확실히 만병통치약은 아니지만 종속성을 줄이는 좋은 방법이기 때문에 대규모 애플리케이션을 훨씬 간단하게 만듭니다.물론 이는 "좋은" OOP 디자인에만 적용됩니다.엉성한 디자인은 어떤 이점도 주지 않습니다.그러나 좋은 분리형 디자인은 OOP를 사용하면 매우 잘 모델링할 수 있지만 다른 기술을 사용하면 잘 모델링할 수 없습니다.

훨씬 더 좋고 보편적인 모델이 있습니다(Haskell의 유형 모델 떠오르는 점) 그러나 이는 효율적으로 구현하기가 더 복잡하거나 어려운 경우가 많습니다.OOP는 극단 간의 좋은 절충안입니다.

Answer 3

OOP는 재사용 가능한 클래스를 만드는 것이 아니라 사용 가능한 클래스를 만드는 것입니다.

Answer 4

너무 자주,이 계급은 단순히 구문 설탕에 사용됩니다.레코드 유형의 기능을 자체 작은 네임 스페이스에 넣습니다.

예, 저는 이것이 너무 널리 퍼져 있다고 생각합니다.이것은 객체 지향 프로그래밍이 아닙니다.객체 기반 프로그래밍과 데이터 중심 프로그래밍입니다.OO 언어로 일한 10년 동안 나는 사람들이 주로 객체 기반 프로그래밍을 하는 것을 보았습니다.OBP는 본질적으로 두 단어 중 최악의 결과를 얻기 때문에 매우 빠르게 IMHO로 분류됩니다.1) 입증된 구조적 프로그래밍 방법론을 따르지 않는 절차적 프로그래밍 및 2) 입증된 OOP 방법론을 따르지 않는 OOP.

OOP를 올바르게 수행하는 것은 아름다운 일입니다.이는 매우 어려운 문제를 쉽게 해결할 수 있도록 하며, (거만하게 들리려고 하지 않는) 초심자에게는 거의 마술처럼 보일 수 있습니다.즉, OOP는 프로그래밍 방법론 도구 상자의 하나의 도구일 뿐입니다.그것은 모든 것을 끝내는 방법론이 아닙니다.이는 대규모 비즈니스 애플리케이션에 적합합니다.

OOP 언어로 작업하는 대부분의 개발자는 일상적으로 사용하는 프레임워크와 유형에서 바로 수행되는 OOP의 예를 활용하고 있지만 이를 인식하지 못합니다.다음은 매우 간단한 몇 가지 예입니다.ADO.NET, Hibernate/NHibernate, 로깅 프레임워크, 다양한 언어 컬렉션 유형, ASP.NET 스택, JSP 스택 등...이것들은 코드베이스에서 OOP에 크게 의존하는 것입니다.

Answer 5

재사용은 OOP 또는 그 문제에 대한 다른 패러다임의 목표가 되어서는 안 됩니다.

재사용은 좋은 디자인과 적절한 추상화 수준의 부작용입니다.코드는 유용한 작업을 수행하여 재사용을 달성하지만 유연성을 떨어뜨리지는 않습니다.코드가 OO인지 여부는 중요하지 않습니다. 작동하는 코드를 재사용하고 스스로 수행하는 것이 사소하지 않습니다.그것은 실용주의입니다.

OO를 상속을 통해 재사용하는 새로운 방법으로 생각하는 것은 근본적으로 결함이 있습니다.아시다시피 LSP 위반이 많습니다.대신 OO는 문제 영역의 복잡성을 관리하는 방법으로 적절하게 생각됩니다.목표는 시간이 지남에 따라 시스템을 유지 관리하는 것입니다.이를 달성하기 위한 주요 도구는 공용 인터페이스를 개인 구현에서 분리하는 것입니다.이를 통해 코드 검토 대신 "...을 통해서만 수정해야 합니다."와 같은 규칙을 컴파일러에서 시행할 수 있습니다.

이것을 사용하면 여러분도 동의할 것이라고 확신합니다. 이를 통해 우리는 매우 복잡한 시스템을 만들고 유지 관리할 수 있습니다.거기에는 많은 가치가 있으며, 다른 패러다임에서는 하기가 쉽지 않습니다.

Answer 6

종교적인 측면이 있지만 당신은 현대 OOP의 상태에 대해 지나치게 암울한 그림을 그리고 있다고 말하고 싶습니다.나는 그것이 실제로 그렇다고 주장할 것이다. 가지다 비용 절감, 대규모 소프트웨어 프로젝트 관리 가능화 등.그렇다고 해서 소프트웨어의 난잡함이라는 근본적인 문제가 해결되었다는 의미도 아니며 일반 개발자가 OOP 전문가라는 의미도 아닙니다.그러나 기능을 객체 구성 요소로 모듈화함으로써 세상에 존재하는 스파게티 코드의 양이 확실히 줄어들었습니다.

나는 아름답게 재사용할 수 있고 결코 계산할 수 없는 시간과 돈을 절약해 준 수십 개의 라이브러리를 머리 속에서 떠올릴 수 있습니다.

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

Answer 7

불투명한 컨텍스트 개체(Win32의 HANDLE, C의 FILE* 등 잘 알려진 두 가지 예를 들자면 HANDLE은 커널 모드 장벽의 반대편에 있으며 실제로는 얻을 수 없는 것)를 사용하는 것 같습니다. 그보다 훨씬 더 캡슐화되어 있음)은 절차 코드에서도 발견됩니다.나는 이것이 어떻게 OOP에 특별한 것인지 알기 위해 애쓰고 있습니다.

HANDLEs(및 나머지 WinAPI) ~이다 이런!C는 OOP를 잘 지원하지 않기 때문에 특별한 구문은 없지만 그렇다고 동일한 개념을 사용하지 않는다는 의미는 아닙니다.WinAPI는 모든 의미에서 개체 지향 프레임워크입니다.

이것이 OOP 또는 대체 기술과 관련된 모든 단일 토론의 문제입니다.누구도 그 정의에 대해 명확하지 않으며, 모두가 다른 것에 대해 이야기하고 있으므로 합의에 도달할 수 없습니다.나에게는 시간 낭비처럼 보인다.

Answer 8

프로그래밍 패러다임이다..우리 같은 인간이 문제를 더 작고 실행 가능한 조각으로 더 쉽게 분해할 수 있도록 설계되었습니다.

유용하지 않다면..그것을 사용하지 말고 훈련 비용을 지불하지 말고 행복하십시오.

반면에 나는 그것이 유용하다고 생각하므로 그렇게 할 것입니다 :)

Answer 9

직접적인 절차적 프로그래밍과 관련하여 OOP의 첫 번째 기본 원칙은 정보 숨기기 및 캡슐화 개념입니다.이 아이디어는 다음과 같은 개념으로 이어진다. 수업 인터페이스와 구현을 분리합니다.이것은 매우 중요한 개념이자 프로그램 설계에 대해 다른 방식, 더 나은 방식으로 생각할 수 있는 프레임워크를 마련하기 위한 기초입니다.이러한 속성에 대해 실제로 논쟁을 벌일 수는 없습니다. 절충안이 없으며 항상 사물을 모듈화하는 더 깔끔한 방법입니다.

상속과 다형성을 포함한 OOP의 다른 측면도 중요하지만 다른 사람들이 언급했듯이 이러한 측면은 일반적으로 과도하게 사용됩니다.즉:때때로 사람들은 상속 및/또는 다형성을 사용해야 하기 때문에가 아니라 할 수 있기 때문에 사용합니다.이는 강력한 개념이고 매우 유용하지만 현명하게 사용해야 하며 OOP의 자동 승리 이점이 아닙니다.

재사용에 상대적입니다.OOP에서는 재사용이 과도하게 판매된다는 데 동의합니다.이는 잘 정의된 객체(일반적으로 보다 원시적/일반 클래스)의 부작용일 수 있으며 캡슐화 및 정보 숨기기 개념의 직접적인 결과입니다.잘 정의된 클래스의 인터페이스가 더 명확하고 어느 정도 자체 문서화가 가능하기 때문에 잠재적으로 재사용하기가 더 쉽습니다.

Answer 10

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

Alan Kay가 처음 구상한 것처럼 이는 원시 데이터와 전체 전역 루틴을 보유하는 이전 방식에 대한 훌륭한 대안이었습니다.

그러자 일부 경영컨설턴트 유형이 이를 붙잡고 소프트웨어의 메시아로 팔았고, 레밍 같은 학계와 산업계가 뒤따랐다.

이제 그들은 함수형 프로그래밍과 같은 다른 좋은 아이디어가 과대평가된 후 레밍처럼 뒹굴고 있습니다.

그러면 나는 무엇을 다르게 할 것인가?나는 이것에 관한 책을 썼습니다.(절판되었습니다. 저는 한 푼도 받지 못하지만 여전히 사본을 얻을 수 있습니다.)아마존

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

그것은 매우 다르며 정보 이론(누구나 이해할 수 있는 수준)을 기반으로 합니다.프로그래밍은 언어를 정의하는 과정으로 볼 수 있으며, 이를 수행하는 기술은 좋은 프로그래밍에 필수적이라고 말합니다.

이는 DSL(도메인별 언어)의 개념을 향상시킵니다.이는 DRY와 매우 일치합니다(반복하지 마세요).코드 생성에 큰 도움이 됩니다.이로 인해 최신 응용 프로그램의 일반적인 데이터 구조보다 훨씬 적은 데이터 구조를 갖춘 소프트웨어가 탄생합니다.

이는 앞으로 나아갈 길은 창의성에 있으며 심지어 잘 받아들여지는 아이디어라도 의문을 제기해야 한다는 생각을 다시 활성화하고자 합니다.

Answer 11

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

그래도 그렇습니까?상속도 불가능하고, 대체도 불가능하며, 잘 정의된 클래스도 부족합니다...나는 그들이 "OOP"에 비해 훨씬 부족하다고 생각합니다.

WinAPI를 사용하여 창을 만들어 본 적이 있나요?그런 다음 클래스(RegisterClass), 해당 인스턴스를 생성합니다(CreateWindow), 가상 메소드 호출(WndProc) 및 기본 클래스 메서드(DefWindowProc) 등등.WinAPI는 SmallTalk OOP의 명명법을 사용하여 메서드를 "메시지"(창 메시지)라고 부릅니다.

핸들은 상속되지 않을 수도 있지만 다음이 있습니다. final 자바에서.그들은 수업이 부족하지 않습니다. ~이다 수업에 대한 자리 표시자:이것이 "손잡이"라는 단어의 의미입니다.MFC 또는 .NET WinForms와 같은 아키텍처를 살펴보면 구문을 제외하면 WinAPI와 크게 다른 점은 없다는 것을 즉시 알 수 있습니다.

Answer 12

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

Answer 13

OOP는 GUI "위젯"과 같은 내부 컴퓨터 구조를 프로그래밍하는 데 적합합니다. 예를 들어 SelectList 및 TextBox는 "이동" 및 "크기 조정"과 같은 일반적인 방법이 있는 항목의 하위 유형일 수 있습니다.

문제는 우리 중 90%가 송장, 직원, 직업, 주문과 같은 비즈니스 개념을 다루는 비즈니스 세계에서 일하고 있다는 것입니다.이것들 하지 마라 "객체"가 더 모호하고 비즈니스 리엔지니어링 등에 따라 변경될 수 있기 때문에 OOP에 매우 적합합니다.

최악의 경우는 SQL 데이터베이스에 대한 터무니없는 OO "향상"을 포함하여 OO가 데이터베이스에 열정적으로 적용되는 경우입니다. 이는 최신이기 때문에 작업을 수행하는 올바른 방법이어야 한다고 가정하는 데이터베이스 초보 사용자를 제외하고는 당연히 무시됩니다.

Answer 14

제가 겪은 프로젝트의 코드와 디자인을 검토해 본 경험에 따르면, OOP의 가치가 완전히 실현되지는 않습니다. 객체 지향 모델이 제대로 개념화되지 않았습니다. 그들의 마음 속에.따라서 그들은 OO 디자인으로 프로그래밍하지 않고, 클래스를 보기 좋게 만드는 하향식 절차 코드를 계속해서 작성하는 경우가 많습니다. 평평한 설계.(애초에 그것을 "디자인"이라고 부를 수 있다면)

비즈니스 요구 사항에 맞게 상속 계층 구조를 적절하게 설계하는 것은 말할 것도 없고 추상 클래스나 인터페이스가 무엇인지 아는 동료가 얼마나 적은지 관찰하는 것은 꽤 무서운 일입니다.

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

물론 그 정도는 꽤 된다 희귀한 안타깝게도.세상에서 아름답게 디자인된 물리적 개체와 끔찍하게 디자인된 물리적 개체의 비율과 마찬가지로 소프트웨어 엔지니어링 및 디자인에 대해서도 거의 동일하다고 말할 수 있습니다.좋은 도구를 마음대로 사용할 수 있다고 해서 반드시 좋은 관행과 결과가 나오는 것은 아닙니다.

Answer 15

어쩌면 보닛, 무릎, 나무 등은 의자가 아니지만 모두 앉을 수 있습니다.

Answer 16

내 생각엔 현실 세계의 것들이 객체인 것 같아

당신은요?

송장에는 어떤 방법이 있나요?아, 잠깐만요.스스로 지불할 수도 없고, 보낼 수도 없고, 판매자가 실제로 배달한 품목과 비교할 수도 없습니다.메소드가 전혀 없습니다.그것은 완전히 불활성이고 기능하지 않습니다.객체가 아닌 레코드 유형(원하는 경우 구조체)입니다.

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

어떤 것이 실제라고 해서 그것이 OO라는 단어의 의미에서 객체가 되는 것은 아닙니다.OO 객체는 스스로 행동할 수 있는 상태와 동작의 독특한 결합입니다.그것은 현실 세계에 풍부한 것이 아닙니다.

Answer 17

나는 지난 9년 정도 OO 코드를 작성해 왔습니다.메시징을 사용하는 것 외에는 다른 접근 방식을 상상하기 어렵습니다.CodingTheWheel이 말한 것과 완전히 일치하는 주요 이점은 다음과 같습니다.모듈화.OO는 자연스럽게 깨끗한 인터페이스와 명확한 책임을 가진 모듈식 구성 요소로 애플리케이션을 구성하도록 유도합니다(예:느슨하게 결합되고 응집력이 강한 코드로 우려 사항이 명확하게 분리됩니다.

내 생각에 OO가 무너지는 곳은 사람들이 깊게 중첩된 클래스 계층 구조를 만들 때입니다.이로 인해 복잡성이 발생할 수 있습니다.그러나 공통 기능을 기본 클래스로 제외하고 이를 다른 하위 클래스에서 재사용하는 것은 매우 우아한 일입니다. IMHO!

Answer 18

우선 관찰이 다소 엉성합니다.나는 소프트웨어 생산성에 대한 수치를 전혀 갖고 있지 않으며, 그것이 올라가지 않을 것이라고 믿을 만한 타당한 이유도 없습니다.게다가 OO를 악용하는 사람들이 많기 때문에 땅콩버터 이후로 OO가 최고였다고 해도 OO를 잘 활용한다고 반드시 생산성 향상으로 이어지는 것은 아닙니다.결국, 무능한 뇌외과 의사는 없는 것보다 더 나쁠 수도 있지만, 유능한 사람은 매우 귀중할 수 있습니다.

즉, OO는 절차적 코드를 데이터에 적용하는 것이 아니라 절차적 코드를 데이터에 첨부하여 사물을 배열하는 다른 방식입니다.OO 접근 방식이 더 자연스러운 경우도 있으므로 이는 그 자체로 최소한 작은 승리여야 합니다.결국 누구든지 C++로 절차적 API를 작성하는 것을 막을 수 없으므로 대신 객체를 제공하는 옵션은 언어를 더욱 다양하게 만듭니다.

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

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

일반적으로 더 나은 것은 아니지만 다른 종류의 도구로 생각하십시오.예를 들어 드라이버 외에 망치도 있습니다.아마도 우리는 결국에는 나사를 박는 데 어떤 렌치를 사용해야 하는지 아는 소프트웨어 엔지니어링의 관행에서 벗어나게 될 것입니다.

Answer 19

@션

그러나 공통 기능을 기본 클래스로 제외하고 이를 다른 하위 클래스에서 재사용하는 것은 매우 우아한 일입니다. IMHO!

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

Answer 20

@콘라드

OOP에는 결함이 있을 수 있으며 확실히 만병통치약은 아니지만 종속성을 줄이는 좋은 방법이기 때문에 대규모 애플리케이션을 훨씬 간단하게 만듭니다.

그것이 교리입니다.나는 이와 관련하여 이전의 절차적 프로그래밍보다 OOP를 훨씬 더 좋게 만드는 것이 무엇인지 알지 못합니다.프로시저 호출을 할 때마다 나는 구현의 세부 사항으로부터 나 자신을 고립시킵니다.

Answer 21

나에게는 OOP 구문 자체에 많은 가치가 있습니다.실제 사물이나 데이터 구조를 나타내려고 시도하는 객체를 사용하는 것은 동일한 데이터로 동일한 작업을 수행하기 위해 다양한 플랫(또는 "부동") 함수를 사용하는 것보다 훨씬 더 유용한 경우가 많습니다.장기적으로 읽고, 쓰고, 유지하는 데 더 적합한 좋은 OOP가 있는 항목에는 자연스러운 "흐름"이 있습니다.

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

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

그래서 나에게 OOP의 가장 중요한 목표는 향후 코드 유지 관리 및 변경을 더 쉽게 만드는 것입니다.그러나 그 이상으로, 절차적 코드에서는 결코 할 수 없는 방식으로 올바르게 수행되면 작업을 훨씬 단순화할 수 있습니다."실제 세계"와 일치하지 않는지는 중요하지 않습니다. 코드를 사용한 프로그래밍은 어쨌든 실제 개체와 상호 작용하지 않습니다.OOP는 내 작업을 더 쉽고 빠르게 만들어주는 도구일 뿐입니다. 저는 언제든지 이를 사용하겠습니다.

Answer 22

@CodingTheWheel

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

그래도 정말 놀라운 일인지는 모르겠습니다.나는 기술적으로 건전한 접근 방식(LSP가 당연한 것임)이 사용하기 어렵다, 그러나 이러한 접근 방식을 사용하지 않으면 어쨌든 코드가 부서지기 쉽고 확장할 수 없게 됩니다(더 이상 이에 대해 추론할 수 없기 때문입니다).그리고 내 생각에 OOP가 가져온 직관에 반하는 결과는 사람들이 OOP를 선택하지 않는 것이 당연하다고 생각합니다.

더 중요한 것은, 소프트웨어는 이미 기본적으로 일반 인간이 안정적이고 정확하게 작성하기에는 너무 어렵기 때문에, 지속적으로 제대로 가르치지 않고 배우기 어려워 보이는 기술을 정말로 칭찬해야 할까요?이점이 분명하다면 어려움에도 불구하고 인내할 가치가 있을 수 있지만 그렇지 않은 것 같습니다.

Answer 23

@제프

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

더 숨겨진 구현이 있습니다.C++의 iostream 또는 C의 FILE*?

불투명한 컨텍스트 개체(Win32의 HANDLE, C의 FILE* 등 잘 알려진 두 가지 예를 들자면 HANDLE은 커널 모드 장벽의 반대편에 있으며 실제로는 얻을 수 없는 것)를 사용하는 것 같습니다. 그보다 훨씬 더 캡슐화되어 있음)은 절차 코드에서도 발견됩니다.나는 이것이 어떻게 OOP에 특별한 것인지 알기 위해 애쓰고 있습니다.

나는 이것이 내가 이점을 보기 위해 고군분투하고 있는 이유의 일부일 수 있다고 생각합니다.분명히 좋은 부분은 OOP에만 국한된 것이 아니며, OOP에만 국한된 부분은 분명히 좋지 않습니다!(이것은 그것이 반드시 나쁘다는 것을 말하는 것이 아니라, 그것이 널리 적용 가능하고 일관되게 유익하다는 증거를 보지 못했다는 것입니다).

Answer 24

내가 읽은 유일한 개발자 블로그에서는 SO 창립자 Joel-On-Software라는 사람이 OO가 생산성 향상으로 이어지지 않는다는 것을 오래 전에 읽었습니다.자동 메모리 관리가 수행됩니다.시원한.누가 데이터를 거부할 수 있나요?

나는 여전히 OO가 OO가 아닌 사람에게는 함수 프로그래밍이 모든 것을 인라인으로 프로그래밍하는 것과 같다고 믿습니다.

(그리고 제가 GWBasic을 시작했기 때문에 알아야 합니다.) 함수를 사용하기 위해 코드를 리팩터링할 때, variable2654 된다 variable3 당신이 속한 방법의.아니면 더 좋은 점은 여러분이 이해할 수 있는 이름이 있다는 것입니다. 그리고 함수가 짧다면, ~라고 불린다 value 그리고 그것은 완전한 이해에 충분합니다.

기능이 없는 코드가 메소드가 있는 코드가 되면 수 마일의 코드가 삭제됩니다.

코드를 진정한 OO로 리팩토링하면, b, c, q, 그리고 Z ~이 되다 this, this, this 그리고 this.그리고 나는 그것을 사용하는 것을 믿지 않기 때문에 this 키워드를 사용하면 수 마일의 코드를 삭제할 수 있습니다.실제로 사용하더라도 그렇게 할 수 있습니다. this.

OO가 자연스러운 비유는 아닌 것 같아요.

나는 언어가 자연스러운 은유라고 생각하지 않으며, Fowler의 "냄새"가 "이 코드가 나쁘다"고 말하는 것보다 낫다고 생각하지 않습니다. 즉, OO는 자연 은유와 생각하는 사람들에 관한 것이 아니라고 생각합니다. 물건이 갑자기 튀어나온다 기본적으로 요점을 놓치고 있습니다. 당신은 객체 우주를 정의합니다. 그리고 더 나은 객체 세계는 더 짧고, 이해하기 쉽고, 더 잘 작동하는 코드 또는 이 모든 것(그리고 내가 잊고 있는 몇 가지 기준)을 생성합니다.고객/도메인의 자연 개체를 프로그래밍 개체로 사용하는 사람들은 우주를 재정의할 수 있는 힘을 놓치고 있다고 생각합니다.

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

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

나는 대부분의 사람들이 "망치를 가지고 있으면 모두 못이다"라는 말을 과장한다고 생각합니다.나는 동전/거울의 다른 면도 마찬가지로 사실이라고 생각합니다.다형성/상속과 같은 장치가 있으면 장갑/양말/콘택트 렌즈처럼 적합한 용도를 찾기 시작합니다.OO의 도구는 매우 강력합니다.단일 상속은 사람들이 쫓겨나지 않으려면 절대적으로 필요하다고 생각합니다. 다중 상속 소프트웨어가 견딜 수 없습니다.

OOP의 요점은 무엇입니까?

나는 이것이 매우 방대한 코드 기반을 처리하는 좋은 방법이라고 생각합니다.내 생각에는 코드를 정리하고 재구성할 수 있고 (작업 중인 프로그래밍 언어를 넘어서) 이를 수행할 수 있는 언어를 제공하고 매우 자연스럽고 이해하기 쉬운 방식으로 코드를 모듈화할 수 있다고 생각합니다.

OOP는 대다수 개발자가 오해할 운명입니다.

이는 인생과 마찬가지로 눈을 뜨게 만드는 과정이기 때문입니다.경험을 통해 OO를 점점 더 많이 이해하고, 현명해질수록 특정 패턴을 피하고 다른 패턴을 고용하기 시작합니다.가장 좋은 예 중 하나는 제어할 수 없는 클래스에 대한 상속 사용을 중단하고 상속을 선호하는 것입니다. 정면 대신 패턴.

귀하의 미니 에세이/질문에 관하여

나는 당신이 옳았다는 것을 언급하고 싶었습니다.재사용성은 대부분의 경우 헛된 꿈입니다.다음은 해당 주제에 대한 Anders Hejilsberg의 인용문입니다(훌륭함). 여기에서:

시작 프로그래머에게 캘린더 컨트롤을 작성 해달라고 요청하면 종종 스스로 생각합니다. "아, 저는 세계 최고의 캘린더 제어를 쓸 것입니다!달력의 종류와 관련하여 다형성이 될 것입니다.그것은 디스플레이와 뭉개, 그리고 이것과 다른 것들을 갖게 될 것입니다. "그들은 2 개월 안에 캘린더 응용 프로그램을 배송해야합니다.그들은이 모든 인프라를 제어에 적용한 다음 이틀을 그 위에 엉뚱한 캘린더 응용 프로그램을 작성합니다.그들은 "다음 버전의 응용 프로그램에서는 훨씬 더 많은 일을 할 것입니다."라고 생각할 것입니다.

그러나 그들이 어떻게 추상적 인 디자인의 다른 모든 구체화를 실제로 구현할 것인지에 대해 생각하기 시작하면, 그들의 디자인은 완전히 잘못된 것으로 밝혀졌습니다.그리고 이제 그들은 그들 자신을 모퉁이로 칠해서 모든 것을 버려야합니다.나는 그것을 계속해서 보았습니다.나는 최소한의 신자입니다.실제로 일반적인 문제를 해결하지 않는 한 특정 문제를 해결하기위한 프레임 워크를 제시하지 마십시오. 해당 프레임 워크가 어떻게 보일지 알지 못하기 때문입니다.

Answer 25

WinAPI를 사용하여 창을 만들어 본 적이 있나요?

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

그런 다음 클래스 정의(RegisterClass), 해당 클래스의 인스턴스 생성(CreateWindow), 가상 메서드 호출(WndProc) 및 기본 클래스 메서드(DefWindowProc) 등을 알아야 합니다.WinAPI는 SmallTalk OOP의 명명법을 사용하여 메서드를 "메시지"(창 메시지)라고 부릅니다.

그러면 자체적으로 메시지를 발송하지 않는다는 사실도 알게 될 것입니다. 이는 큰 공백입니다.또한 형편없는 서브클래싱도 있습니다.

핸들은 상속 불가능할 수 있지만 Java에는 최종 핸들이 있습니다.수업이 부족한 것이 아니라 수업의 자리 표시자입니다.이것이 "손잡이"라는 단어의 의미입니다.MFC 또는 .NET WinForms와 같은 아키텍처를 살펴보면 구문을 제외하면 WinAPI와 크게 다른 점은 없다는 것을 즉시 알 수 있습니다.

인터페이스나 구현에서 상속할 수 없으며 최소한으로 대체할 수 있으며 절차적 코더가 지금까지 해왔던 작업과 크게 다르지 않습니다.

정말이게 맞나요?OOP의 가장 좋은 점은...전통적인 절차 코드? 그건 큰일이야?

Answer 26

나는 전적으로 동의한다. 인사이텍 제프님의 답변에 다음과 같은 개선 사항을 추가하겠습니다.

• 정보 숨기기 및 캡슐화:유지 관리 가능한 코드에 중요합니다.어떤 프로그래밍 언어에서든 주의해서 수행할 수 있으며 OO 기능이 필요하지 않지만 그렇게 하면 코드가 약간 OO와 비슷해집니다.
• 계승:모든 OO가 사용하는 중요한 응용 프로그램 도메인이 하나 있습니다. 일종의 그리고 포함-a 관계는 완벽하게 맞습니다.그래픽 사용자 인터페이스.OO 언어 지원 없이 GUI를 구축하려고 하면 어쨌든 OO와 유사한 기능을 구축하게 될 것이며, 언어 지원 없이는 더 어렵고 오류가 발생하기 쉽습니다.예를 들어 Glade(최근) 및 X11 Xt(역사적)입니다.

아무런 의미가 없을 때 OO 기능(특히 깊게 중첩된 추상 계층 구조)을 사용하는 것은 의미가 없습니다.그러나 일부 응용 프로그램 도메인의 경우 실제로 중요한 점이 있습니다.

Answer 27

저는 OOP의 가장 유익한 품질은 데이터 숨기기/관리라고 믿습니다.그러나 OOP가 오용되는 예가 많이 있으며 여기서 혼란이 발생한다고 생각합니다.

무언가를 물건으로 만들 수 있다고 해서 그렇게 해야 한다는 의미는 아닙니다.그러나 그렇게 하면 코드가 더 체계화되고 읽기 쉬워진다면 반드시 그렇게 해야 합니다.

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

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

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

하지만.OOP의 가장 큰 문제는 누군가 모든 것이 OOP여야 한다고 믿는 것입니다.이로 인해 많은 문제가 발생합니다.내 데이터베이스에는 88개의 테이블이 있습니다.수업이 6개 정도 있는데 아마도 10개 정도는 있어야 할 것 같아요.88 수업은 확실히 필요하지 않습니다.해당 테이블에 직접 액세스하는 대부분의 시간은 내가 사용하는 상황에서 완벽하게 이해할 수 있으며 OOP는 실제로 발생하는 핵심 기능에 도달하는 것을 더 어렵고/지루하게 만듭니다.

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

Answer 28

나는 가독성만큼 재사용에 관심이 없습니다.후자는 코드를 변경하기가 더 쉽다는 것을 의미합니다.그것만으로도 소프트웨어 구축 기술에서는 금과 같은 가치가 있습니다.

그리고 OO는 프로그램을 읽기 쉽게 만드는 매우 효과적인 방법입니다.재사용 여부.

Answer 29

"현실세계는 'OO'가 아니다"

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

개념적인 것에 대한 OO 디자인(실제 창이 아닌 컴퓨터 모니터의 디스플레이 패널과 같은 Windows)은 종종 아쉬운 점이 많습니다.하지만 송장, 배송 주문, 보험금 청구 등과 같은 현실 세계의 것들은 객체라고 생각합니다.내 책상 위에 더미가 있는데 그게 진짜임에 틀림없어요.

Answer 30

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

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

언어에 OO가 내장되어 있다는 것은 프로그래머에게 또 다른 표현 수단을 제공할 뿐입니다.

코드 작성의 가장 큰 부분은 기계와의 의사소통이 아니라 그 부분이 쉽고, 가장 큰 부분은 인간 프로그래머와의 의사소통입니다.