OOP에 대한 흥미로운 해석
이것은 OOP의 문제가 아니라 OOP의 적용, 그리고 적용하는 사람들의 문제입니다. 그들은 또한 경험
특별한 열정, OOP의 도움으로 놀라운 글을 쓸 수 있다는 사실에서 오는 황홀감까지
난독화 된 코드 (심지어 경쟁). 그들은 이것에서 특별한 엘리트처럼 느껴집니다.
그들은 읽고, 읽고, 읽고, 읽었지만 전혀 그렇지 않은 자신만의 "GREAT BOOK"을 생각해 냈습니다.
계속 읽을 수 있습니다. 그것은 " 디자인 패턴"이라고합니다 - 인간의 언어로
"흐리고 이해하기 어렵고 혼란스러운 코드를 작성하는 최고의 기술"로 번역됩니다. 만약에
OOP를 현명하게 사용하는 것 - 이것은 매우, 매우 놀라운 일이며, 믿을 수 없을 정도로 단순화되고
삶을 더 쉽게 만듭니다.
그게 다야, 난 항상 의심했어
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23여기에서 이러한 기사는 이 FP와 각각 20개의 탭을 포함할 수 있는 복잡한 후크에 익숙하지 않은 사람들이 작성했을 가능성이 높다는 것을 이해해야 합니다....
Rigid FP는 다른 것입니다. 그런 다음 어떻게 든 기능의 일부를 미리 선언할 수 있다는 OOP의 간결함과 편리성에 대해 생각하기 시작합니다. ..... 사실 서로 비슷한 것입니다. 그러나 그러한 기사는 종종 절차 코드 만 마스터 한 사람들이 작성합니다. 이것은 FP에 가깝지도 않으므로 후크가 무엇인지와 그 열렬한 사용을 모른다면 FP에 대해 말할 수 없습니다.
또한 "죽는다"라는 기사에 나열된 많은 사람들이 언어 는 "FP와 OOP의 모든 기능을 지원하는데 왜 구부리는지 이상하다?! 그리고 그 중 몇 개 는 CIS에서 가장 높은 급여를 받는다.그것은 FP에 대한 "익사"에 대한 생각이 전혀 없는 OOP의 "스파게티제이션"에 관한 것이었습니다. 나에게 절차적 패러다임은 실제로 OOP보다 리소스 효율적입니다.
OOP 코드 자체가 더 길다는 사실에 대해? 네, 생성자가 있고 어떤 경우에는 코드가 더 길어집니다. 일반적으로 .... 기술적으로 FP를 배포하는 것이 기계어 코드를 생성하는 데 더 효율적이어야 합니다. 하지만 코드는 그렇지 않습니다. 더 간단해지고, 타이핑에 대해 말하면 일반 래퍼를 할 수 없습니다...
요즘에는 종종 서로의 혼합물을 찾을 수 있습니다. 방법은 서로 간섭하지 않습니다.
OOP 코드 자체가 더 길다는 사실에 대해? 네, 생성자가 있고 어떤 경우에는 코드가 더 길어집니다. 일반적으로 .... 기술적으로 FP를 배포하는 것이 기계어 코드를 생성하는 데 더 효율적이어야 합니다. 하지만 코드는 그렇지 않습니다. 더 간단해지고, 타이핑에 대해 말하면 일반 래퍼를 할 수 없습니다...
요즘 당신은 종종 하나와 다른 하나의 혼합물을 찾을 수 있습니다
OOP와 FP가 없으면 모든 것이 더 쉽고 빠르게 진행됩니다(예, "예쁜 것", 패널 등 없이). 그러나 때로는 자신의 코드조차 이해하기 어렵습니다.
OOP와 FP가 없으면 모든 것이 더 쉽고 빠르게 진행됩니다(예, "예쁜 것", 패널 등 없이). 그러나 때로는 자신의 코드조차 이해하기 어렵습니다.
먼저 둘 중 하나를 마스터하고 가급적이면 둘 다 마스터한 다음 가장 좋아하는 것을 결정합니다. 그리고 지금과 같은 접근 방식으로 시간이 지남에 따라 그가 이해하지 못하는 모든 것 (즉, 거의 모든 것)에 공격하는 Fedoseev로 변하십시오.
주제와 파괴적인 토론에 대한 일종의 파괴적인 반응. 절차적 프로그래머인 저에게 OOP에서 spaggetization을 피하는 방법, 구문 분석하는 방법 및 다른 사람의 spagget을 사용하는 것이 합리적인지 여부를 알려주세요.
결국, OOP는 대부분 가독성과 명령 프로그래밍을 위한 것입니다. 큰 프로젝트를 위해. 잔고/계좌 자금의 최대 위험을 절대 통제하지 않고 첨부된 차트에 심볼을 거래하는 Expert Advisor는 큰 프로젝트라고 할 수 없습니다. 절차적 프로그래밍이 메모리 측면에서 충분하고 수익성이 있음을 의미합니다. /속도.
질문:
- 개인적인 경험에서 나온 OOP의 단점/장점(필수적)
- 개인적인 경험에서 FP의 마이너스/플러스(선언적).
그리고 전망에 대한 의견은 물론 특히 병렬 컴퓨팅 의 방향에서 흥미롭습니다. 양자 주제를 다룰 이유가 없습니다.
절차적 프로그래머에게 OOP에서 "스패깅"을 피하는 방법을 알려주세요.
레시피는 인용된 기사에 나와 있습니다: 결정론적 기능을 작성하기 위해 노력하십시오.
, 구문 분석하는 방법과 다른 사람의 "스파게티"를 사용하는 것이 합리적입니까?
좋은 코드 예, 그러나 스파게티는 아닙니다.
결국, OOP는 대부분 가독성과 명령 프로그래밍을 위한 것입니다. 큰 프로젝트를 위해.
권리.
잔고/계좌 자금의 최대 위험을 절대 통제하지 않고 첨부된 차트에 심볼을 거래하는 Expert Advisor는 큰 프로젝트라고 할 수 없습니다. 절차적 프로그래밍이 메모리 측면에서 충분하고 수익성이 있음을 의미합니다. /속도.
호주로 여행하려면 비행기(PLO)를 이용하는 것이 더 편리하고, 이웃 도시로 여행하려면 자동차나 자전거(PP)로도 충분합니다. 목표를 달성하기 위해 더 편리한 수단을 선택하기만 하면 됩니다.
그게 다야, 난 항상 의심했어
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23