MQL5의 OOP에 대한 질문 - 페이지 27

 
Alexey Navoykov :

근거가 없는 구체적인 진술은?

충분합니다.

이 기사는 정크이며 OOP에서 구울 수 있도록 설계되었으며 mql에 FP용 언어 도구가 없기 때문에 mql과 전혀 관련이 없습니다.

따라서 여기서 논의하는 것은 의미가 없습니다.

 
TheXpert :

충분합니다.

이 기사는 정크이며 OOP에서 구울 수 있도록 설계되었으며 mql에 FP용 언어 도구가 없기 때문에 mql과 전혀 관련이 없습니다.

따라서 여기서 논의하는 것은 의미가 없습니다.

예, 하지만 최소한 OOP 오용 문제를 지적합니다. 초보자가 OOP를 사용한다는 사실이 만병 통치약이며 코드 품질을 보장한다는 인상을 받지 않도록 여기에서 이것이 매우 유용하다고 생각합니다.
 
TheXpert :

충분합니다.

이 기사는 정크이며 OOP의 일부에서 소진되도록 설계되었으며 mql 에 FP용 언어 도구가 없기 때문에 mql과 전혀 관련이 없습니다.

따라서 여기서 논의하는 것은 의미가 없습니다.

댓글은 불필요합니다.

 
Vasiliy Sokolov :
FP 지지자들은 그들의 람다 미적분학이 유한한 수의 상태와 그들 사이의 전이를 가진 튜링 기계에 의해 실행된다는 사실을 의도적으로 잊었습니다. 동일한 카운터, 분기 및 goto 명령이 사용됩니다. 따라서 FP가 C, C#, Java와 같은 고전적인 언어보다 더 많은 것을 제공한다고 말하는 것은 적어도 잘못된 것입니다.

Vasily, 이 기사는 당신에게 매우 유용할 것입니다. 자신을 고문하지 않기 위해 OOP를 위해 자신의 OOP를 짜내십시오.

 
Dmitry Fedoseev :

Vasily, 이 기사는 당신에게 매우 유용할 것입니다. 자신을 고문하지 않기 위해 OOP를 위해 자신의 OOP를 짜내십시오.

왜 그렇게 아첨하지? 나는 그의 기사 스타일을 정말 좋아한다.

코드 청결도 및 가독성 - 나는 분명히 나 자신을 원할 것입니다 - 수준이 매우 높습니다

 
Igor Makanu :

왜 그렇게 아첨하지? 나는 그의 기사 스타일을 정말 좋아한다.

및 코드 청결 및 가독성 - 나는 분명히 나 자신을 원할 것입니다 - 수준이 매우 높습니다

불행히도 나는 이 대화를 지원할 수 없습니다. 기사를 읽거나 코드를 본 적이 없습니다. 그것은 다른 것에 관한 것이었습니다.

 
Dmitry Fedoseev :

불행히도 나는 이 대화를 지원할 수 없습니다. 기사를 읽거나 코드를 본 적이 없습니다. 그것은 다른 것에 관한 것이었습니다.

글쎄, 나는 MQL에서 OOP의 편의를 이해하는 순도를 위해 OOP에 대한 내 의견을 말할 수 있습니다. 코드를 완성했습니다. 결국에는 무엇이 나올지 보는 것이 흥미로웠습니다. 처음에는 내가 쓰던 방식이었습니다 - 디버깅 주문 작업 및 이 작업에서만 사용하기로 계획한 데이터 및 작은 메서드를 저장한 OOP 삽입을 위한 서비스 함수, 클래스의 주문 작업을 위한 함수 (절차적 스타일)

이제 클래스에서 주문으로 작업하는 모든 기능을 래핑한 다음 클래스 필드가 비공개이기 때문에 코드를 결합하여 함수에서 매개변수를 제거했습니다. 추가 사용을 위한 절대적으로 이식 불가능한 코드

