OOP 대 절차 프로그래밍
나는 여기서 holivar를 만들고 싶지 않지만 OOP 지지자가 OOP가 없는 솔루션보다 이 솔루션이 더 효율적이라는 것을 분명히 알 수 있는 일부 문제를 해결하는 코드를 여기에 제공할 수 있는지 궁금합니다.
저는 OOP가 없는 문제 해결사이고 OOP가 있는 문제 해결사와 경쟁하고 싶습니다.
나는 여기서 holivar를 만들고 싶지 않지만 OOP 지지자가 OOP가 없는 솔루션보다 이 솔루션이 더 효율적이라는 것을 분명히 알 수 있는 일부 문제를 해결하는 코드를 여기에 제공할 수 있는지 궁금합니다.
저는 OOP가 없는 문제 해결사이고 OOP 가 있는 문제 해결사와 경쟁하고 싶습니다 .
이것은 비교를 재현할 수 있는 플랫폼이 아닙니다. 프로그램은 한 페이지(단일 파일)입니다. 여기에서 원하는 대로 작성할 수 있으며 프로그램에 대한 성능과 액세스 권한은 거의 동일한 수준으로 유지됩니다. 비록 OOP에서도 절차적이라 할지라도 어떤 스타일의 작문에서도 쓰레기를 망칠 수 있습니다.
이것은 비교를 재현할 수 있는 플랫폼이 아닙니다. 프로그램은 한 페이지(단일 파일)입니다. 여기에서 원하는 대로 작성할 수 있으며 프로그램에 대한 성능과 액세스 권한은 거의 동일한 수준으로 유지됩니다. 비록 OOP에서도 절차적이라 할지라도 어떤 스타일의 작문에서도 쓰레기를 망칠 수 있습니다.
나는 당신을 잘 이해하지 못했습니다. "단일 페이지 프로그램"은 무엇을 의미합니까? 한 문제의 솔루션을 두 가지 다른 접근 방식으로 간단하게 비교할 수 있습니다. 비교할 때 주요 기준인 솔루션 자체, 코드 간결성, 코드 가독성 에 따라 각 솔루션을 평가합니다.
프로그래밍의 주요 기준은 이러한 기준입니다.
- www.metatrader5.com
수백 줄의 코드 블록을 작성합니다. 거의 노코멘트. 아니요. 러시아어 코드. 모든 것이 매우 효율적으로 작동합니다. 약 100개의 연결된 파일이 있지만 프로그램의 방향에는 문제가 없습니다. 아마도 이미 익숙해져서 오랫동안 모든 것을 기억했기 때문일 것입니다. 따라서 가장 중요한 것은 프로그램을 알고 잘 이해하는 것이며 나머지는 부차적입니다. 임호.
작업의 "효율성"에 관해서는 논쟁의 여지가 있습니다.
수정 가능성도 마찬가지입니다. 코드가 다른 정밀도의 따옴표에 사용되는 경우 변경이 필요하고 구현하기 쉬울까요?
그러한 프로젝트 의 주요 문제는 단지 변경하는 것입니다. 실습에서 알 수 있듯이 블록이 많을수록 수정 중에 오류가 발생할 가능성이 높아집니다. 댓글이 없는 것은 플러스가 아니라 마이너스입니다. 그렇기 때문에 기억해야 할 것이 많다.
나는 여기서 holivar를 만들고 싶지 않지만 OOP 지지자가 OOP가 없는 솔루션보다 이 솔루션이 더 효율적이라는 것을 분명히 알 수 있는 일부 문제를 해결하는 코드를 여기에 제공할 수 있는지 궁금합니다.
저는 OOP가 없는 문제 해결사이고 OOP가 있는 문제 해결사와 경쟁하고 싶습니다.
나는 이미 위에서 그러한 코드를 제공했습니다. 거래 내역 작업이 수행되는 완전히 가상 인터페이스가 있습니다. 나는 현재 위치 와 다른 유사한 장소에서 작업할 때 동일한 시스템을 사용했습니다.
OOP 덕분에 헤징 또는 네팅 시스템 여부에 관계없이 MT4와 MT5, 그리고 MT5에서 작업의 완전한 통합이 수행됩니다.
또한 OOP 덕분에 하나의 Expert Advisor 내에서 마법이 다른 여러 TS를 쉽게 사용할 수 있습니다.
본질적으로 OOP는 코드 유지 관리를 단순화하기 위해 발명되었습니다. 동시에 글을 쓰는 시점에 높은 비용을 지불해야 합니다. 코드를 작성하고 수정하지 않고 사용하고 삭제하면 실제로 OOP를 엉망으로 만들 의미가 없습니다. OOP는 여러 곳에서 동일한 코드가 필요하고 주기적으로 변경해야 하는 경우에 유리합니다.
따라서 OOP의 범위와 미적용은 코드를 지원하고 변경해야 할 필요성에 따라 정확하게 결정됩니다.
작업의 "효율성"에 관해서는 논쟁의 여지가 있습니다.
수정 가능성도 마찬가지입니다. 코드가 다른 정밀도의 따옴표에 사용되는 경우 변경이 필요하고 구현하기 쉬울까요?
그러한 프로젝트의 주요 문제는 단지 변경하는 것입니다. 실습에서 알 수 있듯이 블록이 많을수록 수정 중에 오류가 발생할 가능성이 높아집니다. 댓글이 없는 것은 플러스가 아니라 마이너스입니다. 그렇기 때문에 기억해야 할 것이 많다.
블록의 다양성은 또 다른 평가 기준입니다. 물론 블록은 다양한 작업에 사용되어야 하며 변화하는 조건에 쉽게 적응해야 합니다. 나는 정확히 그것을 가지고있다. 예를 들어, 저는 소위 "초점" 기술을 사용합니다. 즉, 주요 매개변수의 값은 항상 전역 변수 에 고정되며 이러한 변수는 모든 블록에 고정됩니다.
블록의 다양성은 또 다른 평가 기준입니다. 물론 블록은 다양한 작업에 사용되어야 하며 변화하는 조건에 쉽게 적응해야 합니다. 나는 정확히 그것을 가지고있다. 예를 들어, 저는 소위 "초점" 기술을 사용합니다. 즉, 주요 매개변수의 값은 항상 전역 변수 에 고정되며 이러한 변수는 모든 블록에 고정됩니다.
전역 변수도 마이너스입니다. 가능한 모든 블록에서 사용할 수 있는 전역 변수가 적어야 합니다. 각 블록이 필요한 데이터만 수신하도록 하고 가능한 한 항상 일정한 형식으로만 수신하므로 변경 사항이 의미하지 않는 것을 변경할 수 없습니다.
내 프로젝트에는 두 개의 전역 변수만 있습니다. 이것은 Init(), OnTick() 및 기타 이벤트의 기능을 캡슐화하는 기능을 가진 CExpert 클래스의 개체이고, CLogFile 개체는 추적이 기록되는 로그 파일입니다. 추적 매크로는 프로그램의 어느 곳에서나 작동해야 하기 때문입니다.
내 생각에 기억에 의존하는 것은 최선의 해결책이 아닙니다. 적어도 셜록 홈즈가 말했듯이, 언젠가는 필요한 지식이 불필요한 쓰레기 더미 아래 묻힐 것이기 때문입니다. 글쎄, 그것은 또한 메모리를 실패할 수 있습니다.
전역 변수도 마이너스입니다. 가능한 모든 블록에서 사용할 수 있는 전역 변수가 적어야 합니다. 각 블록이 필요한 데이터만 수신하도록 하고 가능한 한 항상 일정한 형식으로만 수신하므로 변경 사항이 의미하지 않는 것을 변경할 수 없습니다.
내 프로젝트에는 두 개의 전역 변수만 있습니다. 이것은 Init(), OnTick() 및 기타 이벤트의 기능을 캡슐화하는 기능을 가진 CExpert 클래스의 개체이고, CLogFile 개체는 추적이 기록되는 로그 파일입니다. 추적 매크로는 프로그램의 어느 곳에서나 작동해야 하기 때문입니다.
내 생각에 기억에 의존하는 것은 최선의 해결책이 아닙니다. 적어도 셜록 홈즈가 말했듯이, 언젠가는 필요한 지식이 불필요한 쓰레기 더미 아래 묻힐 것이기 때문입니다. 글쎄, 그것은 또한 메모리를 실패할 수 있습니다.
실전에서 비교가 필요합니다. 그렇지 않으면 이것은 쓸모없는 토론입니다.
왜 "쓸모없는"것입니까? 굉장히 유용하다.
그러나 실제로 "지원"을 비교하는 방법은 무엇입니까?
여기에서 코드가 하나의 거대한 블록에 작성되고 코드가 기능적인 부분으로 나누어져 있다고 가정해 보겠습니다. 두 경우 모두 변경하는 것은 정확히 동일합니다. 유일한 차이점은 첫 번째 경우 수정의 영향을 받는 모든 링크를 기억하고 고려해야 한다는 것입니다. 그리고 두 번째 경우 - 블록이 작동해야 하는 연결에만 액세스할 수 있으므로 수정은 사용 가능한 모든 연결에 영향을 미칩니다. 아무것도 기억할 필요가 없습니다. 변경되는 블록에 사용할 수 있는 모든 것을 일관되게 수정합니다.
차이를 평가하는 방법은 다음과 같습니다. 정확히 같은 양을 일하십시오!
