주제와 파괴적인 토론에 대한 일종의 파괴적인 반응. 절차적 프로그래머인 저에게 OOP에서 spaggetization을 피하는 방법, 구문 분석하는 방법 및 다른 사람의 spagget을 사용하는 것이 합리적인지 여부를 알려주세요.
결국, OOP는 대부분 가독성과 명령 프로그래밍을 위한 것입니다. 큰 프로젝트를 위해. 잔고/계좌 자금의 최대 위험을 절대 통제하지 않고 첨부된 차트에 심볼을 거래하는 Expert Advisor는 큰 프로젝트라고 할 수 없습니다. 절차적 프로그래밍이 메모리 측면에서 충분하고 수익성이 있음을 의미합니다. /속도.
질문:
- 개인적인 경험에서 나온 OOP의 단점/장점(필수적)
- 개인적인 경험에서 FP의 마이너스/플러스(선언적).
그리고 전망에 대한 의견은 물론 특히 병렬 컴퓨팅 의 방향에서 흥미롭습니다. 양자 주제를 다룰 이유가 없습니다.
나는 스파게티제이션에 대해 전혀 이해하지 못했습니다.
모든 코드의 좋은 기능은 기능이 가능한 한 짧다는 것입니다. 그들 중 더 많은 것을 보자
예를 들어, OOP 속성의 절반은 사용 편의성을 위해 분리하려는 것입니다. 예를 들어, 여러 함수를 그룹으로 분리하고 해당 네임스페이스에 사용할 고유 변수를 제공합니다.
우리는 유형 저장 "클래스"로 작업하기 때문에 모든 변수를 미리 정의하여 특정 유형을 제공할 수 있습니다....
외부 API 생성에 편리합니다. 작업할 때 매우 자주 사용되는 클래스 참조(8바이트)로 작업할 수 있습니다.
예: 노드의 모든 연결 목록 등.
// 여기에 보이는 기능만 썼습니다. 보호된 메서드의 가능성과 속성 등에 대해 쓸 의미가 없음이 분명합니다. .... 말하자면 설탕일 뿐입니다.
FP 속성은 우리가 어딘가에서 하고 싶은 것입니다. 예를 들어, 우리는 함수에서 즉시 새 함수를 작성하고 싶습니다. 즉, 현재 함수를 분할하여 함수에서 현재 변수의 일부를 사용합니다. 실행을 다른 함수로 전송하기 위해 아직 계산이 수행되지 않은 보류 중인 함수를 코드 조각 형태로 전달하기만 하면 됩니다.
실제로 꽤 편리합니다.
동시에 코드의 전체 배포 속성은 그대로 유지됩니다. 사실, 우리는 어떤 함수를 받았는지 분명히 알고 있습니다. 이것은 OOP보다 계산할 때 더 빠를 것입니다. 한 함수에서 다른 함수로 매우 까다로운 계산 전송을 구성할 수 있습니다. 함수는 또한 이전 함수의 호출된 변수의 환경을 완전히 기억합니다. 이는 매우 훌륭합니다(사실 이것은 외부 범위에서 선언된 변수를 저장하는 것일 뿐임) . FP는 함수 의 주소를 설정할 수도 있습니다. 특별히 유용하지는 않지만 클래스처럼 배열에 저장합니다.
나는 인용된 기사와 결정론의 바로 그 개념을 기반으로 나의 두려움을 설명할 것이다. "spaggetization"(코드 자체의 복잡성과 계산 오류 찾기 작업)이 두려운 것은 무엇입니까? 따라서 이 기사에서 초점을 맞추는 것은 변수의 "쓰레기" 값 또는 함수의 비결정적 반환입니다.
나는 내 가변(진화) 구조로 신경망을 조립/훈련합니다. 그리고 그들에게는 값의 "쓰레기"가 갑자기 나오는 것이 매우 중요합니다.
기사에서와 같이 브레이크 페달에 압력을 가하면 페달이 당신을 신경 쓰지 않습니다. 사용중입니다. 그리고 처음에 조립(아키텍처 자동 선택) 및 신경망 훈련 시 "쓰레기"가 있다면 어떻게 조립/학습할까요?
나는 인용된 기사와 결정론의 바로 그 개념을 기반으로 나의 두려움을 설명할 것이다. "spaggetization"(코드 자체의 복잡성과 계산 오류 찾기 작업)이 두려운 것은 무엇입니까? 따라서 이 기사에서 초점을 맞추는 것은 변수의 "쓰레기" 값 또는 함수의 비결정적 반환입니다.
나는 내 가변(진화) 구조로 신경망을 조립/훈련합니다. 그리고 그들에게는 값의 "쓰레기"가 갑자기 나오는 것이 매우 중요합니다.
기사에서와 같이 브레이크 페달에 압력을 가하면 페달이 당신을 신경 쓰지 않습니다. 사용중입니다. 그리고 처음에 조립(아키텍처 자동 선택) 및 신경망 교육 시 "쓰레기"가 있는 경우 어떻게 조립/학습합니까?
OOP에서 "쓰레기"(비결정론)를 최대한 피하는 방법은 무엇입니까?
기사에서 일반적으로 이상하게도 그 사람은 const 변수의 유형을 지정하는 것을 분명히 잊었습니다. 마치 거기에 js가 있고 최소한 읽기 전용인 것처럼 말입니다. 그런 다음 그는 개체가 크기를 변경해서는 안 되는(상수여야 함) 어떤 이유로 상수가 아닐 때 오류가 있다고 쓰고 ..... 이를 기반으로 오류 가능성이 높다고 결론을 내립니다. OOP에서)))
일반적으로 OOP를 사용하면 변수의 범위를 제어할 수 있습니다. 반면에 FP는 함수에서 변수를 전달하는 것으로 간주됩니다. 유형은 기본적으로 이미 정의되어 있어야 합니다. 그들은 아마도 소수일 것입니다. 그리고 이동 중에도 이 기능을 확장할 수 있습니다.
그러한 "기사", 쓸데없는 이야기, 일반적인 문구, 적어도 의미를 누가 작성했는지는 분명하지 않습니다.
" 전체 코드는 혼란스럽고 지저분했습니다. 속어로 "스파게티"라고 하는 " - Toyota의 나쁜 프로그래머 때문에 OOP의 코드를 혼란스러운 것으로 간주합니다.
" 내장 OOP 기능은 혼란을 가중시킬 뿐입니다. " - 글쎄요, OOP 기능(C #)의 수가 지속적으로 증가하면서 논리, 기능을 사용하는 기능이 코드에 혼란을 더하면 더 이상 다음을 수행할 수 없게 됩니다. 간단한 코드를 작성하십시오. 응.
" 대부분의 객체 지향 언어에서 데이터는 참조로 전달됩니다. 즉, 프로그램의 다른 부분이 동일한 데이터 구조를 처리하고 변경할 수 있습니다.이는 프로그램을 전역 상태의 하나의 큰 덩어리로 만들고 원래 아이디어와 모순됩니다. 의 OOP " - 그리고 비공개 ,보호 ?
"... 이 인용문이 마음에 들지 않으면 일반적으로 비결정론이 좋지 않기 때문입니다. " - 예, 예측할 수 없는 GetMicrosecondCount, MathRand, CoptBuffer 함수, 모든 네트워크 함수 및 기타 함수는 버려야 합니다. 왜냐하면 결과는 외부 상태에 따라 다릅니다. 공포.
거기에서 대부분의 논쟁은 손가락에서 빨려 들어갑니다. OOP가 유효하지 않다는 것을 "증명하는" 일부 실험은 일반적으로 올바르지 않습니다. 일반 OOP 언어에서 sum(int, int b)은 내부에 += b와 같은 넌센스를 작성하더라도 항상 순수합니다. 다시 말하지만, 객체가 메서드 내에서 힙 할당된 경우 항상 보호됩니다. 그것을 호출한 메서드에만 참조가 있습니다. 맥박을 잃을 때까지 바꾸십시오. 참조 및 값 유형이 있습니다. 아무도 OOP 언어가 부작용 없이 순수 함수를 작성하는 것을 막지 못합니다. 예를 들어 표준 수학 함수. 예, 때로는 공유 리소스 없이는 할 수 없지만 이를 위한 편리한 스레드 안전 컬렉션이 있습니다. 결국 순수한 FP는 필연적으로 IO, BD, 네트워크 요청 및 기타 등등과 상호 작용하게 되며, 여기에서 가변성 데몬이 돌파하게 됩니다.
// 여기에 보이는 기능만 썼습니다. 보호된 메서드의 가능성과 속성 등에 대해 쓸 의미가 없음이 분명합니다. .... 말하자면 설탕일 뿐입니다.
FP 속성은 우리가 어딘가에서 하고 싶은 것입니다. 예를 들어, 우리는 함수에서 즉시 새로운 함수를 작성하고 싶습니다. 현재 함수를 나누면 함수에서 현재 변수의 일부를 사용할 것입니다. 실행을 다른 함수로 전송하기 위해 아직 계산이 수행되지 않은 보류 중인 함수를 코드 조각 형태로 전달하기만 하면 됩니다.
실제로 꽤 편리합니다.
글쎄, 누가 당신이 OOP에서 같은 일을 하는 것을 막고 있습니까? 예, 순전히 절차적인 언어로도? 함수 포인터를 다른 함수에 전달하고 지연된 실행을 수행합니다.
비동기는 일반적으로 깔끔한 디자인 패턴입니다. 순수 C로 비동기 코드를 작성할 수도 있습니다. 작업을 하나씩 수행하는 상태 머신을 만드는 것은 쉽습니다. 그건 그렇고, 나는 오랫동안 고려되었던 MQL의 지표로 이것을했습니다. 차트 속도를 늦추지 않고 완료 비율을 변경하는 아름다운 상태 표시줄을 표시합니다.
글쎄, 누가 당신이 OOP에서 같은 일을 하는 것을 막고 있습니까? 예, 순전히 절차적인 언어로도? 함수 포인터를 다른 함수에 전달하고 지연된 실행을 수행합니다.
비동기는 일반적으로 깔끔한 디자인 패턴입니다. 순수 C로 비동기 코드를 작성할 수도 있습니다. 작업을 하나씩 수행하는 상태 머신을 만드는 것은 쉽습니다. 그건 그렇고, 나는 오랫동안 고려되었던 MQL의 지표로 이것을했습니다. 차트 속도를 늦추지 않고 완료 비율을 변경하는 아름다운 상태 표시줄을 표시합니다.
)는 어셈블러에서도 수행할 수 있습니다. 문제는 어느 것이 더 쉬운가입니다.
그리고 나를 한 방향이나 다른 방향으로 두지 마십시오 .... 나는 한 가지를 지지하지 않습니다
주제와 파괴적인 토론에 대한 일종의 파괴적인 반응. 절차적 프로그래머인 저에게 OOP에서 spaggetization을 피하는 방법, 구문 분석하는 방법 및 다른 사람의 spagget을 사용하는 것이 합리적인지 여부를 알려주세요.
결국, OOP는 대부분 가독성과 명령 프로그래밍을 위한 것입니다. 큰 프로젝트를 위해. 잔고/계좌 자금의 최대 위험을 절대 통제하지 않고 첨부된 차트에 심볼을 거래하는 Expert Advisor는 큰 프로젝트라고 할 수 없습니다. 절차적 프로그래밍이 메모리 측면에서 충분하고 수익성이 있음을 의미합니다. /속도.
질문:
- 개인적인 경험에서 나온 OOP의 단점/장점(필수적)
- 개인적인 경험에서 FP의 마이너스/플러스(선언적).
그리고 전망에 대한 의견은 물론 특히 병렬 컴퓨팅 의 방향에서 흥미롭습니다. 양자 주제를 다룰 이유가 없습니다.
나는 스파게티제이션에 대해 전혀 이해하지 못했습니다.
모든 코드의 좋은 기능은 기능이 가능한 한 짧다는 것입니다. 그들 중 더 많은 것을 보자
예를 들어, OOP 속성의 절반은 사용 편의성을 위해 분리하려는 것입니다. 예를 들어, 여러 함수를 그룹으로 분리하고 해당 네임스페이스에 사용할 고유 변수를 제공합니다.
우리는 유형 저장 "클래스"로 작업하기 때문에 모든 변수를 미리 정의하여 특정 유형을 제공할 수 있습니다....
외부 API 생성에 편리합니다. 작업할 때 매우 자주 사용되는 클래스 참조(8바이트)로 작업할 수 있습니다.
예: 노드의 모든 연결 목록 등.
// 여기에 보이는 기능만 썼습니다. 보호된 메서드의 가능성과 속성 등에 대해 쓸 의미가 없음이 분명합니다. .... 말하자면 설탕일 뿐입니다.
FP 속성은 우리가 어딘가에서 하고 싶은 것입니다. 예를 들어, 우리는 함수에서 즉시 새 함수를 작성하고 싶습니다. 즉, 현재 함수를 분할하여 함수에서 현재 변수의 일부를 사용합니다. 실행을 다른 함수로 전송하기 위해 아직 계산이 수행되지 않은 보류 중인 함수를 코드 조각 형태로 전달하기만 하면 됩니다.
실제로 꽤 편리합니다.
동시에 코드의 전체 배포 속성은 그대로 유지됩니다. 사실, 우리는 어떤 함수를 받았는지 분명히 알고 있습니다. 이것은 OOP보다 계산할 때 더 빠를 것입니다. 한 함수에서 다른 함수로 매우 까다로운 계산 전송을 구성할 수 있습니다. 함수는 또한 이전 함수의 호출된 변수의 환경을 완전히 기억합니다. 이는 매우 훌륭합니다(사실 이것은 외부 범위에서 선언된 변수를 저장하는 것일 뿐임) . FP는 함수 의 주소를 설정할 수도 있습니다. 특별히 유용하지는 않지만 클래스처럼 배열에 저장합니다.
지연된 작업, 모든 종류의 비동기 함수, 병렬 계산을 위한 코드 작성 용이성
나는 인용된 기사와 결정론의 바로 그 개념을 기반으로 나의 두려움을 설명할 것이다. "spaggetization"(코드 자체의 복잡성과 계산 오류 찾기 작업)이 두려운 것은 무엇입니까? 따라서 이 기사에서 초점을 맞추는 것은 변수의 "쓰레기" 값 또는 함수의 비결정적 반환입니다.
나는 내 가변(진화) 구조로 신경망을 조립/훈련합니다. 그리고 그들에게는 값의 "쓰레기"가 갑자기 나오는 것이 매우 중요합니다.
기사에서와 같이 브레이크 페달에 압력을 가하면 페달이 당신을 신경 쓰지 않습니다. 사용중입니다. 그리고 처음에 조립(아키텍처 자동 선택) 및 신경망 훈련 시 "쓰레기"가 있다면 어떻게 조립/학습할까요?
OOP에서 "쓰레기"(비결정론)를 최대한 피하는 방법은 무엇입니까?
나는 인용된 기사와 결정론의 바로 그 개념을 기반으로 나의 두려움을 설명할 것이다. "spaggetization"(코드 자체의 복잡성과 계산 오류 찾기 작업)이 두려운 것은 무엇입니까? 따라서 이 기사에서 초점을 맞추는 것은 변수의 "쓰레기" 값 또는 함수의 비결정적 반환입니다.
나는 내 가변(진화) 구조로 신경망을 조립/훈련합니다. 그리고 그들에게는 값의 "쓰레기"가 갑자기 나오는 것이 매우 중요합니다.
기사에서와 같이 브레이크 페달에 압력을 가하면 페달이 당신을 신경 쓰지 않습니다. 사용중입니다. 그리고 처음에 조립(아키텍처 자동 선택) 및 신경망 교육 시 "쓰레기"가 있는 경우 어떻게 조립/학습합니까?
OOP에서 "쓰레기"(비결정론)를 최대한 피하는 방법은 무엇입니까?
기사에서 일반적으로 이상하게도 그 사람은 const 변수의 유형을 지정하는 것을 분명히 잊었습니다. 마치 거기에 js가 있고 최소한 읽기 전용인 것처럼 말입니다. 그런 다음 그는 개체가 크기를 변경해서는 안 되는(상수여야 함) 어떤 이유로 상수가 아닐 때 오류가 있다고 쓰고 ..... 이를 기반으로 오류 가능성이 높다고 결론을 내립니다. OOP에서)))
일반적으로 OOP를 사용하면 변수의 범위를 제어할 수 있습니다. 반면에 FP는 함수에서 변수를 전달하는 것으로 간주됩니다. 유형은 기본적으로 이미 정의되어 있어야 합니다. 그들은 아마도 소수일 것입니다. 그리고 이동 중에도 이 기능을 확장할 수 있습니다.
저것들. OOP에는 더 많은 초기 제어 기능이 있습니다.
그게 다야, 난 항상 의심해왔어
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23그러한 "기사", 쓸데없는 이야기, 일반적인 문구, 적어도 의미를 누가 작성했는지는 분명하지 않습니다.
" 전체 코드는 혼란스럽고 지저분했습니다. 속어로 "스파게티"라고 하는 " - Toyota의 나쁜 프로그래머 때문에 OOP의 코드를 혼란스러운 것으로 간주합니다.
" 내장 OOP 기능은 혼란을 가중시킬 뿐입니다. " - 글쎄요, OOP 기능(C #)의 수가 지속적으로 증가하면서 논리, 기능을 사용하는 기능이 코드에 혼란을 더하면 더 이상 다음을 수행할 수 없게 됩니다. 간단한 코드를 작성하십시오. 응.
" 대부분의 객체 지향 언어에서 데이터는 참조로 전달됩니다. 즉, 프로그램의 다른 부분이 동일한 데이터 구조를 처리하고 변경할 수 있습니다. 이는 프로그램을 전역 상태의 하나의 큰 덩어리로 만들고 원래 아이디어와 모순됩니다. 의 OOP " - 그리고 비공개 , 보호 ?
"... 이 인용문이 마음에 들지 않으면 일반적으로 비결정론이 좋지 않기 때문입니다. " - 예, 예측할 수 없는 GetMicrosecondCount, MathRand, CoptBuffer 함수, 모든 네트워크 함수 및 기타 함수는 버려야 합니다. 왜냐하면 결과는 외부 상태에 따라 다릅니다. 공포.
알겠습니다. 모든 것이 명확합니다.
그게 다야, 난 항상 의심했어
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23거기에서 대부분의 논쟁은 손가락에서 빨려 들어갑니다. OOP가 유효하지 않다는 것을 "증명하는" 일부 실험은 일반적으로 올바르지 않습니다. 일반 OOP 언어에서 sum(int, int b)은 내부에 += b와 같은 넌센스를 작성하더라도 항상 순수합니다. 다시 말하지만, 객체가 메서드 내에서 힙 할당된 경우 항상 보호됩니다. 그것을 호출한 메서드에만 참조가 있습니다. 맥박을 잃을 때까지 바꾸십시오. 참조 및 값 유형이 있습니다. 아무도 OOP 언어가 부작용 없이 순수 함수를 작성하는 것을 막지 못합니다. 예를 들어 표준 수학 함수. 예, 때로는 공유 리소스 없이는 할 수 없지만 이를 위한 편리한 스레드 안전 컬렉션이 있습니다. 결국 순수한 FP는 필연적으로 IO, BD, 네트워크 요청 및 기타 등등과 상호 작용하게 되며, 여기에서 가변성 데몬이 돌파하게 됩니다.
이상한 글....
양은 질로 변하는 성질을 가지고 있다.
무전기가 많을 경우 전자기 비호환성이 발생하여 작동이 중지될 수 있습니다.
코드의 스파게티 속성은 일반적으로 수량에서 비롯되며 여러 상태에서 많은 수로 래핑된 속성을 모두 고려하지 않습니다.
기능에서 피드백의 존재는 동일하게 이어질 것입니다. 히스테리시스는 여전히 농담)
작업 및 올바른 공식 이해 ...))))
// 여기에 보이는 기능만 썼습니다. 보호된 메서드의 가능성과 속성 등에 대해 쓸 의미가 없음이 분명합니다. .... 말하자면 설탕일 뿐입니다.
FP 속성은 우리가 어딘가에서 하고 싶은 것입니다. 예를 들어, 우리는 함수에서 즉시 새로운 함수를 작성하고 싶습니다. 현재 함수를 나누면 함수에서 현재 변수의 일부를 사용할 것입니다. 실행을 다른 함수로 전송하기 위해 아직 계산이 수행되지 않은 보류 중인 함수를 코드 조각 형태로 전달하기만 하면 됩니다.
실제로 꽤 편리합니다.
글쎄, 누가 당신이 OOP에서 같은 일을 하는 것을 막고 있습니까? 예, 순전히 절차적인 언어로도? 함수 포인터를 다른 함수에 전달하고 지연된 실행을 수행합니다.
비동기는 일반적으로 깔끔한 디자인 패턴입니다. 순수 C로 비동기 코드를 작성할 수도 있습니다. 작업을 하나씩 수행하는 상태 머신을 만드는 것은 쉽습니다. 그건 그렇고, 나는 오랫동안 고려되었던 MQL의 지표로 이것을했습니다. 차트 속도를 늦추지 않고 완료 비율을 변경하는 아름다운 상태 표시줄을 표시합니다.
글쎄, 누가 당신이 OOP에서 같은 일을 하는 것을 막고 있습니까? 예, 순전히 절차적인 언어로도? 함수 포인터를 다른 함수에 전달하고 지연된 실행을 수행합니다.
비동기는 일반적으로 깔끔한 디자인 패턴입니다. 순수 C로 비동기 코드를 작성할 수도 있습니다. 작업을 하나씩 수행하는 상태 머신을 만드는 것은 쉽습니다. 그건 그렇고, 나는 오랫동안 고려되었던 MQL의 지표로 이것을했습니다. 차트 속도를 늦추지 않고 완료 비율을 변경하는 아름다운 상태 표시줄을 표시합니다.
)는 어셈블러에서도 수행할 수 있습니다. 문제는 어느 것이 더 쉬운가입니다.
그리고 나를 한 방향이나 다른 방향으로 두지 마십시오 .... 나는 한 가지를 지지하지 않습니다
이상한 기사. OOP는 어떤 식으로든 절차 스타일과 다르지 않습니다. 기본적으로 모든 것이 절차적 스타일로 수행될 수 있지만 그 반대의 경우도 끔찍한 코드 팽창 없이는 불가능합니다. OOP는 근본적으로 다른 스타일이 아닌 상부 구조입니다.
기사가 절차가 아닌 기능에 관한 것이라면(잘못을 발견하면 명확하지 않음), 완전히 다른 적용 영역을 가진 것을 비교하는 이유는 무엇입니까?
토픽 스타터, 당신 자신이 뭔가를 쓰고 지금 당신은 무엇에 대해 이야기하고 있었습니까? 기능적 또는 절차적?
결국, OOP는 대부분 가독성과 명령 프로그래밍을 위한 것입니다. 큰 프로젝트를 위해.
나는 할 수 없다. 그러나 나는 그것에서 원시적인 것들을 사용합니다. 최근 에 매우 간단한 코드를 게시했습니다 .
나는 내가 결국 무엇을 봐야할지 이해하지 못했을 때 FP에서 쓰기 시작했습니다.
OOP의 기본 요소를 통해 완료됩니다. 아마도 나는 FP 기술을 잃었지만 여기서는 OOP가 훨씬 간단하고 읽기 쉬워 보였습니다.
코드는 매우 간단하고 짧습니다( description ). FP에 써보시면 비교해보는 것도 재미있을 것 같습니다.