예, 작은 메서드를 추가하고 클래스의 기능을 확장할 수 있는 것이 편리하지만 나중에 사용하기 위해 ... 또는 컴파일러가 실행 파일에 사용되지 않는 코드를 포함하지 않는다는 것을 알고 새 메서드를 추가하거나 ... 다시 작성 - 일반적으로 특정 몬스터는 주문이 있는 클래스 작업으로 밝혀졌습니다.

안전보장이사회를 살펴보면 기본적으로 같은 상황이 있습니다. 즉, 보편성에 대한 요금이 부풀려진 코드로, 몇 개월 후에는 읽을 수 없고 상속을 통해 무엇이 불필요한지 파악하지 못하게 됩니다. 수업 시간은 유감입니다

원칙적으로 읽을 수 있습니다. 수행 된 작업의 방법 이름 ... 일반적으로 결과에 만족하지 않으며 모든 것이 번거롭습니다.

 
Igor Makanu :

글쎄, 나는 MQL에서 OOP의 편의를 이해하는 순도를 위해 OOP에 대한 내 의견을 말할 수 있습니다. 코드를 완성했습니다. 결국에는 무엇이 나올지 보는 것이 흥미로웠습니다. 처음에는 내가 쓰던 방식이었습니다 - 디버깅 주문 작업 및 이 작업에서만 사용하기로 계획한 데이터 및 작은 메서드를 저장한 OOP 삽입을 위한 서비스 함수, 클래스의 주문 작업을 위한 함수 (절차적 스타일)

이제 클래스에서 주문으로 작업하는 모든 기능을 래핑한 다음 클래스 필드가 비공개이기 때문에 코드를 결합하여 함수에서 매개변수를 제거했습니다. 추가 사용을 위한 절대적으로 이식 불가능한 코드

예, 작은 메서드를 추가하고 클래스의 기능을 확장할 수 있는 것이 편리하지만 나중에 사용하기 위해 ... 또는 컴파일러가 실행 파일에 사용되지 않는 코드를 포함하지 않는다는 것을 알고 새 메서드를 추가하거나 ... 다시 작성 - 일반적으로 특정 몬스터는 주문이 있는 클래스 작업으로 밝혀졌습니다.

안전보장이사회를 살펴보면 기본적으로 같은 상황이 있습니다. 즉, 보편성에 대한 요금이 부풀려진 코드로, 몇 개월 후에는 읽을 수 없고 상속을 통해 무엇이 불필요한지 파악하지 못하게 됩니다. 수업 시간은 유감입니다

원칙적으로 읽을 수 있습니다. 수행 된 작업의 방법 이름 ... 일반적으로 결과에 만족하지 않으며 모든 것이 번거롭습니다.

한마디로 똥과 버려졌습니다.

 
Алексей Тарабанов :

한마디로 똥과 버려졌습니다.

어, 누가 떨어뜨렸어? 무슨 얘기를 하는 건가요? 알았어 ... 한밤중에 모든 댓글이있어 무엇인지 이해하기 어렵습니다.

 
Igor Makanu :

...

그리고 클래스를 사용하지 않으면 SymbolInfoDouble(_Symbol, SYMBOL_BID )과 같은 것을 지속적으로 작성하는 데 어려움을 겪을 것입니다. 매번 그런 춤을 추고 대괄호와 밑줄을 긋고 capslock을 눌러야하는지 (그런 다음 다른 곳에서 보지 않고 전체 줄을 대문자로 입력하고 다시 입력하십시오) Shift 키를 계속 누르고 있어야하는지 알 수 없습니다. 적어도 이 OOP에서는 유용합니다. 최소한 이러한 모든 기능에 대한 클래스를 만들면 그렇습니다. 매우 큽니다. 자신을 위해 쓴다면 문제가 되지 않습니다. 주문 작업의 경우 자주 사용하는 기능이 많지 않으므로 라이브러리에 몇 가지 기능을 추가하기만 하면 됩니다. 그러나 일반적으로 아직 이상적인 접근 방식은 없습니다.