繰り返しになりますが、なぜカプセル化やインターフェースが必要なのか、これはIQがワッセルマン以下であったり、実際のプロジェクトに参加したことがなかったりすると、おそらく理解できないでしょう。プロジェクトの異なる部分が異なる人によって同時に変更され、OOPDの基本原則に従わないと、バグ捕捉に膨大なコストがかかるからです。本当に、なぜExpert Advisors for Marketのスタンプのために、このようなことをするのか))
繰り返しになりますが、なぜカプセル化やインターフェースが必要なのか。これは、IQがWasserman以下であったり、実際のプロジェクトに参加したことがなかったりすると、理解できないかもしれません。プロジェクトの異なる部分が異なる人によって同時に変更され、OOPDの基本原則に従わない場合は、バグを捕まえるのに大きなコストがかかってしまいます。本当に、なぜExpert Advisors for marketのスタンプのためにこれほどまでに)))
1.ツリーのデータ構造は、すべて邪道からきていることがわかりました。
2.クラス==プライベート構造体の貧弱なC++、どうしよう、構造体やクラスは諦めた方がいいのでは？
3.そしてその通り、パターンもなく、ポインタによるソートもなく、特に大きなオブジェクトの場合はメモリの節約にもならない...。
4.インターフェイスやテンプレート関数の使用を禁止することも忘れてはならない。そうしないと、自分がどんなオブジェクトを扱っているのかが分からなくなる。
1.いや、なんで？ツリー（あるいはリンクリスト）のノードが状態を変化させるということであれば、その状態へのアクセスを手配すればよいだけのことです。コード機能としては、ユーザーがノードの状態にアクセスできるようにするべきでは ありません。ノード間のすべての反復は、myNode.NextNode() や myNode.Parent() ではなく、 tree.NextNode(myNode) や tree.Parent(myNode) というツリーそのものへのアクセスによって行わなければならない。
すなわち、変更される状態は公開されるべきではない。
2.いいですか、シャープの構造をとったのは、参考・ポインターをとることができないからです。もし、そのような制御ができない場合は、クラスの適切な命名など、個人で制御できるようにする必要があります。こう言ってはどうだろう。
class MyClass_mut; // ミュータブル
class MyClass_immut; // 変えられない
3、4は間違いです。 すべて実装可能です）ただ、オブジェクトのデータがすべてスタックを通じてコピーされるとは考えないほうがいいでしょう。 一般にオブジェクトはデータへの内部ポインタを持ちます。 これはスマートポインタのようなものです。 変更可能なオブジェクトの場合のみ、このポインタはよりスマートでなければなりません）。
ドミトリー、私はあなたを保証する、私もあなたを笑って幸せになる、よく私はこのビジネスを愛する）しかし、このケースでは、あなたも特によく笑って、誇張されています。
ショットとオブジェクトのコピーは同じではないのです。
1000バイトのオブジェクトがあり、スナップショットには200バイトが必要で、特に何百万ものスナップショットが保存されている場合、なぜ800もコピーするのか。
p/s//そして、一般的に。パターンというのは、典型的な問題を解決するための初歩的な例に過ぎないということに、みんな気づいていないんだ。そして実は、その作業は初歩的なものではなく、もっと複雑なものなのです。実際の問題を解決するためには、パターンが必要ですが、多くの場合、純粋な本の形ではなく、特定のタスクに適応させ、場合によっては互いに組み合わせ、場合によっては即興を加え、タスクが許すなら、時には簡略化して表現したり、逆に実現に「重み付け」したりするのです。
繰り返しになりますが、なぜカプセル化やインターフェースが必要なのか、これはIQがワッセルマン以下であったり、実際のプロジェクトに参加したことがなかったりすると、おそらく理解できないでしょう。プロジェクトの異なる部分が異なる人によって同時に変更され、OOPDの基本原則に従わないと、バグ捕捉に膨大なコストがかかるからです。本当に、なぜExpert Advisors for Marketのスタンプのために、このようなことをするのか))
プログラミングの課題を解決するためのアルゴリズムと、いわゆる最近流行の、OOPに特化した「デザイン パターン」を混同しているのですね。そして、他のいろいろなことを混同して、不注意に読んでしまうのです。少し前に、「構造を利用する」と書きました。しかし、あの記事を読んで、私がクラス全体のコピーの機能について書いていなければ、私たちは大人なのだから、何でも大人しくやればいいのに、余計な構造で余計なことをする必要はない、クラス全体のコピー機能を提供すればいい、ということになったはずです。
...
繰り返しになりますが、なぜカプセル化やインターフェースが必要なのか。これは、IQがWasserman以下であったり、実際のプロジェクトに参加したことがなかったりすると、理解できないかもしれません。プロジェクトの異なる部分が異なる人によって同時に変更され、OOPDの基本原則に従わない場合は、バグを捕まえるのに大きなコストがかかってしまいます。本当に、なぜExpert Advisors for marketのスタンプのためにこれほどまでに)))
.
...
4.インターフェイスやテンプレート関数の使用も禁止しておかないと、何のオブジェクトを扱っているのかわからなくなりますからね。
インターフェースとは何か、なぜ必要なのか、いつかどこかで読んだことがあるはずだ。
-
あ、それとこれ...オブジェクトの全フィールドまたは一部のフィールドを保存する機能と、アンドゥ／リドゥ機能を混同しているのは本気ですか？Photoshopの話をしましょう。
-
そして、チョコチョコとメールをくれるのは、どの人？
-
どうしたんだ？私は聖なるパターンに対するあなたの信仰の土台を揺るがしたか？
は、この本棚を調べていた。
大発見！『BASICで学ぶ人工知能とエキスパートシステム入門』1987年。 その中の1章「オブジェクト指向プログラミングの考え方」。
何も変わっていないと信じて...。
は、この本棚を調べていた。
大発見！『BASICで学ぶ人工知能とエキスパートシステム入門』1987年。 その中の1章「オブジェクト指向プログラミングの考え方」。
何も変わっていないと信じて...。
当時はSacredDesign Patternsの信奉者の教会があったわけでもなく、ずいぶん変わりました。その頃はまだ、c++被害者クラブも結成されていませんでしたしね。
当時は、デザインパターンを信奉する教会などなかったのです。
当時は聖人デザイン崇拝者の教会はありませんでした。これは今でも存在しません。ルネットを検索してみてください。ルネットでデザインパターンに関する質問の数が非常に少ない場合、それは塊として存在しないことを意味します。学生の「本」の質問はカウントされません。
読むべきものはないのですが、プロジェクトを 拡張したいときに便利です。
いろいろと変わりましたね。当時はデザインの聖パタリロ教会なんてなかったんですよ。
「デザイン パターン」とは、同じ頻度で発生するものを同じ名前で呼ぼうという取り決めに過ぎない。ちなみに、この言葉は建築（彫刻／橋／門／ポータルに関するもの）から来ているんだ。
似たようなことは似たような手法で解決することもある、必ずしもいつもそうとは限らない...。しかし、物事や方法が似ていることに同意することは、お互いを理解するために有効です。
しかし、もちろん、「馬鹿にガラスの陰茎を与えれば、それを壊して身を切るだろう」という人もいる。
これは今でも存在しない、あなたはrunetを検索することができます、runetのパターンに関する質問の数が非常に小さい場合、それは質量として存在しない、学生の "本 "の質問はカウントされません。
読むことはないのですが、プロジェクトの規模を大きくしたいときに便利なんです。
何も入っていないのです。何パターンくらい勉強したのですか？
何も埋め込まれていない。何パターンくらい勉強したのですか？
勉強した」とはどういう意味ですか？
いくつかのフォーラムで説明を読んでいれば、何十本も持っていることになります。
MQLで適用した場合、1つは - 戦略が機能し、スケールし、リファクタリングが容易 - テスターのために不要なものをすべて捨てて高速化したり、デモに直行することもある - 一般的に便利で実用的である