아니요, 당신이 잊는 능력이 위축된 암기 타이탄이라면 운이 좋은 것이고 OOP가 필요하지 않다는 것은 분명합니다. 그러나 모든 사람이 그렇게 운이 좋은 것은 아닙니다.
SanSanych는 OOP를 문서로 대체할 것을 제안합니다. 원칙적으로 이는 옵션이기도 하며 Peter가 제안한 구조에 훨씬 가깝습니다. Peter는 모든 문서를 "마음속에" 가지고 있는 반면 SanSanych는 문서(또는 전자 매체)에 문서를 가지고 있습니다.
어떤 식으로든 변수의 의미를 알아야 하지만 기억할 필요는 없습니다. 컨텍스트에서 명확하지 않은 경우 주석을 작성할 수 있습니다. 분명한 것 같습니다.
OOP를 사용하면 훨씬 더 많은 것을 기억하고 문서화해야 합니다. 즉, 언제 어떤 순간에 생성되고 소멸되는지, 어떤 특정 순간에 어떤 인터페이스를 통해 흐르는지, 최종 결과에 완전히 쓸모없는 유사한 마우스 소란 - 바로 여기에서 혼자라면 정신적으로 건강한 사람이라면 누구나 미쳐버리고 그의 뇌를 망가뜨릴 수 있습니다.
그건 그렇고, OOP를 반대하는 모든 사람들은 프로그램이 어셈블러로 작성된 시간을 기억하는 것이 좋습니다.
특히 - BIOS 및 DOS를 사용하여 파일 작업.
제 생각에는 절차적 접근 방식과 OOP 접근 방식의 차이점은 BIOS와 DOS를 사용하여 디스크로 작업할 때와 거의 같습니다.
BIOS와 DOS에는 디스크 작업에 필요한 모든 기능이 있습니다.
그러나 BIOS 기능이 있는 파일을 만들고 "Hello, world!"라고 작성하십시오. - 이것은 FAT 시스템이 있는 디스크의 경우에도 다소 심각한 문제입니다. 한때 나는 감히 이것을 했고 그것은 나에게 매우 어려웠다. DOS에서 이것은 하나의 기능으로 쉽게 수행됩니다.
BIOS를 사용하여 NTFS 시스템에 대해 이러한 파일을 만드는 것이 얼마나 어려운지 상상할 수 있습니다 ...
또한, 원숭이 작업을 다시 제안합니다. 정원에 정원을 가두기 위해 외부 변수의 경우 아무 것도 하지 않고 매개변수에 액세스할 수 있거나 생성자-소멸자와 모든 종류의 불필요한 골칫거리 없이 매개변수를 직접 전달할 수 있는 경우 관련 메모리 누수.
네, 들어가야 해요. 여기 문을 보여주세요. 아마도 클래스 생성자가 무엇인지 모를 것입니다.
그냥 공통 매개변수 - 클래스 내부에서 이미 볼 수 있지만 사용하는 것은 좋지 않습니다. OOP는 공통 공간에서 벗어날 수 있어 좋습니다.
직접 어떻습니까? 문을 통하지 않으면 벽을 제거합니까? 생성자를 통해 직접 전송으로도 보입니다. 매개변수는 new 없이도 객체를 생성할 때 즉시 전달할 수 있습니다. 클래스가 수락해야 하는 매개변수를 설명하기에는 너무 게으르다는 것이 밝혀졌습니다. 함수와 변수를 작성하기에는 너무 게으르신가요?
함수는 작성되어야 하고 변수는 어디에서나 그리고 OOP와 함께 선언되어야 합니다. OOP를 사용하는 경우에만 이것에 대해 훨씬 더 쓸모없는 소란이 생길 것이며, 모든 것이 미리 예측된다면 백 번 다시 작성하지 않도록 프로젝트의 마지막에 어떤 종류 의 데이터 구조 가 있게 될까요? 분명한 것 같습니다.
함수는 작성되어야 하고 변수는 어디에서나 그리고 OOP와 함께 선언되어야 합니다. OOP를 사용하는 경우에만 이것에 대해 훨씬 더 쓸모없는 소란이 생길 것이며, 모든 것이 미리 예측된다면 백 번 다시 작성하지 않도록 프로젝트의 마지막에 어떤 종류 의 데이터 구조 가 있게 될까요? 분명해 보인다.
더 소란스럽지만 게임이 양초의 가치가 있는 경우와 많은 경우가 있습니다. 일반적으로 치명적이지는 않습니다.
그래픽 인터페이스의 핵심(그런데 요소 프로토타입을 포함하는 proto-core도 있습니다. 2MB가 필요합니다. 내가 제공한 것과 같은 테이블로 구성됨)에는 수천 개의 변수가 포함되어 있습니다. 커널을 센터로 사용하지 않고 클래스와 구조에 변수를 흩뿌리고 다양한 액세스 제어를 통해 연결을 설정했다면 내 작업을 처리했을 것이라고 생각하십니까? - 절대 혼자가 아닙니다. 프로그램 엔터티의 수는 몇 배 증가했을 것입니다. 함수와 클래스 간의 코드 내 링크는 너무 복잡해져서 혼자서 작업을 계속할 수 없을 것입니다. 전체 메커니즘의 효율성이 전체적으로 떨어질 것입니다.
훨씬 더 빨리 한계에 도달하고 멈췄을 것입니다.
"내가 OOP를 사용 한다면 무엇을 얻을 수 있을까?"라는 질문을 스스로에게 여러 번 했습니다. 그리고 매번 매일의 연습에 의지하여 나는 지금까지 혼자 갈 수 없다는 것을 깨달았습니다.
Holivar를 위해 - R은 "접근 제어가 없는 일체형 휴지통" 모드에서 절대 역겹게 작성되었습니다. 범위, 보호 및 다중 세션이 없는 20년 전의 구식 접근 방식. 나는 혼자인 것처럼 글을 씁니다. 예, 프로젝트는 비전문 개발자에 의해 한 사람 아래 태어났습니다. 처음부터 다시 작성해야 합니다. 적어도 한 번.
MQL5에서 R로 일반 인터페이스를 만들자는 아이디어가 있었지만 더 깊이 파고든 후에는 즉시 통합을 거부했습니다. 시스템은 데이터와 세션을 보호할 수 없습니다.
프로그래머가 엄격한 요구 사항(적어도 몇 년 동안 손을 대는 일)이 있는 일반 개발 팀에서 일할 때까지는 정상적인 의미의 개발자가 될 수 없습니다. 우리는 후보자를 고려할 때 시험 항목을 볼 때 90%의 시간을 머리를 잡습니다. 개발 산업 전반에 걸친 공포.
따라서 다시 한 번 반복합니다. PLO의 반대자들은 여기서 일종의 희극을 보여주고 있습니다.
다시 한 번 죄송합니다.
레나트, 긴장하지 마세요. 나 자신은 R의 지지자가 아닙니다. 당신은 훌륭한 리더이자 프로그래머입니다. 포럼의 외침을 마음으로 받아들이지 마십시오.
그게 다야, 특정 사람의 말이다. 정신분열증을 앓지 않는 프로그래머가 디버깅을 하고 있는 자신의 코드 일부에 대한 액세스를 숨기기 위해 왜 엄청난 노력을 기울여야 할까요? 손을 묶는 것이 낫지 않을까요? :)
글쎄, 나는 이미 말했다 - Peter가 위에서 제공한 구조 파일로 작업을 시도하십시오. 거기에서 필요한 데이터를 "캐치"한 다음 올바른 위치에 다시 입력하십시오.
그리고 동일한 구조의 작은 부분을 제공하는 "잘린" 인터페이스에서 필요한 데이터를 얻는 것과 비교하십시오. 인터페이스를 사용하면 다른 것을 얻거나 "잘못된 위치에" 무언가를 쓸 수 있는 방법이 없습니다.
아니요, 당신이 잊는 능력이 위축된 암기 타이탄이라면 운이 좋은 것이고 OOP가 필요하지 않다는 것은 분명합니다. 그러나 모든 사람이 그렇게 운이 좋은 것은 아닙니다.
SanSanych는 OOP를 문서로 대체할 것을 제안합니다. 원칙적으로 이는 옵션이기도 하며 Peter가 제안한 구조에 훨씬 가깝습니다. Peter는 모든 문서를 "마음속에" 가지고 있는 반면 SanSanych는 문서(또는 전자 매체)에 문서를 가지고 있습니다.
그리고 여기서이 "공포"가 보여지는 것이 흥미 롭습니다.
그건 그렇고, Renat Fatkhullin은 실제로 예를 보는 것이 흥미로울 것입니다 ...
아니요, 당신이 잊는 능력이 위축된 암기 타이탄이라면 운이 좋은 것이고 OOP가 필요하지 않다는 것은 분명합니다. 그러나 모든 사람이 그렇게 운이 좋은 것은 아닙니다.
SanSanych는 OOP를 문서로 대체할 것을 제안합니다. 원칙적으로 이는 옵션이기도 하며 Peter가 제안한 구조에 훨씬 가깝습니다. Peter는 모든 문서를 "마음속에" 가지고 있는 반면 SanSanych는 문서(또는 전자 매체)에 문서를 가지고 있습니다.
어떤 식으로든 변수의 의미를 알아야 하지만 기억할 필요는 없습니다. 컨텍스트에서 명확하지 않은 경우 주석을 작성할 수 있습니다. 분명한 것 같습니다.
OOP를 사용하면 훨씬 더 많은 것을 기억하고 문서화해야 합니다. 즉, 언제 어떤 순간에 생성되고 소멸되는지, 어떤 특정 순간에 어떤 인터페이스를 통해 흐르는지, 최종 결과에 완전히 쓸모없는 유사한 마우스 소란 - 바로 여기에서 혼자라면 정신적으로 건강한 사람이라면 누구나 미쳐버리고 그의 뇌를 망가뜨릴 수 있습니다.
그건 그렇고, OOP를 반대하는 모든 사람들은 프로그램이 어셈블러로 작성된 시간을 기억하는 것이 좋습니다.
특히 - BIOS 및 DOS를 사용하여 파일 작업.
제 생각에는 절차적 접근 방식과 OOP 접근 방식의 차이점은 BIOS와 DOS를 사용하여 디스크로 작업할 때와 거의 같습니다.
BIOS와 DOS에는 디스크 작업에 필요한 모든 기능이 있습니다.
그러나 BIOS 기능이 있는 파일을 만들고 "Hello, world!"라고 작성하십시오. - 이것은 FAT 시스템이 있는 디스크의 경우에도 다소 심각한 문제입니다. 한때 나는 감히 이것을 했고 그것은 나에게 매우 어려웠다. DOS에서 이것은 하나의 기능으로 쉽게 수행됩니다.
BIOS를 사용하여 NTFS 시스템에 대해 이러한 파일을 만드는 것이 얼마나 어려운지 상상할 수 있습니다 ...
자세히 읽어보십시오. 클래스 생성자가 아니라 클래스에 대한 것입니다.
또한, 원숭이 작업을 다시 제안합니다. 정원에 정원을 가두기 위해 외부 변수의 경우 아무 것도 하지 않고 매개변수에 액세스할 수 있거나 생성자-소멸자와 모든 종류의 불필요한 골칫거리 없이 매개변수를 직접 전달할 수 있는 경우 관련 메모리 누수.
네, 들어가야 해요. 여기 문을 보여주세요. 아마도 클래스 생성자가 무엇인지 모를 것입니다.
그냥 공통 매개변수 - 클래스 내부에서 이미 볼 수 있지만 사용하는 것은 좋지 않습니다. OOP는 공통 공간에서 벗어날 수 있어 좋습니다.
직접 어떻습니까? 문을 통하지 않으면 벽을 제거합니까? 생성자를 통해 직접 전송으로도 보입니다. 매개변수는 new 없이도 객체를 생성할 때 즉시 전달할 수 있습니다. 클래스가 수락해야 하는 매개변수를 설명하기에는 너무 게으르다는 것이 밝혀졌습니다. 함수와 변수를 작성하기에는 너무 게으르신가요?
스토푸도 당신은 쓰여진 것을 이해하지 못했습니다))
Dmitry Fedoseev :
함수와 변수를 작성하는 것이 너무 게으르신가요?
함수는 작성되어야 하고 변수는 어디에서나 그리고 OOP와 함께 선언되어야 합니다. OOP를 사용하는 경우에만 이것에 대해 훨씬 더 쓸모없는 소란이 생길 것이며, 모든 것이 미리 예측된다면 백 번 다시 작성하지 않도록 프로젝트의 마지막에 어떤 종류 의 데이터 구조 가 있게 될까요? 분명한 것 같습니다.
함수는 작성되어야 하고 변수는 어디에서나 그리고 OOP와 함께 선언되어야 합니다. OOP를 사용하는 경우에만 이것에 대해 훨씬 더 쓸모없는 소란이 생길 것이며, 모든 것이 미리 예측된다면 백 번 다시 작성하지 않도록 프로젝트의 마지막에 어떤 종류 의 데이터 구조 가 있게 될까요? 분명해 보인다.
더 소란스럽지만 게임이 양초의 가치가 있는 경우와 많은 경우가 있습니다. 일반적으로 치명적이지는 않습니다.
더 소란스럽지만 게임이 양초의 가치가 있는 경우와 많은 경우가 있습니다. 일반적으로 치명적이지는 않습니다.
얼마나 오랫동안 당신의 라이브러리를 살펴보았습니까?
2년 연속 작업.
그래픽 인터페이스의 핵심(그런데 요소 프로토타입을 포함하는 proto-core도 있습니다. 2MB가 필요합니다. 내가 제공한 것과 같은 테이블로 구성됨)에는 수천 개의 변수가 포함되어 있습니다. 커널을 센터로 사용하지 않고 클래스와 구조에 변수를 흩뿌리고 다양한 액세스 제어를 통해 연결을 설정했다면 내 작업을 처리했을 것이라고 생각하십니까? - 절대 혼자가 아닙니다. 프로그램 엔터티의 수는 몇 배 증가했을 것입니다. 함수와 클래스 간의 코드 내 링크는 너무 복잡해져서 혼자서 작업을 계속할 수 없을 것입니다. 전체 메커니즘의 효율성이 전체적으로 떨어질 것입니다.
훨씬 더 빨리 한계에 도달하고 멈췄을 것입니다.
"내가 OOP를 사용 한다면 무엇을 얻을 수 있을까?"라는 질문을 스스로에게 여러 번 했습니다. 그리고 매번 매일의 연습에 의지하여 나는 지금까지 혼자 갈 수 없다는 것을 깨달았습니다.
또한 내 생각은 이미 구조화되어 있으므로 이와 관련하여 OOP가 필요하지 않습니다.
Holivar를 위해 - R은 "접근 제어가 없는 일체형 휴지통" 모드에서 절대 역겹게 작성되었습니다. 범위, 보호 및 다중 세션이 없는 20년 전의 구식 접근 방식. 나는 혼자인 것처럼 글을 씁니다. 예, 프로젝트는 비전문 개발자에 의해 한 사람 아래 태어났습니다. 처음부터 다시 작성해야 합니다. 적어도 한 번.
MQL5에서 R로 일반 인터페이스를 만들자는 아이디어가 있었지만 더 깊이 파고든 후에는 즉시 통합을 거부했습니다. 시스템은 데이터와 세션을 보호할 수 없습니다.
프로그래머가 엄격한 요구 사항(적어도 몇 년 동안 손을 대는 일)이 있는 일반 개발 팀에서 일할 때까지는 정상적인 의미의 개발자가 될 수 없습니다. 우리는 후보자를 고려할 때 시험 항목을 볼 때 90%의 시간을 머리를 잡습니다. 개발 산업 전반에 걸친 공포.
따라서 다시 한 번 반복합니다. PLO의 반대자들은 여기서 일종의 희극을 보여주고 있습니다.
다시 한 번 죄송합니다.
레나트, 긴장하지 마세요. 나 자신은 R의 지지자가 아닙니다. 당신은 훌륭한 리더이자 프로그래머입니다. 포럼의 외침을 마음으로 받아들이지 마십시오.
귀하와 Rashid, 귀하의 팀의 건강과 창의적인 성공을 기원합니다!