제 생각에는 문제 해결 시스템에 일종의 결함이 있습니다. 작업 자체는 수정처럼 명확하고 정확해야 하므로 솔루션도 마찬가지입니다. 결정이 모호하고 "시스템 자체가 매우 합리적인 것으로 나타났습니다"(270kb 코드에 합리성이 어떻게 있을 수 있습니까?!)라는 단어로 정의된 경우 이는 작성자가 시스템 작동 방식을 대략적으로 이해하고 있음을 의미합니다. 그리고 풀이에 불필요한 문법과 본질의 끔찍한 종소리와 휘파람에 의해 그는 끝까지 이해를 방해합니다.
합리성은 "예측력"에 있습니다. 작업 프로토콜의 중요한 변경은 작업 논리를 담당하는 전문가 코드의 변경을 요구하지 않습니다. 코드 수정은 저수준에서 단말과 직접적으로 작동하는 곳에서만 이루어졌다.
주어진 코드는 모든 OOP 벨과 휘파람이 "기능적인 벨과 휘파람"으로 어떻게 완전히 대체될 수 있는지를 아주 잘 보여줍니다. 즉, 위에서 말한 것과 정확히 일치합니다. 이 방법과 저 방법으로 쓸 수 있습니다.
그러나 귀하의 코드를 보면 훨씬 더 많은 것을 메모리에 보관해야 함을 알 수 있습니다. 대부분의 경우 - 나는 순간에 "익사"했습니다. 그것들은 정확하지만 이 코드를 유지해야 한다면 각 조건 앞에 몇 줄의 주석을 삽입하고 이 검사가 수행하는 작업과 정확히 그러한 필드가 배열에서 사용되는 이유를 삽입할 것입니다. 내 코드에서 СTradePositionI 인터페이스를 선언하기 전에 주석과 유추합니다. 플러스 - 어려운 조건 - 개인적으로도 매우 긴장할 것입니다.
개인적으로, 나는 당신의 코드에 더 많은 오류를 만들 것이고, 그것들을 잡는 것이 더 어려울 것입니다. 즉, 그러한 코드의 모든 정확성과 논리로 모든 것을 OOP 스타일로 작성했을 때보다 지원하기가 더 어려울 것입니다.
OOP 스타일에서는 창, 캔버스 세부 정보, 요소, 캔버스의 인터페이스를 선언한 다음 이러한 인터페이스를 사용하여 이러한 개체의 실제 클래스를 작성한 다음 필요한 블록에서 이러한 인터페이스에 대한 포인터를 발행하고 현재 필요한 엔티티와 구체적으로 작업하십시오. 다른 모든 것은 이 곳에서 액세스할 수 없습니다. 무엇이 무엇에 속하고 무엇이 무엇에 책임이 있는지 기억하지 않기 위해. 몇 가지 기능에서 가장 간단한 인터페이스를 얻을 수 있으므로 작업하고 나머지는 필요하지 않으므로 사용할 수 없습니다. 아무것도 기억할 필요가 없습니다.
예, 인터페이스 할당, 상속 계층 구조 구성, 가상 함수 선언 및 순전히 절차적 스타일로 OOP 스타일에서 모든 작업을 해결할 수 있다는 것은 분명합니다. 모든 작업을 하나로 묶을 수도 있습니다. 거대한 기능.
문제는 지원의 편의성과 효율성이다.
MT에서 가장 OOP에 적합한 곳은 주문 시스템입니다. 개인적으로 "위치" 및 "위치 구성 요소" 가상 인터페이스가 있습니다. "포지션"은 MT4의 주문 집합 또는 MT5 포지션의 집합입니다. "포지션 구성 요소"는 단일 주문 또는 단일 MT5 포지션(헤지 또는 네팅)입니다.
다음은 실제 인터페이스 파일입니다( Peter Konow , 코드 양과 비교하여 주석 수를 추정할 수 있으며 일부 미묘함을 기억하지 못한다는 사실을 발견할 때 주기적으로 거기에 추가합니다. 내가 정기적으로 무엇을 잊어버리는지 가정해 봅시다. 실제 개체는 "위치 구성 요소"입니다. 나는 이것을 기억할 필요가 없습니다 - EA는 인터페이스에 따라 구성 요소와 함께 작동하며 이 인터페이스 뒤에 실제로 무엇이 있는지는 중요하지 않습니다. 하지만 수정할 때 이 항목으로 돌아가야 합니다. - 따라서 이 파일의 첫 번째 주석이 필요한 경우가 많습니다.
무역 구성 요소 인터페이스 파일은 다음과 같습니다(위에서 이미 제공했지만 반복하겠습니다.
이러한 인터페이스에 따르면 실제 및 과거 주문 모두에 대해 MT4 및 MT5 주문 시스템을 모두 구현했습니다.
직위를 요청한 Expert Advisor는 이 인터페이스를 수신하며 MT4 및 MT5 주문 작업의 차이점을 전혀 고려할 필요가 없습니다. 또한 새 주문 유형이 추가되거나 작업 순서가 변경되면 Expert Advisor에 대해 아무 것도 변경되지 않고 새 주문 유형의 클래스만 추가되고 이 인터페이스도 지원합니다.
이 시스템은 헤지 계정이 도입되었을 때 매우 합리적인 것으로 판명되었습니다. 전문가들은 전혀 변하지 않았습니다.
Peter Konow , MT4와 MT5의 주문 유형이 다른 문제를 어떻게 해결합니까?
새로운 유형의 계정이 도입되면(헤지 및 상계 외에) - 한 곳에서 어떤 변경이 필요합니까?
내 생각에, 정말로, 당신이 편지의 모든 코드를 기억하고 이 또는 저 줄이 1년 전에 당신의 코드에 쓰여진 이유를 쉽게 말할 수 있다면, 실제로 이 모든 OOP 종소리와 휘파람은 단지 불필요한 제스처일 뿐입니다. 아무도 필요하지 않습니다.
OOP는 코드를 수정할 때 모든 것을 멀리 기억할 때 정확히 필요합니다. OOP를 사용하면 블록을 서로 분리하여 주어진 순간에 사용 가능한 엔터티 집합을 프로그램의 특정 위치로 제한할 수 있습니다.
합리성은 "예측력"에 있습니다. 작업 프로토콜의 중요한 변경은 작업 논리를 담당하는 전문가 코드의 변경을 요구하지 않습니다. 코드 수정은 저수준에서 단말과 직접적으로 작동하는 곳에서만 이루어졌다.
주어진 코드는 모든 OOP 벨과 휘파람이 "기능적인 벨과 휘파람"으로 어떻게 완전히 대체될 수 있는지를 아주 잘 보여줍니다. 즉, 위에서 말한 것과 정확히 일치합니다. 이 방법과 저 방법으로 쓸 수 있습니다.
그러나 귀하의 코드를 보면 훨씬 더 많은 것을 메모리에 보관해야 함을 알 수 있습니다. 대부분의 경우 - 나는 순간에 "익사"했습니다. 그것들은 정확하지만 이 코드를 유지해야 한다면 각 조건 앞에 몇 줄의 주석을 삽입하고 이 검사가 수행하는 작업과 정확히 그러한 필드가 배열에서 사용되는 이유를 삽입할 것입니다. 내 코드에서 CTradePositionI 인터페이스를 선언하기 전에 주석과 유추합니다. 플러스 - 어려운 조건 - 개인적으로도 매우 긴장할 것입니다.
개인적으로, 나는 당신의 코드에 더 많은 오류를 만들 것이고, 그것들을 잡는 것이 더 어려울 것입니다. 즉, 그러한 코드의 모든 정확성과 논리로 모든 것을 OOP 스타일로 작성했을 때보다 지원하기가 더 어려울 것입니다.
OOP 스타일에서는 창, 캔버스 세부 정보, 요소, 캔버스의 인터페이스를 선언한 다음 이러한 인터페이스를 사용하여 이러한 개체의 실제 클래스를 작성한 다음 필요한 블록에서 이러한 인터페이스에 대한 포인터를 발행하고 현재 필요한 엔티티와 구체적으로 작업하십시오. 다른 모든 것은 이 곳에서 액세스할 수 없습니다. 무엇이 무엇에 속하고 무엇이 무엇에 책임이 있는지 기억하지 않기 위해. 몇 가지 기능에서 가장 간단한 인터페이스를 얻을 수 있으므로 작업하고 나머지는 필요하지 않으므로 사용할 수 없습니다. 아무것도 기억할 필요가 없습니다.
내 코드에서 많은 수의 ifof와 그 중첩은 서로 다른 이벤트와 다른 상태에서 서로 다른 제어 수행자의 복잡한 동작 때문입니다. 그러나 이 기능은 이러한 모든 옵션을 다루며 전체 GUI를 완전히 "제공"합니다. 요소를 다시 그릴 때 부품의 색상은 코어의 원래 색상 값 과 이 기능에 의해 결정됩니다.
그리고 여성에 관해서는... 글쎄요, 저는 당신과 같은 카사노바가 아닙니다... 나는 여전히 억누르고 있고, 생각하는 모든 것을 표현하지 않습니다... 나는 항상 가졌고 여전히 매우 큰 긴장을 가지고 있습니다 그런 면에서 비록 편안한 사생활이 항상 저에게는 매우 중요했지만... 가끔 운이 좋게 웃어주는 것도 좋고, 결국 기억에 남는 일이 있습니다.
여자에 관해서는... 글쎄요, 저는 당신과 같은 카사노바가 아닙니다... 나는 여전히 억누르고 있고, 내가 생각하는 모든 것을 표현하지 않습니다... 나는 항상 가졌고 여전히 매우 큰 긴장을 가지고 있습니다 그런 면에서 비록 편안한 사생활이 항상 저에게는 매우 중요했지만... 가끔 운이 좋게 웃어주는 것도 좋고, 결국 기억에 남는 일이 있습니다.
우리는 여성을 대하는 태도가 다를 뿐입니다. 도움이 필요하다고 생각합니다. 예, 그들은 변덕스럽고, 자신의 추진력이 있고, 취향이 변하는 등입니다. 심각하게 받아들이지 않아야 합니다. 그렇지 않으면 도덕적 비극이 있을 것입니다.
내가 이해하는 것처럼 데이터를 저장하기 위해 구조를 사용하지도 않습니까? 다차원 어레이 는 구조가 부족하여 이러한 솔루션을 사용해야 했던 고대 MQL4의 기억을 불러옵니다. 하지만 이제 요점이 무엇입니까? 의 말을하자
int Элемент = G_CORE[Окно][Деталь_полотна][_MAIN_ELEMENT];
int Состояние_детали = G_CORE[Окно][Элемент][_CURRENT_STATE];
로 대체될 수 있습니다.
int Элемент = G_CORE[Окно][Деталь_полотна].MAIN_ELEMENT;
int Состояние_детали = G_CORE[Окно][Элемент].CURRENT_STATE;
더 짧고 더 안정적이며(더 안전하고) 더 빠릅니다. 첫 번째 경우에는 배열 인덱스 값에 대한 컴파일 타임 제어가 없습니다. 그런 다음 런타임에 모든 종류의 "범위를 벗어난 배열"을 긁어모으십시오. 인덱스가 유효하지만 유효하지 않은 경우에는 더 나쁩니다. 따라서 좋은 프로그래밍 방법은 컴파일러를 최대한 사용하여 컴파일 단계에서 오류를 감지하고 프로세스에서 오류를 포착하지 않는 것입니다.
예, 이제 제출해야 할 값을 여전히 잘 기억하고 있습니다. 하지만 이것은 아마도 당신이 이 프로젝트로 끊임없이 바쁘기 때문일 것입니다. 예를 들어 반년 정도 휴식을 취하면 그 차이를 느낄 수 있을 것입니다. 여기에서 이미 언급하신 분도 있습니다. 아니면 여기 직선형 경화증이 chtol 모여 있다고 생각합니까? :) 이것은 프로그래머에게 흔한 일입니다...
따라서 작업은 발에 총을 쏠 가능성을 최소화하기 위해 그렇게하는 것입니다. 유비쿼터스 int 대신 enum을 사용하여 고유한 유형을 만드는 것이 좋습니다. 또한 열거된 값을 가질 필요가 없습니다. 중요한 것은 이것이 컴파일러에 의해 제어되고 함수 인수 등을 혼동할 기회를 제공하지 않는 별도의 독립 유형이라는 것입니다.
내가 이해하는 한, 데이터를 저장하기 위해 구조를 사용하지 않습니까? 다차원 어레이 는 구조가 부족하여 이러한 솔루션을 사용해야 했던 고대 MQL4의 기억을 불러옵니다. 하지만 이제 요점이 무엇입니까? 의 말을하자
로 대체될 수 있습니다.
더 짧고, 더 안정적이고(더 안전하고) 더 빠릅니다. 첫 번째 경우에는 배열 인덱스 값에 대한 컴파일 타임 제어가 없습니다. 그런 다음 런타임에 모든 종류의 "범위를 벗어난 배열"을 긁어모으십시오. 인덱스가 유효하지만 올바르지 않은 경우에는 더욱 악화됩니다. 따라서 좋은 프로그래밍 방법은 컴파일러를 최대한 사용하여 컴파일 단계에서 오류를 감지하고 프로세스에서 오류를 포착하지 않는 것입니다.
예, 이제 제출해야 할 값을 여전히 잘 기억하고 있습니다. 하지만 이것은 아마도 당신이 이 프로젝트로 끊임없이 바쁘기 때문일 것입니다. 예를 들어 반년 정도 휴식을 취하면 그 차이를 느낄 수 있을 것입니다. 여기에서 이미 언급하신 분도 있습니다. 아니면 곧은 경화증이 모여있는 chtol이 있다고 생각하십니까? :) 이것은 프로그래머에게 흔한 일입니다...
따라서 작업은 발에 총을 쏠 가능성을 최소화하기 위해 그렇게하는 것입니다. 유비쿼터스 int 대신 enum을 사용하여 고유한 유형을 만드는 것이 좋습니다. 또한 열거된 값을 가질 필요가 없습니다. 중요한 것은 이것이 컴파일러에 의해 제어되고 함수 인수 등을 혼동할 기회를 제공하지 않는 별도의 독립 유형이라는 것입니다.
다른 지점에 대한 귀하의 게시물을 읽고 당신이 프로그래밍의 훌륭한 전문가라는 것을 깨달았습니다. 당연히 나는 그렇지 않으며 가장하지도 않습니다. 그러나 나는 스스로 문제를 해결하는 전문가라고 생각합니다. 결국, 가장 중요한 것은 결정의 효율성이라는 데 동의할 것입니다.
구문의 힙과 규칙의 복잡성은 솔루션의 효율성을 유지하는 데 기여한 적이 없습니다. 코드 블록의 간결성, 보편성 및 가독성으로 표현되는 단순성과 간결성에 기여했습니다.
프로그래밍에서 내 규칙은 네이티브 언어와 의미 있는 변수 및 함수 이름을 사용하여 더 적은 코드, 더 적은 규칙, 더 적은 구문 및 더 적은 주석입니다.
제 메인 테제는 "솔루션에 아무것도 없이 할 수 있다면 반드시 솔루션 없이도 해야 합니다."입니다.
경화증이 여기 모였다고는 전혀 생각하지 않는다.)) 주어진 코드만 봐도 왜 쉽게 잊혀지는지 알 수 있다. 외국어로 프로그래밍한다는 바로 그 사실조차 중요한 역할을 합니다. 자신의 언어로 프로그래밍하면 완전히 다르게 느껴집니다. 긴장과 뻣뻣함이 아닌 강인함과 자유로움을 느낀다. 외국어는 더 많은 노력이 필요하고, 코드를 이해하는 데 더 많은 시간이 걸리며, 머리에서 더 빨리 날아갑니다. 바로 "생물학적 요인"입니다.
따라서 내 문제를 해결하기 위해 전체적으로 OOP를 사용하는 것은 (매우 적절하게) 비효율적이라고 생각합니다. 많은 규칙, 구문 및 모든 것이 외국어로 되어 있습니다. 따라서 재능은 실제로 돌아 가지 않습니다. 즉, 결과가 더 나쁠 것입니다. 임호.
제 생각에는 문제 해결 시스템에 일종의 결함이 있습니다. 작업 자체는 수정처럼 명확하고 정확해야 하므로 솔루션도 마찬가지입니다. 결정이 모호하고 "시스템 자체가 매우 합리적인 것으로 나타났습니다"(270kb 코드에 합리성이 어떻게 있을 수 있습니까?!)라는 단어로 정의된 경우 이는 작성자가 시스템 작동 방식을 대략적으로 이해하고 있음을 의미합니다. 그리고 풀이에 불필요한 문법과 본질의 끔찍한 종소리와 휘파람에 의해 그는 끝까지 이해를 방해합니다.
합리성은 "예측력"에 있습니다. 작업 프로토콜의 중요한 변경은 작업 논리를 담당하는 전문가 코드의 변경을 요구하지 않습니다. 코드 수정은 저수준에서 단말과 직접적으로 작동하는 곳에서만 이루어졌다.
주어진 코드는 모든 OOP 벨과 휘파람이 "기능적인 벨과 휘파람"으로 어떻게 완전히 대체될 수 있는지를 아주 잘 보여줍니다. 즉, 위에서 말한 것과 정확히 일치합니다. 이 방법과 저 방법으로 쓸 수 있습니다.
그러나 귀하의 코드를 보면 훨씬 더 많은 것을 메모리에 보관해야 함을 알 수 있습니다. 대부분의 경우 - 나는 순간에 "익사"했습니다. 그것들은 정확하지만 이 코드를 유지해야 한다면 각 조건 앞에 몇 줄의 주석을 삽입하고 이 검사가 수행하는 작업과 정확히 그러한 필드가 배열에서 사용되는 이유를 삽입할 것입니다. 내 코드에서 СTradePositionI 인터페이스를 선언하기 전에 주석과 유추합니다. 플러스 - 어려운 조건 - 개인적으로도 매우 긴장할 것입니다.
개인적으로, 나는 당신의 코드에 더 많은 오류를 만들 것이고, 그것들을 잡는 것이 더 어려울 것입니다. 즉, 그러한 코드의 모든 정확성과 논리로 모든 것을 OOP 스타일로 작성했을 때보다 지원하기가 더 어려울 것입니다.
OOP 스타일에서는 창, 캔버스 세부 정보, 요소, 캔버스의 인터페이스를 선언한 다음 이러한 인터페이스를 사용하여 이러한 개체의 실제 클래스를 작성한 다음 필요한 블록에서 이러한 인터페이스에 대한 포인터를 발행하고 현재 필요한 엔티티와 구체적으로 작업하십시오. 다른 모든 것은 이 곳에서 액세스할 수 없습니다. 무엇이 무엇에 속하고 무엇이 무엇에 책임이 있는지 기억하지 않기 위해. 몇 가지 기능에서 가장 간단한 인터페이스를 얻을 수 있으므로 작업하고 나머지는 필요하지 않으므로 사용할 수 없습니다. 아무것도 기억할 필요가 없습니다.
글쎄, 그들은 망했다 ...
예, 인터페이스 할당, 상속 계층 구조 구성, 가상 함수 선언 및 순전히 절차적 스타일로 OOP 스타일에서 모든 작업을 해결할 수 있다는 것은 분명합니다. 모든 작업을 하나로 묶을 수도 있습니다. 거대한 기능.
문제는 지원의 편의성과 효율성이다.
MT에서 가장 OOP에 적합한 곳은 주문 시스템입니다. 개인적으로 "위치" 및 "위치 구성 요소" 가상 인터페이스가 있습니다. "포지션"은 MT4의 주문 집합 또는 MT5 포지션의 집합입니다. "포지션 구성 요소"는 단일 주문 또는 단일 MT5 포지션(헤지 또는 네팅)입니다.
다음은 실제 인터페이스 파일입니다( Peter Konow , 코드 양과 비교하여 주석 수를 추정할 수 있으며 일부 미묘함을 기억하지 못한다는 사실을 발견할 때 주기적으로 거기에 추가합니다. 내가 정기적으로 무엇을 잊어버리는지 가정해 봅시다. 실제 개체는 "위치 구성 요소"입니다. 나는 이것을 기억할 필요가 없습니다 - EA는 인터페이스에 따라 구성 요소와 함께 작동하며 이 인터페이스 뒤에 실제로 무엇이 있는지는 중요하지 않습니다. 하지만 수정할 때 이 항목으로 돌아가야 합니다. - 따라서 이 파일의 첫 번째 주석이 필요한 경우가 많습니다.
무역 구성 요소 인터페이스 파일은 다음과 같습니다(위에서 이미 제공했지만 반복하겠습니다.
이러한 인터페이스에 따르면 실제 및 과거 주문 모두에 대해 MT4 및 MT5 주문 시스템을 모두 구현했습니다.
직위를 요청한 Expert Advisor는 이 인터페이스를 수신하며 MT4 및 MT5 주문 작업의 차이점을 전혀 고려할 필요가 없습니다. 또한 새 주문 유형이 추가되거나 작업 순서가 변경되면 Expert Advisor에 대해 아무 것도 변경되지 않고 새 주문 유형의 클래스만 추가되고 이 인터페이스도 지원합니다.
이 시스템은 헤지 계정이 도입되었을 때 매우 합리적인 것으로 판명되었습니다. 전문가들은 전혀 변하지 않았습니다.
Peter Konow , MT4와 MT5의 주문 유형이 다른 문제를 어떻게 해결합니까?
새로운 유형의 계정이 도입되면(헤지 및 상계 외에) - 한 곳에서 어떤 변경이 필요합니까?
내 생각에, 정말로, 당신이 편지의 모든 코드를 기억하고 이 또는 저 줄이 1년 전에 당신의 코드에 쓰여진 이유를 쉽게 말할 수 있다면, 실제로 이 모든 OOP 종소리와 휘파람은 단지 불필요한 제스처일 뿐입니다. 아무도 필요하지 않습니다.
OOP는 코드를 수정할 때 모든 것을 멀리 기억할 때 정확히 필요합니다. OOP를 사용하면 블록을 서로 분리하여 주어진 순간에 사용 가능한 엔터티 집합을 프로그램의 특정 위치로 제한할 수 있습니다.
Georges, 때로는 여성에 관한 클리닉을 작성하지만 코드를 존중합니다)))
합리성은 "예측력"에 있습니다. 작업 프로토콜의 중요한 변경은 작업 논리를 담당하는 전문가 코드의 변경을 요구하지 않습니다. 코드 수정은 저수준에서 단말과 직접적으로 작동하는 곳에서만 이루어졌다.
주어진 코드는 모든 OOP 벨과 휘파람이 "기능적인 벨과 휘파람"으로 어떻게 완전히 대체될 수 있는지를 아주 잘 보여줍니다. 즉, 위에서 말한 것과 정확히 일치합니다. 이 방법과 저 방법으로 쓸 수 있습니다.
그러나 귀하의 코드를 보면 훨씬 더 많은 것을 메모리에 보관해야 함을 알 수 있습니다. 대부분의 경우 - 나는 순간에 "익사"했습니다. 그것들은 정확하지만 이 코드를 유지해야 한다면 각 조건 앞에 몇 줄의 주석을 삽입하고 이 검사가 수행하는 작업과 정확히 그러한 필드가 배열에서 사용되는 이유를 삽입할 것입니다. 내 코드에서 CTradePositionI 인터페이스를 선언하기 전에 주석과 유추합니다. 플러스 - 어려운 조건 - 개인적으로도 매우 긴장할 것입니다.
개인적으로, 나는 당신의 코드에 더 많은 오류를 만들 것이고, 그것들을 잡는 것이 더 어려울 것입니다. 즉, 그러한 코드의 모든 정확성과 논리로 모든 것을 OOP 스타일로 작성했을 때보다 지원하기가 더 어려울 것입니다.
OOP 스타일에서는 창, 캔버스 세부 정보, 요소, 캔버스의 인터페이스를 선언한 다음 이러한 인터페이스를 사용하여 이러한 개체의 실제 클래스를 작성한 다음 필요한 블록에서 이러한 인터페이스에 대한 포인터를 발행하고 현재 필요한 엔티티와 구체적으로 작업하십시오. 다른 모든 것은 이 곳에서 액세스할 수 없습니다. 무엇이 무엇에 속하고 무엇이 무엇에 책임이 있는지 기억하지 않기 위해. 몇 가지 기능에서 가장 간단한 인터페이스를 얻을 수 있으므로 작업하고 나머지는 필요하지 않으므로 사용할 수 없습니다. 아무것도 기억할 필요가 없습니다.
내 코드에서 많은 수의 ifof와 그 중첩은 서로 다른 이벤트와 다른 상태에서 서로 다른 제어 수행자의 복잡한 동작 때문입니다. 그러나 이 기능은 이러한 모든 옵션을 다루며 전체 GUI를 완전히 "제공"합니다. 요소를 다시 그릴 때 부품의 색상은 코어의 원래 색상 값 과 이 기능에 의해 결정됩니다.
추신 OOP 또는 절차 스타일에 관해서는 - "각자에게"(c).
Georges, 때로는 여성에 관한 클리닉을 작성하지만 코드를 존중합니다)))
코드에 대해 - 나는 아첨합니다. (사실, 농담이 아닙니다.)
그리고 여성에 관해서는... 글쎄요, 저는 당신과 같은 카사노바가 아닙니다... 나는 여전히 억누르고 있고, 생각하는 모든 것을 표현하지 않습니다... 나는 항상 가졌고 여전히 매우 큰 긴장을 가지고 있습니다 그런 면에서 비록 편안한 사생활이 항상 저에게는 매우 중요했지만... 가끔 운이 좋게 웃어주는 것도 좋고, 결국 기억에 남는 일이 있습니다.
코드에 대해 - 나는 아첨합니다. (사실, 농담이 아닙니다).
여자에 관해서는... 글쎄요, 저는 당신과 같은 카사노바가 아닙니다... 나는 여전히 억누르고 있고, 내가 생각하는 모든 것을 표현하지 않습니다... 나는 항상 가졌고 여전히 매우 큰 긴장을 가지고 있습니다 그런 면에서 비록 편안한 사생활이 항상 저에게는 매우 중요했지만... 가끔 운이 좋게 웃어주는 것도 좋고, 결국 기억에 남는 일이 있습니다.
우리는 여성을 대하는 태도가 다를 뿐입니다. 도움이 필요하다고 생각합니다. 예, 그들은 변덕스럽고, 자신의 추진력이 있고, 취향이 변하는 등입니다. 심각하게 받아들이지 않아야 합니다. 그렇지 않으면 도덕적 비극이 있을 것입니다.
글쎄, 그들은 망했다 ...
예, 인터페이스 할당, 상속 계층 구조 구성, 가상 함수 선언 및 순전히 절차적 스타일로 OOP 스타일에서 모든 작업을 해결할 수 있다는 것은 분명합니다. 모든 작업을 하나로 묶을 수도 있습니다. 거대한 기능.
문제는 지원의 편의성과 효율성이다.
가능하지만 기능의 효율성이 다릅니다. 여기에 지원에 대한 이야기는 없습니다. 너무 상대적입니다.
절차적으로 최적으로 해결할 수 없는 문제가 있습니다.
우리는 여성을 대하는 태도가 다를 뿐입니다. 도움이 필요하다고 생각합니다. 예, 그들은 변덕스럽고, 자신의 추진력이 있고, 취향이 변하는 등입니다. 심각하게 받아들이지 않아야 합니다. 그렇지 않으면 도덕적 비극이 있을 것입니다.
Alexey, 실험을 해본 적이 있습니까? 도움을 받고 싶은 여성의 욕망은 얼마나 끝이 없습니까? 도움에 대한 만족도와 지속 기간은?
내가 이해하는 것처럼 데이터를 저장하기 위해 구조를 사용하지도 않습니까? 다차원 어레이 는 구조가 부족하여 이러한 솔루션을 사용해야 했던 고대 MQL4의 기억을 불러옵니다. 하지만 이제 요점이 무엇입니까? 의 말을하자
로 대체될 수 있습니다.
더 짧고 더 안정적이며(더 안전하고) 더 빠릅니다. 첫 번째 경우에는 배열 인덱스 값에 대한 컴파일 타임 제어가 없습니다. 그런 다음 런타임에 모든 종류의 "범위를 벗어난 배열"을 긁어모으십시오. 인덱스가 유효하지만 유효하지 않은 경우에는 더 나쁩니다. 따라서 좋은 프로그래밍 방법은 컴파일러를 최대한 사용하여 컴파일 단계에서 오류를 감지하고 프로세스에서 오류를 포착하지 않는 것입니다.
예, 이제 제출해야 할 값을 여전히 잘 기억하고 있습니다. 하지만 이것은 아마도 당신이 이 프로젝트로 끊임없이 바쁘기 때문일 것입니다. 예를 들어 반년 정도 휴식을 취하면 그 차이를 느낄 수 있을 것입니다. 여기에서 이미 언급하신 분도 있습니다. 아니면 여기 직선형 경화증이 chtol 모여 있다고 생각합니까? :) 이것은 프로그래머에게 흔한 일입니다...
따라서 작업은 발에 총을 쏠 가능성을 최소화하기 위해 그렇게하는 것입니다. 유비쿼터스 int 대신 enum을 사용하여 고유한 유형을 만드는 것이 좋습니다. 또한 열거된 값을 가질 필요가 없습니다. 중요한 것은 이것이 컴파일러에 의해 제어되고 함수 인수 등을 혼동할 기회를 제공하지 않는 별도의 독립 유형이라는 것입니다.
나는 OOP만을 씁니다.
1900년의 어느 삭막한 해에 Pascal 6.0, 그리고 Borland C++ 4.5에 들어갈 수 없었습니다. 하지만 이사를 하고 나니 달리 상상할 수 없었습니다. 모든 것이 너무 간단하고 편리해졌습니다.
내가 이해하는 한, 데이터를 저장하기 위해 구조를 사용하지 않습니까? 다차원 어레이 는 구조가 부족하여 이러한 솔루션을 사용해야 했던 고대 MQL4의 기억을 불러옵니다. 하지만 이제 요점이 무엇입니까? 의 말을하자
로 대체될 수 있습니다.
더 짧고, 더 안정적이고(더 안전하고) 더 빠릅니다. 첫 번째 경우에는 배열 인덱스 값에 대한 컴파일 타임 제어가 없습니다. 그런 다음 런타임에 모든 종류의 "범위를 벗어난 배열"을 긁어모으십시오. 인덱스가 유효하지만 올바르지 않은 경우에는 더욱 악화됩니다. 따라서 좋은 프로그래밍 방법은 컴파일러를 최대한 사용하여 컴파일 단계에서 오류를 감지하고 프로세스에서 오류를 포착하지 않는 것입니다.
예, 이제 제출해야 할 값을 여전히 잘 기억하고 있습니다. 하지만 이것은 아마도 당신이 이 프로젝트로 끊임없이 바쁘기 때문일 것입니다. 예를 들어 반년 정도 휴식을 취하면 그 차이를 느낄 수 있을 것입니다. 여기에서 이미 언급하신 분도 있습니다. 아니면 곧은 경화증이 모여있는 chtol이 있다고 생각하십니까? :) 이것은 프로그래머에게 흔한 일입니다...
따라서 작업은 발에 총을 쏠 가능성을 최소화하기 위해 그렇게하는 것입니다. 유비쿼터스 int 대신 enum을 사용하여 고유한 유형을 만드는 것이 좋습니다. 또한 열거된 값을 가질 필요가 없습니다. 중요한 것은 이것이 컴파일러에 의해 제어되고 함수 인수 등을 혼동할 기회를 제공하지 않는 별도의 독립 유형이라는 것입니다.
다른 지점에 대한 귀하의 게시물을 읽고 당신이 프로그래밍의 훌륭한 전문가라는 것을 깨달았습니다. 당연히 나는 그렇지 않으며 가장하지도 않습니다. 그러나 나는 스스로 문제를 해결하는 전문가라고 생각합니다. 결국, 가장 중요한 것은 결정의 효율성이라는 데 동의할 것입니다.
구문의 힙과 규칙의 복잡성은 솔루션의 효율성을 유지하는 데 기여한 적이 없습니다. 코드 블록의 간결성, 보편성 및 가독성으로 표현되는 단순성과 간결성에 기여했습니다.
프로그래밍에서 내 규칙은 네이티브 언어와 의미 있는 변수 및 함수 이름을 사용하여 더 적은 코드, 더 적은 규칙, 더 적은 구문 및 더 적은 주석입니다.
제 메인 테제는 "솔루션에 아무것도 없이 할 수 있다면 반드시 솔루션 없이도 해야 합니다."입니다.
경화증이 여기 모였다고는 전혀 생각하지 않는다.)) 주어진 코드만 봐도 왜 쉽게 잊혀지는지 알 수 있다. 외국어로 프로그래밍한다는 바로 그 사실조차 중요한 역할을 합니다. 자신의 언어로 프로그래밍하면 완전히 다르게 느껴집니다. 긴장과 뻣뻣함이 아닌 강인함과 자유로움을 느낀다. 외국어는 더 많은 노력이 필요하고, 코드를 이해하는 데 더 많은 시간이 걸리며, 머리에서 더 빨리 날아갑니다. 바로 "생물학적 요인"입니다.
따라서 내 문제를 해결하기 위해 전체적으로 OOP를 사용하는 것은 (매우 적절하게) 비효율적이라고 생각합니다. 많은 규칙, 구문 및 모든 것이 외국어로 되어 있습니다. 따라서 재능은 실제로 돌아 가지 않습니다. 즉, 결과가 더 나쁠 것입니다. 임호.