color m_color; // object color
...
bool CWndObj::Color( const color value )
{
//--- save new value of parameter
m_color= value ;
//--- call virtual event handlerreturn (OnSetColor());
}
모든 것이 정확합니다. 모든 OOP 트릭은 MQL에서도 다음과 같습니다. - SB의 소스 코드를 봤습니다. Delphi에서도, VS에서도 - 코드 구조와 논리는 항상 반복됩니다.
봐, 내 구독에이 채널이 있습니다. 일반적으로 저자에 대해 긍정적 인 의견이 있습니다. 분쟁이 시작된 비디오 주제의 반복도 있습니다.
내가 좋아하는 또 다른 채널이 있습니다.
OOP 측면에서 비디오의 의미는 정반대입니다.
내 메시지를 삭제했습니다. 논의가 계획보다 오래 걸릴 것입니다. 구체적인 내용을 기다릴 것인지 의심스럽습니다. 실질적인 이점 없이 "구형 OOP"에 대해 논의하는 것은 최선의 생각이 아닙니다.
솔직히 나 자신도 이제 슬슬 PLO에 진입하기 시작했다. 나는 Egor Bugaenko에 더 직관적으로 그리고 우리가 이미 가지고 있는 약간의 경험을 기반으로 동의합니다. 더군다나 나는 복잡함이 막다른 골목에 이르는 경우가 많다는 것을 순수하게 철학적으로 알고 있기 때문에 "하나의 복잡한 구성요소로 이루어진 전체"보다 "단순한 구성요소로 이루어진 전체"라는 계획이 더 완벽하다고 생각합니다. 그래서 시청 후이것비디오 다음 논리와 패러다임을 고수하려고 노력할 것입니다. 어떤 시점에서 문제를 해결할 수 있는 유일한 방법이 복잡한 복잡성을 통해서만 해결되는 것처럼 보인다면 문제를 더 간단한 요소로 쪼개야 할 때입니다. 이것이 불가능한 것 같으면 잘못된 개념을 선택한 것이며 이를 변경하고 전체 코드를 다시 작성해야 합니다.앞으로 시간을 절약할 수 있을 것 같아요.
많은 옵션. 그것은 모두 당신이 필요로하는 것과 당신의 상상력이 충분한 것에 달려 있습니다. 예를 들어 그렇습니다.
class A
{
public :
A( void ) { };
~A( void ) { };
};
class B
{
public :
B( void ) { };
~B( void ) { };
};
class C
{
public :
C( void ) { };
~C( void ) { };
};
struct STest
{
A a[];
B b[];
C c[];
} test[];
그래서 시청 후이것비디오 다음 논리와 패러다임을 고수하려고 노력할 것입니다. 어떤 시점에서 문제를 해결할 수 있는 유일한 방법이 복잡한 복잡성을 통해서만 해결되는 것처럼 보인다면 문제를 더 간단한 요소로 쪼개야 할 때입니다. 이것이 불가능한 것 같으면 잘못된 개념을 선택한 것이며 이를 변경하고 전체 코드를 다시 작성해야 합니다.앞으로 시간을 절약할 수 있을 것 같아요.
이론적으로는 작동할 것이고 실제로는 작동할 것입니다. 게임 개발을 제외하고 오류가 그다지 중요하지 않은 게이머의 게임 하드웨어 또는 사무용 소프트웨어로 오류를 보상하는 게임 개발을 제외하고는 작업할 산업에 따라 다릅니다. 그러면 우리는 패치 또는 다시 작성, 프로그래머의 활동 영역이 있습니다. 실수를 할 수 없으며 생산 자동화에 대해 작업했으며 자동화는 조명과 에너지 - 전력 터빈으로 깜박이지 않았습니다. 소프트웨어 및 자동화 "대차가 있는 왜건" - 자동 제어 시스템의 랙, 자동화된 프로세스 제어 시스템, 진동 제어, 작업자 워크스테이션 및 컨트롤러 및 액추에이터의 센서, 이 모든 것이 복합적으로 동시에 작동하며 개념의 모든 실수는 비상 사태입니다. 기껏해야 중지, 최악의 장비 파괴 및 물질적 손상.
무엇을 위한 것입니까? - 코드가 무엇보다 먼저 효율적이어야 한다는 사실을 다시 한 번 강조합니다! 수년에 걸쳐 만들어진 모든 것이 "OOP의 잘못된 사용"에 기록되어 있으며 혁신가는 ... 음, 맥주 한 잔에 앉아 Microsoft와 Google이 틀렸다는 꿈을 꾸었습니다. 멋지네요! 하지만 아직 책임은 없다
네, C++에서는 OOP에 대한 이해가 바로 오지 않습니다. 절차적 접근 방식을 이해한 후 1년 반 정도가 지나면서 OOP에 조금씩 입문하기 시작했습니다.
글쎄, 나는 똑같이한다 - 조금씩 ... 그리고 완전한 이해는 4-5 년 후에 만 온다 (그리고 이것은 평범한 사람에게 정상이다)
추신: 버튼 색상을 변경하는 방법은 무엇입니까? - 이전 개체를 죽이고 다른 색상의 새 버튼을 만드시겠습니까? - 버튼의 상태를 얻는 방법은 무엇입니까? - 그리고 이것이 수백 개의 버튼의 색 구성표라면 - 다시 모든 것을 죽이고 다른 것을 만드시겠습니까? ;)
MQ에서는 어떻게 됩니까?
클래스 CButton : 공개 CWndObj :
클래스 CChartObjectText : 공개 CChartObject
클래스 CChartObject: 공개 CObject:
클래스 CWndObj : 공개 CWnd :
따라서 CButton 클래스 에 함수를 추가하는 것으로 충분합니다.
MQ에서는 어떻게 됩니까?
클래스 CButton : 공개 CWndObj :
클래스 CChartObjectText : 공개 CChartObject
클래스 CChartObject: 공개 CObject:
클래스 CWndObj : 공개 CWnd :
따라서 CButton 클래스 에 함수를 추가하는 것으로 충분합니다.
모든 것이 정확합니다. 모든 OOP 트릭은 MQL에서도 다음과 같습니다. - SB의 소스 코드를 봤습니다. Delphi에서도, VS에서도 - 코드 구조와 논리는 항상 반복됩니다.
봐, 내 구독에이 채널이 있습니다. 일반적으로 저자에 대해 긍정적 인 의견이 있습니다. 분쟁이 시작된 비디오 주제의 반복도 있습니다.
내가 좋아하는 또 다른 채널이 있습니다.
OOP 측면에서 비디오의 의미는 정반대입니다.
내 메시지를 삭제했습니다. 논의가 계획보다 오래 걸릴 것입니다. 구체적인 내용을 기다릴 것인지 의심스럽습니다. 실질적인 이점 없이 "구형 OOP"에 대해 논의하는 것은 최선의 생각이 아닙니다.
모든 것이 정확합니다. 모든 OOP 트릭은 MQL에서도 다음과 같습니다. - SB의 소스 코드를 봤습니다. Delphi에서도, VS에서도 - 코드 구조와 논리는 항상 반복됩니다.
봐, 내 구독에이 채널이 있습니다. 일반적으로 저자에 대해 긍정적 인 의견이 있습니다. 분쟁이 시작된 비디오 주제의 반복도 있습니다.
내가 좋아하는 또 다른 채널이 있습니다.
OOP 측면에서 비디오의 의미는 정반대입니다.
내 메시지를 삭제했습니다. 논의가 계획보다 오래 걸릴 것입니다. 구체적인 내용을 기다릴 것인지 의심스럽습니다. 실질적인 이점 없이 "구형 OOP"에 대해 논의하는 것은 최선의 생각이 아닙니다.
솔직히 나 자신도 이제 슬슬 PLO에 진입하기 시작했다. 나는 Egor Bugaenko에 더 직관적으로 그리고 우리가 이미 가지고 있는 약간의 경험을 기반으로 동의합니다.
더군다나 나는 복잡함이 막다른 골목에 이르는 경우가 많다는 것을 순수하게 철학적으로 알고 있기 때문에 "하나의 복잡한 구성요소로 이루어진 전체"보다 "단순한 구성요소로 이루어진 전체"라는 계획이 더 완벽하다고 생각합니다.
그래서 시청 후 이것 비디오 다음 논리와 패러다임을 고수하려고 노력할 것입니다.
어떤 시점에서 문제를 해결할 수 있는 유일한 방법이 복잡한 복잡성을 통해서만 해결되는 것처럼 보인다면 문제를 더 간단한 요소로 쪼개야 할 때입니다. 이것이 불가능한 것 같으면 잘못된 개념을 선택한 것이며 이를 변경하고 전체 코드를 다시 작성해야 합니다. 앞으로 시간을 절약할 수 있을 것 같아요.
많은 옵션. 그것은 모두 당신이 필요로하는 것과 당신의 상상력이 충분한 것에 달려 있습니다. 예를 들어 그렇습니다.
내 게시물을 삭제했습니다. 토론이 예상보다 오래 걸릴 것입니다.
Peter의 테마는 경로에 있는 모든 것을 끌어들이는 무자비한 요소입니다)), 이것은 단지 소개일 뿐이며, 앞으로는 "코어 엔진 개념"으로의 출구이며 Peter는 더 많은 경험을 가지고 있습니다)).
그래서 시청 후 이것 비디오 다음 논리와 패러다임을 고수하려고 노력할 것입니다.
어떤 시점에서 문제를 해결할 수 있는 유일한 방법이 복잡한 복잡성을 통해서만 해결되는 것처럼 보인다면 문제를 더 간단한 요소로 쪼개야 할 때입니다. 이것이 불가능한 것 같으면 잘못된 개념을 선택한 것이며 이를 변경하고 전체 코드를 다시 작성해야 합니다. 앞으로 시간을 절약할 수 있을 것 같아요.
이론적으로는 작동할 것이고 실제로는 작동할 것입니다. 게임 개발을 제외하고 오류가 그다지 중요하지 않은 게이머의 게임 하드웨어 또는 사무용 소프트웨어로 오류를 보상하는 게임 개발을 제외하고는 작업할 산업에 따라 다릅니다. 그러면 우리는 패치 또는 다시 작성, 프로그래머의 활동 영역이 있습니다. 실수를 할 수 없으며 생산 자동화에 대해 작업했으며 자동화는 조명과 에너지 - 전력 터빈으로 깜박이지 않았습니다. 소프트웨어 및 자동화 "대차가 있는 왜건" - 자동 제어 시스템의 랙, 자동화된 프로세스 제어 시스템, 진동 제어, 작업자 워크스테이션 및 컨트롤러 및 액추에이터의 센서, 이 모든 것이 복합적으로 동시에 작동하며 개념의 모든 실수는 비상 사태입니다. 기껏해야 중지, 최악의 장비 파괴 및 물질적 손상.
무엇을 위한 것입니까? - 코드가 무엇보다 먼저 효율적이어야 한다는 사실을 다시 한 번 강조합니다! 수년에 걸쳐 만들어진 모든 것이 "OOP의 잘못된 사용"에 기록되어 있으며 혁신가는 ... 음, 맥주 한 잔에 앉아 Microsoft와 Google이 틀렸다는 꿈을 꾸었습니다. 멋지네요! 하지만 아직 책임은 없다
당신은 나에게 첫 번째를 썼습니다 (당신이 걱정하는 것을 의미합니다), 나는 일반적으로 표준 라이브러리에 대한 Alexey Viktorov 의 질문에 대답 했습니다
질문은 수사학적이었습니다. 명확하지 않았습니까?
질문은 수사학적이었습니다. 명확하지 않았습니까?
수사학적 질문에 명백한 진술이 포함되어 있습니다. 그 진술이 무엇인지 이해하지 못했습니다. 설명해주실 수 있나요?
수사학적 질문은 다른 질문과 마찬가지로 어떤 식으로든 진술을 포함할 수 없습니다. 질문은 아프리카에 있습니다. 이것은 같은 질문이지만 요구하지도 않고 대답을 기대하지도 않습니다. 질문은 어디에도 없습니다.