color m_color; // object color
...
bool CWndObj::Color(const color value)
{
//--- save new value of parameter
m_color=value;
//--- call virtual event handlerreturn(OnSetColor());
}
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[];
C++の場合、OOPの理解が一気に進んだわけではなく、手続き的なアプローチを理解してから1年半ほど経ってからOOPに取り組みました。
私もそうでした。少しずつ、少しずつ...そして、完全な理解は4〜5年経ってから（そして、これは普通の人にとっては当たり前のことです）。
ZS: ボタンの色を変えるにはどうしたらいいですか？- 前のオブジェクトを殺して、違う色の新しいボタンを作る？- また、ボタンの状態を取得する方法は？- そして、もしそれが何百ものボタンの配色であるなら、それらをすべて殺し、他のボタンを作るのですか？）
MQではどのように動作するのですか？
class CButton : public CWndObj :
class CChartObjectText : public CChartObject.
class CChartObject : public CObject :
class CWndObj : public CWnd :
したがって、CButton クラスに 関数を追加すればよいことになります。
また、MQではどのように動作するのでしょうか？
class CButton : public CWndObj :
class CChartObjectText : public CChartObject.
class CChartObject : public CObject :
class CWndObj : public CWnd :
つまり、CButton クラスに関数を追加すればいいわけです。
MQLでも、ソースコードを見ても、Delphiでも、VSでも、コード構成とロジックはいつも同じです。
いいですか、私はこのチャンネルを登録していますし、一般的に、作者に対して肯定的な見方をしていますし、論争の発端となったあなたのビデオのテーマの繰り返しさえあります。
と、もう一つ好きなチャンネルがあります。
ビデオのポイントは、OOPの観点からすると正反対です。
私の投稿を削除しました、議論は私が計画しているよりも長くかかるでしょう、私は具体的なために待つことを疑う、そして実用的な有用性なしで "球状のOOP "を議論することは最善のアイデアではありません。
MQLでも、SBのソースコードを見ても、Delphiでも、VSでも、コード構成とロジックはいつも同じです。
いいですか、私はこのチャンネルを登録していますし、一般的に、作者に対して肯定的な見方をしていますし、論争の発端となったあなたのビデオのテーマを繰り返すことさえあります。
と、もう一つ好きなチャンネルがあります。
ビデオのポイントは、OOPの観点からすると正反対です。
私の投稿を削除しました、議論は私が計画したよりも長くかかるでしょう、私は具体的に待つことを疑う、そして実用的な使用せずに "球状のOOP "を議論することは、最良のアイデアではありません
正直なところ、私自身、OOPの考え方に触れ始めたばかりです。私は、すでに持っているわずかな経験から、より直感的にエゴール・ブガエンコ氏の意見に賛成です。
また、純粋に哲学的な観点で言うと、複雑化すると行き詰まることが多いので、「複雑な1つの部品からなる全体」よりも「単純な部品からなる全体」という図式の方が完璧 だと思うのですが、いかがでしょうか？
そこで、このビデオを見た後は、次のような論理とパラダイムを貫いてみようと思います。
ある時点で、問題を解決するには面倒な複雑化しかないと思えば、より単純な要素に 分解することです。 もし不可能に思えたら、それは間違った概念を選んだということであり、それを変えてコード全体を書き直さなければならない。今後、時間の短縮につながると思います。
いろいろなバリエーションがありますね。すべては、あなたが何を必要とし、どんな想像力を持っているかによるのです。例えばこれ。
削除しました。
ピーターのトピックは、あらゆるものを引き込む非情な要素です )) 、これは単なる紹介で、この先は「コア・エンジン・コンセプト」への出口であり、ピーターはそちらの方が経験が豊富です )) 。）
ですから、このビデオを見た後は、次のような論理とパラダイムに忠実であろうと思います。
ある時点で、問題を解決するには面倒な複雑化しかないと思われたら、より単純な要素に 分解するのがよいでしょう。 もし不可能に思えたら、それは間違ったコンセプトを選んだということであり、それを変更してコード全体を書き直す必要があります。将来的には時間の節約にもなると思います。
理論的にはうまくいきますが、実際には、あなたが働く業界にもよります。ゲーム開発では、エラーがあってもゲーマーのハードウェアで補われますし、オフィスソフトでは、エラーは重要ではなく、後で修正したり書き直したりしますから別ですが、ミスをしてはいけない分野もあります。ソフトウェアと自動化 "ワゴンとワゴン" - ラックACS、ACS、振動制御、オペレータコンソール、およびアクチュエータのコントローラとセンサー、そしてそれはすべて複雑で同時に動作し、概念内の任意のエラー - よくても緊急停止、最悪の場合 - 機器の破壊や物的損害です。
何が言いたいのか？- なぜなら、そもそもコードが有効でなければならないからです何年も前から作られているものはすべて「OOPの間違った使い方」について書かれており、イノベーター...ビール片手に、マイクロソフトとグーグルの人類がいかに道を踏み外したかを夢想するのはいいことだが、今のところ説明責任はない。
あなたが最初に書き込みをしたのは（つまりあなたが心配しているということです）、私はAlexey Viktorovの 標準ライブラリに関する質問に答えて いたのです。
という問いかけは、レトリックだった。明確ではなかったのでしょうか？
という問いかけは、レトリックだった。分かりませんでしたか？
修辞的な質問には、明白な文が含まれています - 私はその文が何であるかを理解していませんでした。説明できますか？
修辞的な質問は、他の質問と同様に主張を含むことはできません。疑問は疑問のままです。同じ質問でありながら、答えを求めず、答えを期待しない。どこにもない質問。