물론 리소스와 많은 디버깅 시간으로 OOP의 아름다움에 대한 비용을 지불해야 합니다. OOP는 편리한 텍스트 래퍼로 또는 런타임 환경을 초기화할 때 최소한의 사용으로만 의미가 있습니다. 본질적으로 OOP 는 순전히 Microsoft에서 프로그래머의 작업 시간 비용을 늘리고 고급 장비의 구매를 촉진하기 위한 마케팅이었습니다. 게다가 그들 자신은 바보가 아니며 모든 소프트웨어를 C와 어셈블러로 작성합니다.
아 그리고 젠장
MS 프로그래머가 기계어로 직접 작성한다는 것은 누구나 알고 있습니다.
모든 프로그래머는 테이블에 프로세서의 기계어 코드가 적힌 소책자를 가지고 있으며 펀치 카드의 코드를 즉시 알아냅니다.
1. 그리고 예를 들면? 시끄러운 슬로건은 좋지만 정확히 무엇을 말하는지 명확하지 않습니다 ...
2. 이미 텍스트 래퍼로서 OOP가 많은 도움이 된다고 말했지만 절차적 프로그래밍에서 염두에 두지 않았기 때문이기도 합니다.
3. 왜 이러한 "개발된 구조"를 생산합니까? 코드의 속도 때문에 이것은 치명적일 것이며, 그 안에 있는 버그가 더 빨리 포착되고 더 빨라질 것이라는 사실은 아닙니다.
1. 예를 들어 개체 배열이 필요합니다. 이는 절차적 형식과 CArrayObj 및 CObject 기반 모두에서 수행할 수 있습니다. 문제는 개체를 추가 또는 제거하거나 정렬할 때 동작을 변경해야 할 때 시작됩니다. OOP에서 포인터의 실제 배열에 대한 지원과 이에 대한 작업은 기본 개체에 포함됩니다. 배열에 실제로 포함된 하위 개체를 변경해도 아무 영향을 주지 않습니다. 절차 스타일(배열에 포함된 실제 개체 변경)을 사용하면 일반적으로 개체 크기의 변경을 고려해야 하기 때문에 더 많은 위치에 영향을 줍니다. 실수하기가 훨씬 쉽습니다.
크로스 플랫폼 - OOP 스타일로 구성하는 것이 훨씬 더 편리합니다. 예를 들어, 거래 포지션의 요청에 따라 - 우리는 인터페이스를 얻었고 우리가 어떤 플랫폼에서 작업했는지는 중요하지 않습니다 - 인터페이스는 모든 주문에 대한 모든 데이터를 얻을 수 있는 가상 기능 을 제공합니다( 또한 MT4) 또는 직위(MT5)의 경우, 전문가의 관점에서 볼 때 차이가 전혀 없습니다. 전문가는 자신이 어떤 플랫폼에서 작업하는지 알 필요가 없습니다.
2. 음, 결국, "절차적 프로그래밍에서 염두에 두십시오" - 이것은 "객체-프로시저 작성", 즉 OOP에서 객체를 나타내는 데이터와 절차 사이의 일부 링크를 만드는 것입니다.
3. 그리고 우리는 많은 공통점이 있는 많은 종류의 주문을 가지고 있습니다. 기본 개체가 될 COrderInfo 개체와 그 하위 개체가 다른 유형의 주문을 나타내도록 하는 것이 합리적입니다. 동시에, 거래 프로세서(CTradeProcessor 클래스가 있음)는 전달된 주문과 이 주문을 처리하는 데 필요한 절차를 정확히 자동으로 지원합니다.
교차 링크가 가장 적은 곳에서 버그를 잡는 것이 더 쉽습니다. 그것은 캡슐화와 다형성으로도 제공됩니다. 우리는 거래 포지션 인터페이스(CTradePositionI)를 요청하며 이 포지션을 나타내는 실제 클래스(CMT4PositionInfo, CMT5PositionInfo)에 대한 모든 링크는 이 인터페이스를 통해서만 만들어지므로 실제 기능으로 직접 작업할 때보다 오류를 수정하기가 더 쉽습니다. , 거래 포지션 데이터를 반환합니다.
물론 리소스와 많은 디버깅 시간으로 OOP의 아름다움에 대한 비용을 지불해야 합니다. OOP는 편리한 텍스트 래퍼로 또는 런타임 환경을 초기화할 때 최소한의 사용으로만 의미가 있습니다. 본질적으로 OOP 는 순전히 Microsoft에서 프로그래머의 작업 시간 비용을 늘리고 고급 장비의 구매를 촉진하기 위한 마케팅이었습니다. 게다가 그들 자신은 바보가 아니며 모든 소프트웨어를 C와 어셈블러로 작성합니다.
아 그리고 젠장
MS 프로그래머가 기계어로 직접 작성한다는 것은 누구나 알고 있습니다.
모든 프로그래머는 테이블에 프로세서의 기계어 코드가 적힌 소책자를 가지고 있으며 펀치 카드의 코드를 즉시 알아냅니다.
빌 게이츠는 머리 속에서 운영 체제를 컴파일할 수 있습니다))
아 그리고 젠장
MS 프로그래머가 기계어로 직접 작성한다는 것은 누구나 알고 있습니다.
당신의 광대는 완전히 명확하지 않습니다. 어셈블러의 삽입은 코드 속도를 높이는 데 사용되는 것으로 알려져 있습니다 ...
OOP는 터미널에서 최소한으로 사용되거나 전혀 사용되지 않는다고 가정할 수 있습니다.
말한 내용에 대해 의미 있는 주장이 있습니까?
있다. 사실 Alexei는 단순히 감정적으로 반응했습니다. 기본적으로 반대 의견은 다음과 같습니다.
OOP는 일종의 복잡한 코드를 유지 관리해야 할 때 매우 유용합니다.
물론 MA 지표에 대해 모든 OOP 트릭을 사용하는 것은 의미가 없습니다. 기본 클래스가 작성될 때(Mashka의 경우에도) 모두 동일하지만 OOP 접근 방식은 최소한 일반적인 절차적 접근 방식보다 나쁘지 않습니다.
OOP의 주요 장점은 고급 개체 구조의 지원에 의해 드러납니다. 캡슐화로 인해 매번 오버로드된 함수의 모든 뉘앙스를 이해할 필요는 없습니다. 다형성으로 인해 코드 재사용 이 크게 증가합니다.
OOP의 본질은 모든 객체가 항상 속성과 연결되고 외부 세계와 상호 작용하기 위한 특정 규칙이 있는 현실 세계에 더 가깝습니다.
"근무 시간 비용 증가"에 관해서는 그렇지 않습니다. 물론 OOP 스타일로 시스템을 설계할 때는 절차적 접근 방식보다 약간 더 많은 작업이 필요합니다. 그러나 이러한 추가 비용은 작성된 코드를 유지 관리하고 변경하는 편의성으로 인해 상쇄됩니다.
개인적으로, 나는 매우 작은 "무릎에 쓰여진" 표시기를 가지고 있습니다. 나는 어떤 물건도 쓰지 않고 씁니다. 그러나 조금 더 필요한 것이 있을 때(적어도 크로스 플랫폼) - 저는 항상 OOP 스타일과 개체 라이브러리에서 사용 가능한 개발을 사용합니다.
당신의 광대는 완전히 명확하지 않습니다. 어셈블러의 삽입은 코드 속도를 높이는 데 사용되는 것으로 알려져 있습니다 ...
OOP는 터미널에서 최소한으로 사용되거나 전혀 사용되지 않는다고 가정할 수 있습니다.
1. OOP - 복잡한 코드에 대한 지원이 필요할 때 많은 도움이 됩니다.
2. 물론 MA 지표에 대해 모든 OOP 트릭을 사용하는 것은 이치에 맞지 않습니다. 기본 클래스가 작성될 때(Mashka의 경우에도) 모두 동일하지만 OOP 접근 방식은 최소한 일반적인 절차적 접근 방식보다 나쁘지 않습니다.
3. OOP의 주요 장점은 고급 객체 구조의 지원으로 드러납니다.
1. 그리고 예를 들면? 시끄러운 슬로건은 좋지만 정확히 무엇을 말하는지 명확하지 않습니다 ...
2. 이미 텍스트 래퍼로서 OOP가 많은 도움이 된다고 말했지만 절차적 프로그래밍에서 염두에 두지 않았기 때문이기도 합니다.
3. 왜 이러한 "개발된 구조"를 생산합니까? 코드의 속도 때문에 이것은 치명적일 것이며, 그 안에 있는 버그가 더 빨리 포착되고 더 빨라질 것이라는 사실은 아닙니다.
최신 컴파일러는 평균적이고 훌륭한 프로그래머보다 몇 배나 더 잘 최적화합니다.
간단하고 사소한 일이 가능할 수도 있지만 사람들이 앉아서 수동으로 알고리즘을 작성했기 때문일 수 있지만 무언가가 비표준이라면 사실과 거리가 멀며 특히 OOP 종소리와 휘파람이 있는 경우에는 더욱 그렇습니다.
드라이버에서 네, 어셈블러를 사용하지만 속도 때문이 아니라 장비로 작업하기가 더 쉽습니다.,
글쎄, 사람들은 바보가 아닙니다. 왜 그들은 복잡하고 혼란스럽고 느린 것이 필요합니까?
1. 그리고 예를 들면? 시끄러운 슬로건은 좋지만 정확히 무엇을 말하는지 명확하지 않습니다 ...
2. 이미 텍스트 래퍼로서 OOP가 많은 도움이 된다고 말했지만 절차적 프로그래밍에서 염두에 두지 않았기 때문이기도 합니다.
3. 왜 이러한 "개발된 구조"를 생산합니까? 코드의 속도 때문에 이것은 치명적일 것이며, 그 안에 있는 버그가 더 빨리 포착되고 더 빨라질 것이라는 사실은 아닙니다.
1. 예를 들어 개체 배열이 필요합니다. 이는 절차적 형식과 CArrayObj 및 CObject 기반 모두에서 수행할 수 있습니다. 문제는 개체를 추가 또는 제거하거나 정렬할 때 동작을 변경해야 할 때 시작됩니다. OOP에서 포인터의 실제 배열에 대한 지원과 이에 대한 작업은 기본 개체에 포함됩니다. 배열에 실제로 포함된 하위 개체를 변경해도 아무 영향을 주지 않습니다. 절차 스타일(배열에 포함된 실제 개체 변경)을 사용하면 일반적으로 개체 크기의 변경을 고려해야 하기 때문에 더 많은 위치에 영향을 줍니다. 실수하기가 훨씬 쉽습니다.
크로스 플랫폼 - OOP 스타일로 구성하는 것이 훨씬 더 편리합니다. 예를 들어, 거래 포지션의 요청에 따라 - 우리는 인터페이스를 얻었고 우리가 어떤 플랫폼에서 작업했는지는 중요하지 않습니다 - 인터페이스는 모든 주문에 대한 모든 데이터를 얻을 수 있는 가상 기능 을 제공합니다( 또한 MT4) 또는 직위(MT5)의 경우, 전문가의 관점에서 볼 때 차이가 전혀 없습니다. 전문가는 자신이 어떤 플랫폼에서 작업하는지 알 필요가 없습니다.
2. 음, 결국, "절차적 프로그래밍에서 염두에 두십시오" - 이것은 "객체-프로시저 작성", 즉 OOP에서 객체를 나타내는 데이터와 절차 사이의 일부 링크를 만드는 것입니다.
3. 그리고 우리는 많은 공통점이 있는 많은 종류의 주문을 가지고 있습니다. 기본 개체가 될 COrderInfo 개체와 그 하위 개체가 다른 유형의 주문을 나타내도록 하는 것이 합리적입니다. 동시에, 거래 프로세서(CTradeProcessor 클래스가 있음)는 전달된 주문과 이 주문을 처리하는 데 필요한 절차를 정확히 자동으로 지원합니다.
교차 링크가 가장 적은 곳에서 버그를 잡는 것이 더 쉽습니다. 그것은 캡슐화와 다형성으로도 제공됩니다. 우리는 거래 포지션 인터페이스(CTradePositionI)를 요청하며 이 포지션을 나타내는 실제 클래스(CMT4PositionInfo, CMT5PositionInfo)에 대한 모든 링크는 이 인터페이스를 통해서만 만들어지므로 실제 기능으로 직접 작업할 때보다 오류를 수정하기가 더 쉽습니다. , 거래 포지션 데이터를 반환합니다.