나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.
생성 - 공장을 통해 삭제 - 일반적인 방법으로. 위임이 필요한지 여부는 라이브러리의 내용이 어떻게 사용되는지에 따라 결정됩니다. 라이브러리가 스스로 작업을 수행하는 클래스를 제공하는 경우 위임할 필요가 없습니다. 인터페이스 메서드를 호출하기만 하면 됩니다.
그건 그렇고, Android/Java 에는 코어 클래스와 유사한 쓰레기가 있습니다. 다중 상속이 없기 때문에 개체에 대리자를 삽입하고 해당 메서드에 대한 래퍼 메서드를 만들어야 합니다. 셀라비.
나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.
글쎄, 언어는 반 리터가 없으면 냉정한 사람이 그것이 무엇인지 이해할 수 없습니다. :) 그리고이 OOPish bodyaga와 중국어 문자가 이혼 한 것에 대한 모든 것 - 절차 수준에서 사소하게 구현되는 간단한 데이터 교환 을 만들기 위해 ...
교육적인 베지크로서, 나는 어떤 이유로 아무도 무지하다고 부르지 않는 사람들의 OOP에 대한 위키에서 몇 가지 잘 알려진 비판적 인용문을 제공할 것입니다.
Alexander Stepanov 는 인터뷰 중 하나에서 OOP가 "방법론적으로 잘못"되었으며 "...OOP는 인공 지능과 거의 같은 사기입니다..."라고 지적했습니다. [20] .
Niklaus Wirth 는 OOP가 구조화된 프로그래밍에 대한 하찮은 상부 구조에 불과하다고 믿으며, 무엇보다도 프로그래밍 언어에 새로운 유행의 "객체 지향" 도구를 포함하는 것으로 표현되는 그 중요성의 과장은 해를 입힙니다. 개발 중인 소프트웨어의 품질.
Patrick Killelia 는 그의 책 Tuning Web Server에서 다음과 같이 썼습니다. "... OOP는 프로그램 속도를 늦추는 여러 가지 방법을 제공합니다..."
1950년생인 Stepanov, 1934년생인 Wirth, 그리고 동등하게 오래된 Killea(그의 책은 1998년에 출판됨)는 2017년에 이것을 반복하는 것을 매우 부끄러워할 것입니다.
그들이 말한 것은 너무 오래전 일이라 기억하기가 부끄럽습니다. C++ 컴파일러는 최적화에서 최소 2배 더 멍청하고 더 원시적이었습니다. 실제로 최적화의 냄새는 없었습니다. 그 당시(90년대 초반), 나 자신도 어셈블러에 많은 글을 썼고 "C/C ++ - 속도가 느려진다"는 같은 생각을 고수했습니다.
뽑아낸 인용문 형태의 Likbezik은 당신이 나를 위해 수행할 일이 아닙니다. 게다가, 당신은 이미 이 스레드에서 당신의 극도의 밀도와 공격적인 무지를 보여주기 위해 관리했습니다.
객체지향 프로그래밍이 효과적인 주된 이유는 모듈성과 선언성을 보장하는 수단이 포함되어 있기 때문입니다. 개발 효율성을 높이는 수단은 모듈성과 선언성입니다. "은빛 총알처럼." 방법론을 선택할 때 안내해야 할 것은 그들에게 있습니다. PLO 자체가 목표가 되어서는 안 된다."
객체지향 프로그래밍이 효과적인 주된 이유는 모듈성과 선언성을 보장하는 수단이 포함되어 있기 때문입니다. 개발 효율성을 높이는 수단은 모듈성과 선언성입니다. "은빛 총알처럼." 방법론을 선택할 때 안내해야 할 것은 그들에게 있습니다. PLO 자체가 목표가 되어서는 안 된다."
최소한의 의견을 수용할 수 있도록 개인적으로 구현한 프로젝트를 보여주십시오. 제공된 링크를 이해할 수도 없습니다. 출력을 포함하여 OOP에 대한 송가만 있습니다.
모든 소프트웨어의 거의 90%가 OOP로 작성되었습니다(드라이버에 대한 넌센스를 기억할 필요가 없음). 사실 OOP 없이 큰 프로젝트를 작성하고 유지하는 것은 불가능합니다. 그리고 비즈니스와 관련하여 "단지 래퍼"에 대한 단어는 허용되지 않습니다. 소프트웨어 개발은 오래 전부터 입증된 비즈니스입니다.
이해 없이 OOP에 대해 불평하는 사람은 현대 C++ 컴파일러가 무엇을 하는지 알지 못합니다. OOP의 최종 코드에는 종종 아무것도 남지 않습니다. 물론 C++에 대해 이야기하고 있습니다.
동시에 경험 을 잊지 마십시오 , 한 번 경험 한 (자신의 시간 내에) 사람들의 가장 오래된 진술을 꺼내려고 노력하십시오. 자신의 경험이 없기 때문에 찢어진 진술이 오랫동안 작동하지 않았다는 것을 이해하지 못합니다. 그리고 그들은 작동하지 않았지만 그 당시의 특징적인 망상이었습니다. 이러한 망상에 대해 기억하는 것은 이미 부끄러운 일입니다.
또한 제공된 링크에 쓰여진 내용의 본질을 실제로 이해하지 못하고 있습니다. "OOP가 목발보다 낫고(목발은 OOP 없이 OOP를 에뮬레이트하려는 시도임) 반드시 사용해야 합니다."
하지만 굴러가지 않습니다 :-)
나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.
생성 - 공장을 통해 삭제 - 일반적인 방법으로. 위임이 필요한지 여부는 라이브러리의 내용이 어떻게 사용되는지에 따라 결정됩니다. 라이브러리가 스스로 작업을 수행하는 클래스를 제공하는 경우 위임할 필요가 없습니다. 인터페이스 메서드를 호출하기만 하면 됩니다.
그건 그렇고, Android/Java 에는 코어 클래스와 유사한 쓰레기가 있습니다. 다중 상속이 없기 때문에 개체에 대리자를 삽입하고 해당 메서드에 대한 래퍼 메서드를 만들어야 합니다. 셀라비.
나는 당신에게 말하고 있습니다 - 그것을 시도하십시오. 그것은 엄청난 양의 코드입니다. 인스턴스화된 클래스 "СFoo: public InterfaceCFoo"는 InterfaceCFoo *privateContext 필드(1:1 연결 만들기)를 포함해야 하고, 팩토리를 통해 생성 및 삭제하고, 모든 메소드를 위임하고 동시에 CFoo* 링크를 번역해야 합니다.<->privateContext 이리저리. 이것은 "수동 일몰", 즉 상속을 위임에 의해 갑자기 교체하는 것입니다.
글쎄, 언어는 반 리터가 없으면 냉정한 사람이 그것이 무엇인지 이해할 수 없습니다. :) 그리고이 OOPish bodyaga와 중국어 문자가 이혼 한 것에 대한 모든 것 - 절차 수준에서 사소하게 구현되는 간단한 데이터 교환을 만들기 위해 ...
치열한 OOP 코더의 존재에 대해 OOP 자체를 탓할 수는 없습니다. 일반적으로 OOP에서는 모든 것이 정상이지만 OOP에 대한 의견은 완전히 틀립니다.
치열한 OOP 코더의 존재에 대해 OOP 자체를 탓할 수는 없습니다. 일반적으로 OOP에서는 모든 것이 정상이지만 OOP에 대한 의견은 완전히 틀립니다.
당신은 그의 이야기를 모릅니다.
직접 파괴에 대한 반복 금지. 따라서 그의 호전적인 무지에 반응하지 마십시오.
일반적으로 OOP에서는 모든 것이 정상이지만 OOP에 대한 의견은 완전히 틀립니다.
교육적인 베지크로서, 나는 어떤 이유로 아무도 무지하다고 부르지 않는 사람들의 OOP에 대한 위키에서 몇 가지 잘 알려진 비판적 인용문을 제공할 것입니다.
교육적인 베지크로서, 나는 어떤 이유로 아무도 무지하다고 부르지 않는 사람들의 OOP에 대한 위키에서 몇 가지 잘 알려진 비판적 인용문을 제공할 것입니다.
1950년생인 Stepanov, 1934년생인 Wirth, 그리고 동등하게 오래된 Killea(그의 책은 1998년에 출판됨)는 2017년에 이것을 반복하는 것을 매우 부끄러워할 것입니다.
그들이 말한 것은 너무 오래전 일이라 기억하기가 부끄럽습니다. C++ 컴파일러는 최적화에서 최소 2배 더 멍청하고 더 원시적이었습니다. 실제로 최적화의 냄새는 없었습니다. 그 당시(90년대 초반), 나 자신도 어셈블러에 많은 글을 썼고 "C/C ++ - 속도가 느려진다"는 같은 생각을 고수했습니다.
뽑아낸 인용문 형태의 Likbezik은 당신이 나를 위해 수행할 일이 아닙니다. 게다가, 당신은 이미 이 스레드에서 당신의 극도의 밀도와 공격적인 무지를 보여주기 위해 관리했습니다.
Renat Fatkhullin :
게다가, 당신은 이미 이 스레드에서 당신의 극도의 밀도와 공격적인 무지를 보여주기 위해 관리했습니다.
요약해보자. 여기 내 주요 OOP 가설이 있습니다. "OOP는 텍스트를 위한 편리한 래퍼로서만 의미가 있거나 런타임 초기화에서 최소한의 사용으로..." 게시물 #10입니다.
그리고 다음은 유사한 의견과 코드 수준에서 자세한 증거를 가진 독립 전문가의 합리적인 의견입니다.
http://rainman-rocks.livejournal.com/122876.html
"이 모든 것의 최종 결론은 다음과 같습니다.
객체지향 프로그래밍이 효과적인 주된 이유는 모듈성과 선언성을 보장하는 수단이 포함되어 있기 때문입니다. 개발 효율성을 높이는 수단은 모듈성과 선언성입니다. "은빛 총알처럼." 방법론을 선택할 때 안내해야 할 것은 그들에게 있습니다. PLO 자체가 목표가 되어서는 안 된다."
요약해보자. 여기 내 주요 OOP 가설이 있습니다. "OOP는 텍스트를 위한 편리한 래퍼로서만 의미가 있거나 런타임 초기화에서 최소한의 사용으로..." 게시물 #10입니다.
그리고 다음은 유사한 의견과 코드 수준에서 자세한 증거를 가진 독립 전문가의 합리적인 의견입니다.
http://rainman-rocks.livejournal.com/122876.html
"이 모든 것의 최종 결론은 다음과 같습니다.
객체지향 프로그래밍이 효과적인 주된 이유는 모듈성과 선언성을 보장하는 수단이 포함되어 있기 때문입니다. 개발 효율성을 높이는 수단은 모듈성과 선언성입니다. "은빛 총알처럼." 방법론을 선택할 때 안내해야 할 것은 그들에게 있습니다. PLO 자체가 목표가 되어서는 안 된다."
최소한의 의견을 수용할 수 있도록 개인적으로 구현한 프로젝트를 보여주십시오. 제공된 링크를 이해할 수도 없습니다. 출력을 포함하여 OOP에 대한 송가만 있습니다.
모든 소프트웨어의 거의 90%가 OOP로 작성되었습니다(드라이버에 대한 넌센스를 기억할 필요가 없음). 사실 OOP 없이 큰 프로젝트를 작성하고 유지하는 것은 불가능합니다. 그리고 비즈니스와 관련하여 "단지 래퍼"에 대한 단어는 허용되지 않습니다. 소프트웨어 개발은 오래 전부터 입증된 비즈니스입니다.
이해 없이 OOP에 대해 불평하는 사람은 현대 C++ 컴파일러가 무엇을 하는지 알지 못합니다. OOP의 최종 코드에는 종종 아무것도 남지 않습니다. 물론 C++에 대해 이야기하고 있습니다.
최소한의 의견을 수용할 수 있도록 개인적으로 구현한 프로젝트를 보여주십시오. 제공된 링크를 이해할 수도 없습니다. 출력을 포함하여 OOP에 대한 송가만 있습니다.
나는이 기사의 주요 아이디어에 대해 한 번 더 인용 할 것이므로 거기에 쓰여진 내용에 대해 의심의 여지가 없습니다.
"따라서 구조화된 절차적 프로그래밍을 대체하려는 OOP는 결국 거의 그것으로 돌아갔지만 유행하는 래퍼에만 있었습니다. 몇 가지 질문이 발생합니다. 조작에 어떤 포인트가 있었습니까? .."
죄송하지만 논리와 인과 관계를 이해하지 못합니다. 사람의 의견을 최소한으로 고려하기 위해 구현 된 프로젝트 가 필요한 이유는 무엇입니까? 일반적으로 문명화된 토론에서는 제시된 의견 자체에 대한 추론과 합리적인 정당성을 갖는 것으로 충분합니다.
그렇지 않으면 우리는 어떤 사람이 프로젝트를 구현했다면 그의 모든 후속 진술은 처음부터 모든 사람이 믿음으로 받아들여야 한다는 터무니없는 결론에 도달합니다. 또한 프로젝트를 실현한 다른 전문가의 의견.
다시 말하지만, 그것은 업보에 나쁜 영향을 미치기 때문에 자랑하는 것은 그다지 겸손하지 않습니다.
즉, 프로젝트 가 없으므로 경험이 없습니다.
동시에 경험 을 잊지 마십시오 , 한 번 경험 한 (자신의 시간 내에) 사람들의 가장 오래된 진술을 꺼내려고 노력하십시오. 자신의 경험이 없기 때문에 찢어진 진술이 오랫동안 작동하지 않았다는 것을 이해하지 못합니다. 그리고 그들은 작동하지 않았지만 그 당시의 특징적인 망상이었습니다. 이러한 망상에 대해 기억하는 것은 이미 부끄러운 일입니다.
또한 제공된 링크에 쓰여진 내용의 본질을 실제로 이해하지 못하고 있습니다. "OOP가 목발보다 낫고(목발은 OOP 없이 OOP를 에뮬레이트하려는 시도임) 반드시 사용해야 합니다."