아니요. 하나의 변수로 작동하는 두 개의 함수가 있는 경우 전역으로 선언합니다. 또는 하나에서 다른 것으로 전송합니다. 이것은 엔티티를 생성하는 이유가 아닙니다.
그리고 3개의 클래스와 2개의 구조에 대한 OOP는 무엇입니까? 그러한 짧은 상속 사슬은 무엇을 위한 것입니까? 간단한 솔루션은 구문의 복잡성과 일련의 선택적 구문 트릭을 얻습니다. 그런 다음 추종자들은 OOP의 관련성을 정당화하기 위해 기능을 분할하기 시작합니다. 결정의 관점에서 이것은 잘못된 것입니다.
날조하지 마십시오. 그렇지 않으면 Peter, 클럽에 가입하도록 청원하겠습니다.
캡슐화와 OOP의 관련성은 두 함수가 하나의 공통 변수로 작동할 때 이미 발생합니다.
날조하지 마십시오. 그렇지 않으면 Peter, 클럽에 가입하도록 청원하겠습니다.
캡슐화와 OOP의 관련성은 두 함수가 하나의 공통 변수로 작동할 때 이미 발생합니다.
아니요. 하나의 변수로 작동하는 두 개의 함수가 있는 경우 전역으로 선언합니다. 또는 하나에서 다른 것으로 전송합니다. 이것은 엔티티를 생성하는 이유가 아닙니다.
그리고 3개의 클래스와 2개의 구조에 대한 OOP는 무엇입니까? 그러한 짧은 상속 사슬은 무엇을 위한 것입니까? 간단한 솔루션은 구문의 복잡성과 일련의 선택적 구문 트릭을 얻습니다. 그런 다음 추종자들은 OOP의 관련성을 정당화하기 위해 기능을 분할하기 시작합니다. 결정의 관점에서 이것은 잘못된 것입니다.
OOP의 사용은 다음과 같이 정당화되어야 합니다.
1. 배우고자 하는 열망.
2. 솔루션을 대규모 프로그램이나 라이브러리에 연결합니다.
3. 프로그램의 성장과 복잡성, 데이터의 다양성으로 이어지는 글로벌 아이디어.
이것이 없고 솔루션에 필요하지 않은 경우 사용할 필요가 없습니다.
아니요. 하나의 변수로 작동하는 두 개의 함수가 있는 경우 전역으로 선언합니다. 또는 한 곳에서 다른 곳으로 이전합니다. 이것은 엔티티를 생성하는 이유가 아닙니다.
...
그건 그냥 예입니다! 코드를 균질한 엉망으로 만들지 않기 위해.
댓글과 스타일러 가 도움이 될 것입니다.
응. 또 다른 공책과 이마에 영구 화장.
이 질문이 나왔습니다.
지표 계산을 클래스로 배열하면 이점이 있습니까? 이렇게 하면 Expert Advisor를 작성할 때 표시기 핸들 없이도 호출하지 않고 라이브러리를 이 클래스와 연결하여 마지막 막대의 값을 가져오기만 하면 됩니다.
예, 표시기는 이 라이브러리를 사용하여 작성할 수 있습니다.
어떻게 생각하나요?
이 질문이 나왔습니다.
지표 계산을 클래스로 배열하면 이점이 있습니까? 이렇게 하면 Expert Advisor를 작성할 때 표시기 핸들 없이도 호출하지 않고 라이브러리를 이 클래스와 연결하여 마지막 막대의 값을 가져오기만 하면 됩니다.
예, 표시기는 이 라이브러리를 사용하여 작성할 수 있습니다.
어떻게 생각하나요?
포함 > 지표
봐, 클래스에 표시기의 예가 있습니다.
포함 > 지표
봐, 클래스에 표시기의 예가 있습니다.
어떤 예가 있습니까? 이러한 예가 있다고 해서 @Alexey Viktorov 가 제기한 질문에 대한 답을 얻을 수는 없습니다.
이 질문이 나왔습니다.
지표 계산을 클래스로 배열하면 이점이 있습니까?
꼭. 적어도 고문과의 연결 측면에서. 이러한 표시기는 코드에 한 줄로 포함됩니다. 그리고 iCustom이 필요하지 않습니다.
꼭. 적어도 고문과의 연결 측면에서. 이러한 표시기는 코드에 한 줄로 포함됩니다. 그리고 iCustom이 필요하지 않습니다.
예를 들어볼까요?