2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
같은 것을 얼마나 반복할 수 있습니까? OOP는 코드를 구조화 하는 수단일 뿐만 아니라 절차적 프로그래밍에 없는 메커니즘도 가지고 있습니다.
이것은 아마도 사람이 산을 보지 못했다면 그것이 무엇인지 이해하지 못할 것입니다. 적어도 그에게 말하십시오.
Holivar를 위해 - R은 "접근 제어가 없는 일체형 휴지통" 모드에서 절대 역겹게 작성되었습니다. 범위, 보호 및 다중 세션이 없는 20년 전의 구식 접근 방식. 나는 혼자인 것처럼 글을 씁니다. 예 , 프로젝트 는 비전문 개발자에 의해 한 사람 아래 태어났습니다. 처음부터 다시 작성해야 합니다. 적어도 한 번.
MQL5에서 R로 일반 인터페이스를 만들자는 아이디어가 있었지만 더 깊이 파고든 후에는 즉시 통합을 거부했습니다. 시스템은 데이터와 세션을 보호할 수 없습니다.
프로그래머가 엄격한 요구 사항(적어도 몇 년 동안 손을 대는 일)이 있는 일반 개발 팀에서 일할 때까지는 정상적인 의미의 개발자가 될 수 없습니다. 우리는 후보자를 고려할 때 시험 항목을 볼 때 90%의 시간을 머리를 잡습니다. 개발 산업 전반에 걸친 공포.
따라서 다시 한 번 반복합니다. PLO의 반대자들은 여기서 일종의 희극을 보여주고 있습니다.
Реter Konow : OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 필요한지 아닌지는 개발자가 결정합니다. 메커니즘의 효율성을 높이는 것과는 관련이 없습니다. 구조적 사고, 그렇습니다. 제대로 구성되었는지 여부는 알 수 없습니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
클래스에는 내부 변수만 있고 입력 또는 출력이 없습니다... 외부 세계와 접촉하지 않고 자체 주스에서 끓는 그러한 객체의 프로그래밍에서 사용을 본 적이 있습니까?
왜 본 적도 없는 이야기를 하는 거지? 클래스 생성자가 생성되고 매개변수를 원하는 수만큼 수신할 수 있습니다. 다른 자식 클래스는 생성자에서 완전히 다른 매개 변수 집합을 가질 수 있습니다. 예, 단순히 매개변수를 설정하는 메소드를 작성할 수 있습니다.
1. 이것은 OOP의 필요성에 대한 주요 답변입니다.
2. 팀 경험의 문제입니다. 나는 2008-2009년에 필요한 모든 것을 썼습니다. 몇 년 전에 나는 더 많은 것을 쓰기로 결정했습니다. 모든 것이 읽을 수 있고 문제가 없습니다.
귀하의 답변에서 나는 한 가지를 이해했습니다. OOP는 프로그래밍 원칙을 도입하고 균일성을 도입하는 일종의 표준이며 이를 기반으로 초기 오류가 적고 가장 중요하고 가장 중요한 것은 수정 중 문제가 근본적으로 감소한다는 것입니다. 그러나 GOST, 개발 단계, 문서를 주의 깊게 준수하여 동일한 결과를 얻었습니다.
같은 것을 얼마나 반복할 수 있습니까? OOP는 코드를 구조화 하는 수단일 뿐만 아니라 절차적 프로그래밍에 없는 메커니즘도 가지고 있습니다.
이것은 아마도 사람이 산을 보지 못했다면 그것이 무엇인지 이해하지 못할 것입니다. 적어도 그에게 말하십시오.
저는 개인적으로 솔루션의 보편성을 위해 노력합니다. 이를 위해서는 코드 양을 늘리지 않고 유사한 기능을 하나의 블록으로 "연결"해야 합니다. 메커니즘의 효율성을 높이고 과부하 및 분리가 필요하지 않습니다. 두뇌를 사용하면 됩니다.)
즉, 각각 20줄씩 2개의 기능이 있었다. 둘 다 유사한 작업을 수행하거나 동일한 유형의 작업을 해결합니다. 내 목표는 두 기능의 작업을 수행하는 20줄 이하의 코드로 된 하나의 기능으로 만드는 것입니다. 이것이 내가 블록을 얻는 방법입니다.
얼마나 오랫동안 당신의 라이브러리를 살펴보았습니까?
Holivar를 위해 - R은 "접근 제어가 없는 일체형 휴지통" 모드에서 절대 역겹게 작성되었습니다. 범위, 보호 및 다중 세션이 없는 20년 전의 구식 접근 방식. 나는 혼자인 것처럼 글을 씁니다. 예 , 프로젝트 는 비전문 개발자에 의해 한 사람 아래 태어났습니다. 처음부터 다시 작성해야 합니다. 적어도 한 번.
MQL5에서 R로 일반 인터페이스를 만들자는 아이디어가 있었지만 더 깊이 파고든 후에는 즉시 통합을 거부했습니다. 시스템은 데이터와 세션을 보호할 수 없습니다.
프로그래머가 엄격한 요구 사항(적어도 몇 년 동안 손을 대는 일)이 있는 일반 개발 팀에서 일할 때까지는 정상적인 의미의 개발자가 될 수 없습니다. 우리는 후보자를 고려할 때 시험 항목을 볼 때 90%의 시간을 머리를 잡습니다. 개발 산업 전반에 걸친 공포.
따라서 다시 한 번 반복합니다. PLO의 반대자들은 여기서 일종의 희극을 보여주고 있습니다.
다시 한 번 죄송합니다.
기절!
나는 현대 프로그래밍에서 먹은 계란의 수준 문제를 더 갑자기 혼란스럽게 만드는 다른 가능성이 있는지 궁금합니다.
교통 체증에 빠진 차에 다가가 작동 방식을 살펴보고 운전자에게 말하세요. "좀 더 급작스럽게 문제를 혼동하고 100미터를 걸어갈 수 있는 방법이 없을까요?"
내 경험에서 알 수 있듯이 모든 전역 변수 가 포함된 단일 템플릿에서 복사-붙여넣기를 사용하여 만든 "문제 없는" Expert Advisors보다 "엉킨 문제"를 파악하는 것이 훨씬 쉽습니다.
왜 본 적도 없는 이야기를 하는 거지? 클래스 생성자가 생성되고 매개변수를 원하는 수만큼 수신할 수 있습니다.
자세히 읽어보십시오. 클래스 생성자가 아니라 클래스에 대한 것입니다.
또한, 원숭이 작업을 다시 제안합니다. 정원에 정원을 가두기 위해 외부 변수의 경우 아무 것도 하지 않고 매개변수에 액세스할 수 있거나 생성자-소멸자와 모든 종류의 불필요한 골칫거리 없이 매개변수를 직접 전달할 수 있는 경우 관련 메모리 누수.
내 OnInit()은 거의 동일하게 보입니다 - 12줄...
그래서 무엇?
그것에 관해서는 모든 고문에 12 줄이 있습니다 (포함 및 주석 제외).
여기 하나의 Expert Advisor에는 한 번에 3개의 완전히 다른 TS가 있습니다. 그들은 서로 간섭하지 않고 동시에 작동합니다.
적절한 팩토리를 선언하고 이를 함수에 반환하는 코드를 작성하여 추가 TS를 추가할 수 있습니다.
그러나 진짜 문제는 코드에 줄이 적거나 많은지 여부가 아닙니다. 문제는 필요한 경우 유지 관리하고 수정하는 것이 얼마나 쉬운가 하는 것입니다.
SanSanych, Peter가 제공한 테이블 파일을 쉽게 알 수 있습니까? 그리고 당신은 그것을 쉽게 수정할 수 있습니까? 글쎄, 당신은 Peter처럼 OOP가 필요하지 않습니다.
OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 필요한지 아닌지는 개발자가 결정합니다. 메커니즘의 효율성을 높이는 것과는 관련이 없습니다. 구조적 사고, 그렇습니다. 제대로 구성되었는지 여부는 알 수 없습니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
정확히. 이것이 캡슐화의 본질입니다.
상속과 다형성 도 있습니다.
OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
그게 다야, 특정 사람의 말이다. 정신분열증을 앓지 않는 프로그래머가 디버깅을 하고 있는 자신의 코드 일부에 대한 액세스를 숨기기 위해 왜 엄청난 노력을 기울여야 할까요? 손을 묶는 것이 낫지 않을까요? :)
프로그래머가 엄격한 요구 사항(적어도 몇 년 동안 손을 대는 일)이 있는 일반 개발 팀에서 일할 때까지는 정상적인 의미의 개발자가 될 수 없습니다. 우리는 후보자를 고려할 때 시험 항목을 볼 때 90%의 시간을 머리를 잡습니다. 개발 산업 전반에 걸친 공포.
그리고 여기서이 "공포"가 보여지는 것이 흥미 롭습니다.
나는 이것이 OOP의 사용 때문이라고 가정할 수 있습니다. 절차적 프로그래밍에서 초점은 알고리즘의 논리에 있고 어떤 밀도의 포리스트를 쌓기 매우 쉬운 외부 OOP 추가 기능에 있지 않기 때문입니다.