Мнение редакции может не совпадать с мнением автора оригинала. По мнению многих, ООП является жемчужиной информатики. Идеальное решение для организации кода. Конец всем проблемам. Единственный верный способ написания программ. Дарован нам самим истинным Богом программирования. Но это не так. Люди начинают уступать под тяжестью абстракций и...
다음은 항상 방법입니다. 극단적인 관점. 망치와 망치 중 어느 것이 더 나은지에 대해 논쟁하는 것과 같습니다.
C#에서는 좋은 장작을 작성할 수 없지만 순수한 C에서는 심각한 응용 프로그램에서 분기된 논리적 연결을 설명하고 디버그할 수 있습니다.
그래서 기사는 아무것도 아닙니다.
물론 기사에는 약간의 진실이 있습니다 ... 글쎄, 적어도 상속은 실제로 필요하지 않은 메소드와 필드를 "끌어 올"것이지만 슬프게도 모든 비용을 지불해야합니다. 시간을 절약 할 수 있지만 메모리 사용량이나 솔루션의 전체 성능을 높일 수 있지만 5는 그렇게 슬프지 않습니다. 컴파일러 및 코드 최적화 수준은 이제 매우 시원하므로 짧은 개발 시간에 출력이 문제에 대한 좋은 솔루션인 경우가 많습니다.
C#에 대해 말하자면, 그의 목표는 다릅니다. 그는 특정 PC 또는 제한된 PC 그룹에서 빠르게 결과를 얻기 위한 순전히 "Windows 언어"입니다. 설치되지 않은 .Net 업데이트라도 치명적인 오류를 일으킬 수 있습니다. 액세스 권한이 없지만 비용이 많이 드는 PC에서 거래하기 위한 패널을 작성했습니다. C # 이미 확인했습니다. 가상 머신 에서 업데이트의 모든 "패치"가 설치되지 않은 경우 프로젝트가 예기치 않게 충돌할 수 있습니다. GitHub의 모든 새 항목은 새 .Net 어셈블리 아래에 게시됩니다. 당신은 당신의 성취에 의해서만 제한 될 것입니다
일반적으로 다른 곳과 마찬가지로 혁신은 "고통스럽고 길고 슬프다"고 IT 거물이 설정한 추세를 따라야 합니다. 그러면 모든 것이 신속하고 문제 없이 작성됩니다. 음, Microsoft는 OOP 스타일로 가능한 모든 것을 작성했습니다. 이 모든 것을 사용하려면 처음부터 모든 WinForm 등을 작성해야 합니다. Win-95))))))))
조금? ) 실제로 이것은 정확히 일어나는 일입니다. 그러나 저자는 미국을 발견하지 못했습니다. (적어도 저에게는) 뻔한 일처럼 보입니다. 경험이 있는 프로그래머라면 누구나 휘발성 상태의 문제에 대해 동일한 인식을 갖게 되는 것 같습니다. 그건 그렇고, 나는 최근에 매우 유사한 기사를 보았습니다. 단지 더 짧았습니다. 그러나 이것은 분명히 기능주의자와 oop-shniks 사이의 영원한 holivar입니다)
그러나 사실 아무도 OOP를 올바르게 사용하려고 애쓰지 않습니다. 저자 자신도 불변 객체를 사용할 수 있다고 언급합니다. 그리고 설명된 문제의 99%가 즉시 사라집니다. 저것들. 모든 것은 팔과 어깨의 머리의 직선성에 관한 문제에만 의존하며 사용된 패러다임에는 의존하지 않습니다.
물론 인기 있는 OOP 언어가 객체의 가변성을 제어하는 수단을 제공하지 않는다는 사실이 프로세스를 복잡하게 만듭니다. 따라서 const/readonly 대신 immutable 키워드를 사용하는 것이 좋습니다.
그러나 기능 언어 의 인기가없는 이유에 대해-여기서 나는 저자와 동의하지 않습니다. 요점은 내가 보기에 그러한 코드에 대한 보다 복잡한 인식에 있습니다. OOP와 FP의 반대만이 아니라 명령적 접근과 기능적 접근의 반대이기도 하다. 제 생각에는 첫 번째 것이 대부분의 사람들이 이해하기에 더 가깝고 직관적입니다. 저는 부재중 함수형 언어밖에 몰라서 객관적으로 판단할 수는 없지만, 람다가 오버로드된 코드를 보면 인지부조화에 빠지게 됩니다.) 너무 혼란스럽고 까다롭습니다. 그리고 아마 대부분의 사람들도 그렇게 생각할 것입니다.
게다가 함수형 언어는 외부 환경과의 상호 작용과 관련된 여러 작업을 위해 설계되지 않았습니다. 동일한 그래픽 인터페이스를 사용하십시오. 어떤 식 으로든 이벤트 사이의 전역 변경 상태를 저장해야 할 때 필요합니다.
조금? ) 실제로 이것은 정확히 일어나는 일입니다. 그러나 저자는 미국을 발견하지 못했습니다. (적어도 저에게는) 뻔한 일처럼 보입니다. 경험이 있는 프로그래머라면 누구나 휘발성 상태의 문제에 대해 동일한 인식을 갖게 되는 것 같습니다. 그건 그렇고, 나는 최근에 매우 유사한 기사를 보았습니다. 단지 더 짧았습니다. 그러나 이것은 분명히 기능주의자와 oop-shniks 사이의 영원한 holivar입니다)
그러나 사실 아무도 OOP를 올바르게 사용하려고 애쓰지 않습니다. 저자 자신도 변경할 수 없는 개체를 사용할 수 있다고 언급합니다. 그리고 설명된 문제의 99%가 즉시 사라집니다. 저것들. 모든 것은 팔과 어깨의 머리의 직선성에 관한 문제에만 의존하며 사용된 패러다임에는 의존하지 않습니다.
물론 인기 있는 OOP 언어가 객체의 가변성을 제어하는 수단을 제공하지 않는다는 사실이 프로세스를 복잡하게 만듭니다. 따라서 const/readonly 대신 immutable 키워드를 사용하는 것이 좋습니다.
어쨌든 가까운 장래에 아무 것도 바뀌지 않을 것입니다. IT 거물은 이 패러다임을 지원합니다. 아마도 이것이 유익할 것입니다. 소프트웨어 개발자가 작동하려면 더 강력한 하드웨어가 필요한 복잡한 구현을 수행하고 OS 또는 컴파일러에 대한 문서를 제출하도록 하는 것입니다. 기성 라이브러리는 대부분 OOP 형식으로 되어 있어 개발자에게 .... 무한정 ;)
OOP가 있는 이 이야기는 한때 의사들이 라틴어를 의무적으로 알고 있었기 때문에 필요하지 않은 것 같았지만 전문적인 수준의 의사 소통 수단으로 사용할 필요가 있었다고 가정할 수 있습니다.)
https://githut.info/ 에 자세한 통계가 있지만 14세입니다.
github에 대한 최신 통계 https://madnight.github.io/githut/#/pull_requests/2019/2
이 글 에 있는 전문가들의 의견을 모두 읽어보시면 도움이 되리라 생각합니다.
행운을 빕니다
이 글 에 있는 전문가들의 의견을 모두 읽어보시면 도움이 되리라 생각합니다.
기사의 모든 (절대적으로 편향된) 결론은 하나의 간단한 질문으로 평준화됩니다.
FP는 오랫동안 사용되어 왔으며, 그렇게 멋진데도 왜 여전히 작은 틈새 시장을 갖고 있습니까?
결코 내가 OOP가 최고의 개념이나 FP가 형편없는 옵션에서 곧바로 나왔다는 것을 의미하지는 않습니다.
기사의 모든 (절대적으로 편향된) 결론은 하나의 간단한 질문으로 평준화됩니다.
FP는 오랫동안 사용되어 왔으며, 그렇게 멋진데도 왜 여전히 작은 틈새 시장을 갖고 있습니까?
기사에 이 질문에 대한 답이 있습니다. 주의 깊게 읽지 않았습니다.
기사에 이 질문에 대한 답이 있습니다.
절대적으로 편향되어 있고 아무것도 아닙니다.
실제로 코드를 작성하는 개발자가 있습니다. 단어로 프로그래밍을 전혀 할 수 없는 관리자가 있습니다.
따라서 기술 스택은 개발자가 반드시 선택하는 것은 아닙니다. 그리고 특정 스택을 통해 팀이 문제를 보다 효율적으로 해결할 수 있다면 이를 이해하기 위해 기술을 소유하고 알 필요가 없습니다.
기사가 여전히 질문에 대한 답이라고 생각합니까?
이 글 에 있는 전문가들의 의견을 모두 읽어보시면 도움이 되리라 생각합니다.
행운을 빕니다
다음은 항상 방법입니다. 극단적인 관점. 망치와 망치 중 어느 것이 더 나은지에 대해 논쟁하는 것과 같습니다.
C#에서는 좋은 장작을 작성할 수 없지만 순수한 C에서는 심각한 응용 프로그램에서 분기된 논리적 연결을 설명하고 디버그할 수 있습니다.
그래서 기사는 아무것도 아닙니다.
다음은 항상 방법입니다. 극단적인 관점. 망치와 망치 중 어느 것이 더 나은지에 대해 논쟁하는 것과 같습니다.
C#에서는 좋은 장작을 작성할 수 없지만 순수한 C에서는 심각한 응용 프로그램에서 분기된 논리적 연결을 설명하고 디버그할 수 있습니다.
그래서 기사는 아무것도 아닙니다.
물론 기사에는 약간의 진실이 있습니다 ... 글쎄, 적어도 상속은 실제로 필요하지 않은 메소드와 필드를 "끌어 올"것이지만 슬프게도 모든 비용을 지불해야합니다. 시간을 절약 할 수 있지만 메모리 사용량이나 솔루션의 전체 성능을 높일 수 있지만 5는 그렇게 슬프지 않습니다. 컴파일러 및 코드 최적화 수준은 이제 매우 시원하므로 짧은 개발 시간에 출력이 문제에 대한 좋은 솔루션인 경우가 많습니다.
C#에 대해 말하자면, 그의 목표는 다릅니다. 그는 특정 PC 또는 제한된 PC 그룹에서 빠르게 결과를 얻기 위한 순전히 "Windows 언어"입니다. 설치되지 않은 .Net 업데이트라도 치명적인 오류를 일으킬 수 있습니다. 액세스 권한이 없지만 비용이 많이 드는 PC에서 거래하기 위한 패널을 작성했습니다. C # 이미 확인했습니다. 가상 머신 에서 업데이트의 모든 "패치"가 설치되지 않은 경우 프로젝트가 예기치 않게 충돌할 수 있습니다. GitHub의 모든 새 항목은 새 .Net 어셈블리 아래에 게시됩니다. 당신은 당신의 성취에 의해서만 제한 될 것입니다
일반적으로 다른 곳과 마찬가지로 혁신은 "고통스럽고 길고 슬프다"고 IT 거물이 설정한 추세를 따라야 합니다. 그러면 모든 것이 신속하고 문제 없이 작성됩니다. 음, Microsoft는 OOP 스타일로 가능한 모든 것을 작성했습니다. 이 모든 것을 사용하려면 처음부터 모든 WinForm 등을 작성해야 합니다. Win-95))))))))
물론 기사에 일리가 있습니다만...
조금? ) 실제로 이것은 정확히 일어나는 일입니다. 그러나 저자는 미국을 발견하지 못했습니다. (적어도 저에게는) 뻔한 일처럼 보입니다. 경험이 있는 프로그래머라면 누구나 휘발성 상태의 문제에 대해 동일한 인식을 갖게 되는 것 같습니다. 그건 그렇고, 나는 최근에 매우 유사한 기사를 보았습니다. 단지 더 짧았습니다. 그러나 이것은 분명히 기능주의자와 oop-shniks 사이의 영원한 holivar입니다)
그러나 사실 아무도 OOP를 올바르게 사용하려고 애쓰지 않습니다. 저자 자신도 불변 객체를 사용할 수 있다고 언급합니다. 그리고 설명된 문제의 99%가 즉시 사라집니다. 저것들. 모든 것은 팔과 어깨의 머리의 직선성에 관한 문제에만 의존하며 사용된 패러다임에는 의존하지 않습니다.
물론 인기 있는 OOP 언어가 객체의 가변성을 제어하는 수단을 제공하지 않는다는 사실이 프로세스를 복잡하게 만듭니다. 따라서 const/readonly 대신 immutable 키워드를 사용하는 것이 좋습니다.
그러나 기능 언어 의 인기가없는 이유에 대해-여기서 나는 저자와 동의하지 않습니다. 요점은 내가 보기에 그러한 코드에 대한 보다 복잡한 인식에 있습니다. OOP와 FP의 반대만이 아니라 명령적 접근과 기능적 접근의 반대이기도 하다. 제 생각에는 첫 번째 것이 대부분의 사람들이 이해하기에 더 가깝고 직관적입니다. 저는 부재중 함수형 언어밖에 몰라서 객관적으로 판단할 수는 없지만, 람다가 오버로드된 코드를 보면 인지부조화에 빠지게 됩니다.) 너무 혼란스럽고 까다롭습니다. 그리고 아마 대부분의 사람들도 그렇게 생각할 것입니다.
게다가 함수형 언어는 외부 환경과의 상호 작용과 관련된 여러 작업을 위해 설계되지 않았습니다. 동일한 그래픽 인터페이스를 사용하십시오. 어떤 식 으로든 이벤트 사이의 전역 변경 상태를 저장해야 할 때 필요합니다.
조금? ) 실제로 이것은 정확히 일어나는 일입니다. 그러나 저자는 미국을 발견하지 못했습니다. (적어도 저에게는) 뻔한 일처럼 보입니다. 경험이 있는 프로그래머라면 누구나 휘발성 상태의 문제에 대해 동일한 인식을 갖게 되는 것 같습니다. 그건 그렇고, 나는 최근에 매우 유사한 기사를 보았습니다. 단지 더 짧았습니다. 그러나 이것은 분명히 기능주의자와 oop-shniks 사이의 영원한 holivar입니다)
그러나 사실 아무도 OOP를 올바르게 사용하려고 애쓰지 않습니다. 저자 자신도 변경할 수 없는 개체를 사용할 수 있다고 언급합니다. 그리고 설명된 문제의 99%가 즉시 사라집니다. 저것들. 모든 것은 팔과 어깨의 머리의 직선성에 관한 문제에만 의존하며 사용된 패러다임에는 의존하지 않습니다.
물론 인기 있는 OOP 언어가 객체의 가변성을 제어하는 수단을 제공하지 않는다는 사실이 프로세스를 복잡하게 만듭니다. 따라서 const/readonly 대신 immutable 키워드를 사용하는 것이 좋습니다.
어쨌든 가까운 장래에 아무 것도 바뀌지 않을 것입니다. IT 거물은 이 패러다임을 지원합니다. 아마도 이것이 유익할 것입니다. 소프트웨어 개발자가 작동하려면 더 강력한 하드웨어가 필요한 복잡한 구현을 수행하고 OS 또는 컴파일러에 대한 문서를 제출하도록 하는 것입니다. 기성 라이브러리는 대부분 OOP 형식으로 되어 있어 개발자에게 .... 무한정 ;)
OOP가 있는 이 이야기는 한때 의사들이 라틴어를 의무적으로 알고 있었기 때문에 필요하지 않은 것 같았지만 전문적인 수준의 의사 소통 수단으로 사용할 필요가 있었다고 가정할 수 있습니다.)