Aleksei Stepanenko # : 괜찮은! OOP와 함께하는 수익은 어떻습니까? 공부하면 바로 가나요?
OOP는 간결하고 깨끗하며 우아한 코드를 작성할 수 있는 기능을 제공합니다. 코드를 작성, 수정 및 디버깅하는 데 몇 배 적은 시간을 할애할 수 있으며 이는 매우 비용이 많이 듭니다. 훨씬 더 복잡한 거래 시스템을 구축하고 더 많은 거래 옵션을 시도할 수 있습니다. 물론 수익성 있는 봇에 대한 아이디어가 없다면 아무 것도 하지 않는 것이 좋습니다. 또한 버그의 경우 직접적인 손실 가능성이 있다는 것을 잊지 마십시오. 좋은 OOP 코드에서는 그 가능성이 몇 배나 적습니다.
네, 저는 OOP에 반대하지 않습니다, 친구들. 나는 그의 물건 아이디어를 좋아한다. 그리고 나는 그것을 구조의 형태로, 또는 오히려 구조의 배열의 형태로 부분적으로 사용합니다. 이것은 거래에서 차트의 모든 데이터를 목표 방식으로 저장하고 각 막대의 주기를 유도하지 않는 데 충분합니다. 그러나 여기에서는 더 많은 것이 필요하지 않다고 생각합니다. 물론 익숙하신 분들은 모두 OOP로 작성하셔도 됩니다. 그러나 절차상 이익과는 거리가 멉니다. 전체 질문은 수익성 있는 시스템에 있습니다. 존재하는 경우 goto-code를 작성할 수 있습니다. :)
네, 저는 OOP에 반대하지 않습니다, 친구들. 나는 그의 물건 아이디어를 좋아한다. 그리고 나는 그것을 구조의 형태로 또는 오히려 구조의 배열의 형태로 부분적으로 사용합니다. 이것은 거래에서 차트의 모든 데이터를 목표 방식으로 저장하고 각 막대의 주기를 유도하지 않는 데 충분합니다. 그러나 여기에서는 더 많은 것이 필요하지 않다고 생각합니다. 물론 익숙하신 분들은 모두 OOP로 작성하셔도 됩니다. 그러나 절차상 이익과는 거리가 멉니다. 전체 질문은 수익성 있는 시스템에 있습니다. 존재하는 경우 goto-code를 작성할 수 있습니다. :)
분기의 주제는 해결 방법 위에 있습니다.
구조의 사용은 OOP가 아닙니다. OOP의 모든 이점은 OOP 패턴을 사용하기 시작할 때 시작됩니다. 상속, 싱글톤, 객체 팩토리, 인터페이스 클래스 등 또한 팀원이 2명 이상일 경우 OOP 없이는 할 수 없습니다. 예를 들어:
enum Direction
{
BUY,
SELL,
NO_SIGNAL
};
class Signal
{
public :
Signal() {}
~Signal() {}
virtual Direction check_signal() { return NO_SIGNAL; }
};
또한, 스스로 또는 3명에게 신호를 작성하도록 나누어 예를 들어 3가지 다른 표시기:
class RSISignal : public Signal
{
public :
RSISignal() {}
~RSISignal() {}
Direction check_signal()
{
Direction result;
// Checking signal with RSIreturn result;
}
};
신호가 사용되는 장소에서는 다음을 수행하는 것으로 충분합니다.
Signal* signal;
switch signal_type
{
case RSI : signal = new RSI;
case CCI : signal = new CCI;
case MA : signal = new MA;
};
if (signal.check_signal())
.....
선배로서 당신은 함수 본문의 구현에서 완전히 추상화되어 있습니다. 구현은 귀하에게 중요하지 않으며 어떤 지표가 사용되는지는 중요하지 않습니다. check_signal을 사용하면 됩니다. 이 예에서는 하나의 기능이 사용됩니다. 그리고 클래스에 많은 기능이 있는 경우 구현이 구성 또는 기타 선택에 따라 달라지는 모든 위치에 스위치를 삽입해야 합니다. 또한 여러 곳에서 데이터베이스나 로그 파일을 사용하는 경우 전역 변수를 만들고 모든 단계(파일 또는 데이터베이스가 열려 있는지 등)에서 상태를 제어해야 합니다. 이러한 목적으로 싱글톤을 사용하는 경우 - 파일/데이터베이스 로그 개체를 사용하는 곳마다 - 개체의 복사본 하나가 항상 생성되어 데이터베이스/파일을 다시 열고 상태 플래그를 사용하고 버퍼링된 상태로 만들 수 있습니다. 각 출력 등에서 디스크에 쓰지 않도록 로그인하십시오. 10,000줄 이상의 코드가 있는 경우 기능은 개발자에게 생지옥이 됩니다. 그리고 반년 안에 코드의 절반을 잊어버리면 그것을 다시 이해하는 것은 지옥이 될 것입니다. 또한 좋은 OOP 디자인을 사용하면 어딘가에서 무언가를 하면 모든 것이 지옥에 갈 것이라는 두려움 없이 새로운 기능을 추가하거나 이전 기능을 편집할 수 있습니다.
괜찮은! OOP와 함께하는 수익은 어떻습니까? 공부하면 바로 가나요?
OOP는 간결하고 깨끗하며 우아한 코드를 작성할 수 있는 기능을 제공합니다. 코드를 작성, 수정 및 디버깅하는 데 몇 배 적은 시간을 할애할 수 있으며 이는 매우 비용이 많이 듭니다. 훨씬 더 복잡한 거래 시스템을 구축하고 더 많은 거래 옵션을 시도할 수 있습니다. 물론 수익성 있는 봇에 대한 아이디어가 없다면 아무 것도 하지 않는 것이 좋습니다. 또한 버그의 경우 직접적인 손실 가능성이 있다는 것을 잊지 마십시오. 좋은 OOP 코드에서는 그 가능성이 몇 배나 적습니다.
OOP는 간결하고 깨끗하며 우아한 코드를 작성할 수 있는 기능을 제공합니다.
이것은 사실이 아닙니다.
이것은 사실이 아닙니다.
글쎄, 당신이 그것을 구체적으로 복잡하게 하는 작업을 설정한다면, 그렇습니다. OOP를 사용하면 의도적인 복잡성을 위한 더 많은 기회가 있습니다.
그러나 포인트가 있는 원숭이처럼 되지 않으면 OOP를 사용하는 코드가 눈에 띄게 명확하고 구조화되고 유지 관리가 더 쉬워집니다.
네, 저는 OOP에 반대하지 않습니다, 친구들. 나는 그의 물건 아이디어를 좋아한다. 그리고 나는 그것을 구조의 형태로, 또는 오히려 구조의 배열의 형태로 부분적으로 사용합니다. 이것은 거래에서 차트의 모든 데이터를 목표 방식으로 저장하고 각 막대의 주기를 유도하지 않는 데 충분합니다. 그러나 여기에서는 더 많은 것이 필요하지 않다고 생각합니다. 물론 익숙하신 분들은 모두 OOP로 작성하셔도 됩니다. 그러나 절차상 이익과는 거리가 멉니다. 전체 질문은 수익성 있는 시스템에 있습니다. 존재하는 경우 goto-code를 작성할 수 있습니다. :)
분기의 주제는 해결 방법 위에 있습니다.
그리고 나는 그것을 구조의 형태로, 또는 오히려 구조의 배열의 형태로 부분적으로 사용합니다.
Java에서는 자체 이름도 있습니다. POJO(Plain Old Java Object)
;)
OOP를 사용하는 코드는 눈에 띄게 명확하고 구조화되어 있으며 유지 관리가 더 쉽습니다.
이것은 항상 그런 것은 아니며 OOP가 아니라 코드의 순도, 명명에 따라 다릅니다.
네, 저는 OOP에 반대하지 않습니다, 친구들. 나는 그의 물건 아이디어를 좋아한다. 그리고 나는 그것을 구조의 형태로 또는 오히려 구조의 배열의 형태로 부분적으로 사용합니다. 이것은 거래에서 차트의 모든 데이터를 목표 방식으로 저장하고 각 막대의 주기를 유도하지 않는 데 충분합니다. 그러나 여기에서는 더 많은 것이 필요하지 않다고 생각합니다. 물론 익숙하신 분들은 모두 OOP로 작성하셔도 됩니다. 그러나 절차상 이익과는 거리가 멉니다. 전체 질문은 수익성 있는 시스템에 있습니다. 존재하는 경우 goto-code를 작성할 수 있습니다. :)
분기의 주제는 해결 방법 위에 있습니다.
구조의 사용은 OOP가 아닙니다. OOP의 모든 이점은 OOP 패턴을 사용하기 시작할 때 시작됩니다. 상속, 싱글톤, 객체 팩토리, 인터페이스 클래스 등 또한 팀원이 2명 이상일 경우 OOP 없이는 할 수 없습니다. 예를 들어:
또한, 스스로 또는 3명에게 신호를 작성하도록 나누어 예를 들어 3가지 다른 표시기:
신호가 사용되는 장소에서는 다음을 수행하는 것으로 충분합니다.
선배로서 당신은 함수 본문의 구현에서 완전히 추상화되어 있습니다. 구현은 귀하에게 중요하지 않으며 어떤 지표가 사용되는지는 중요하지 않습니다. check_signal을 사용하면 됩니다. 이 예에서는 하나의 기능이 사용됩니다. 그리고 클래스에 많은 기능이 있는 경우 구현이 구성 또는 기타 선택에 따라 달라지는 모든 위치에 스위치를 삽입해야 합니다. 또한 여러 곳에서 데이터베이스나 로그 파일을 사용하는 경우 전역 변수를 만들고 모든 단계(파일 또는 데이터베이스가 열려 있는지 등)에서 상태를 제어해야 합니다. 이러한 목적으로 싱글톤을 사용하는 경우 - 파일/데이터베이스 로그 개체를 사용하는 곳마다 - 개체의 복사본 하나가 항상 생성되어 데이터베이스/파일을 다시 열고 상태 플래그를 사용하고 버퍼링된 상태로 만들 수 있습니다. 각 출력 등에서 디스크에 쓰지 않도록 로그인하십시오. 10,000줄 이상의 코드가 있는 경우 기능은 개발자에게 생지옥이 됩니다. 그리고 반년 안에 코드의 절반을 잊어버리면 그것을 다시 이해하는 것은 지옥이 될 것입니다. 또한 좋은 OOP 디자인을 사용하면 어딘가에서 무언가를 하면 모든 것이 지옥에 갈 것이라는 두려움 없이 새로운 기능을 추가하거나 이전 기능을 편집할 수 있습니다.
그리고 5k와 4k에서 OOP의 차이점은 무엇입니까? 밝히다. 교환 환경 설정의 차이는 분명합니다. 글쎄, 막대는 끝에서 번호가 매겨집니다. 나는 언어의 명백한 차이를 보지 못합니다.
최소한, 우리는 마침내 많은 망원경 기능을 제거했고, 가장 중요한 것은 표준 라이브러리에 엄청난 수의 유용한 클래스가 추가되었다는 것입니다.
최소한, 우리는 마침내 많은 망원경 기능을 제거했고, 가장 중요한 것은 표준 라이브러리에 엄청난 수의 유용한 클래스가 추가되었다는 것입니다.
특히 Object.mqh
당신이 인용하지 못한 책에서 바로 .. 화려한 패턴 :-)
주제는 당신이 OOP 과정을 얼마나 마스터하고 그것을 옹호하는 방법을 배웠는지에 관한 것이 아닙니다. 제 생각에는 당신이 그것을 잘못 마스터했습니다.
일반적으로 교과서를 수집하고 내일 학교로 행진합니다.