MQL5におけるOOPに関する質問 - ページ 50

新しいコメント
 
Aleksey Mavrin:

ディミトリ この場合、キーパーとプロトタイプのパターンの目的、そしてその組み合わせや現れ方を少し混同しているのではないでしょうか。 まず、SnapshotはPrototypeと違って、必ずしもオブジェクト全体をコピーする必要はない。

そして、カプセル化の必要性は、多くの人が参加する大規模なプロジェクトで主に現れます。ほとんどのようなおもちゃの場合、ちょっと冗長なんです。

結局のところ、そこに座って、変数に値を代入して、それを使うということを真面目に話すということなんです。そうそう、何でもかんでもプログラミングする場合、多くの場合、異なる変数に異なる値を代入して、それを使用することになります。しかし、今は呼び方が変わり、議論するときは眉をひそめて真剣な表情にならざるを得ません。

そして、間違えないことが重要で、すべてのフィールドが保存されていればPrototype、すべてでなければKeeperとしないと、みんなに笑われます。

 
Sergey Dzyublik:

まさか、「インターネットを導入しているんだから、インターネットは必要ない・・・」という宗派の方ではありませんよね？???


1.カストディアンは、デザイン上、変更可能なコンテンツでタイピングするときに、これらの変更が1つではなく数百になったときに変更をロールバックするために、彼らが状態を保存するために使用するパターンに似ています。例：フォトエディター、テキストエディタ...
書いてから発見 -https://refactoring.guru/ru/design-patterns/memento
2.基本的に、対象を知らない、理解していない状態で、そこにあるものを批判するのは悪手だと思うのですが...。
3.すでに理解できていないものが、どうしてもっとわかりにくく、難しくなるのか。
4.あとは、あなた次第です...。


GOPは何の関係があるのですか？

 
Sergey Dzyublik:

ひょっとして、「あいつらはintinetを導入している、俺たちは必要ない、お前はintinetだ」という宗派ではないのでしょうか？???


1.カストディアンは、デザイン上、変更可能なコンテンツでタイピングするときに、これらの変更が1つではなく数百になったときに変更をロールバックするために、彼らが状態を保存するために使用するパターンに似ています。例：フォトエディター、テキストエディタ...
書いてから発見 -https://refactoring.guru/ru/design-patterns/memento
2.基本的に、対象を知らない、理解していない状態で、そこの何かを批判するのは悪手だと思うのですが...。
3.すでに理解できていないものが、どうしてもっとわかりにくく、難しくなるのか。
4.あとは、あなた次第です...。


ずっと一緒だ！私の主張を聞いてくれてありがとう...怠けていたのです))

ただ、スナップショットは必ずしもオブジェクトの全データを保存しているわけではなく、同じオブジェクトのスナップショットが数百個あるブランチが「異なる側からのスナップショット」として存在しうることを、ポイント1で付け加えます。その場合、未使用のデータのコピーを何百枚も保存するのは、まさに最悪の行為です。

 
Dmitry Fedoseev:

こうなってくると、「変数に値を代 入して使う」ということを、その場に座って大真面目に話すことです。そうそう、何でもかんでもプログラミングしていると、多くの場合、異なる変数に異なる値が代入され、それが使用されます。しかし、今は呼び方が変わり、議論するときは眉をひそめて真剣な表情にならざるを得ません。

そして、間違えないことが重要で、すべてのフィールドが保存されていれば「プロトタイプ」、すべてでなければ「ガーディアン」、でないと男の子が笑います。

ドミトリー、私はあなたを保証する、私はあなたを笑って幸せになる、よく、私はそれを愛する）しかし、このケースでは、あなたも特によく笑って、誇張されています。

ショットとオブジェクトのコピーは同じではないのです。

1000バイトのオブジェクトがあり、スナップショットには200バイトが必要で、特に何百万ものスナップショットが保存されている場合、なぜ800もコピーするのか。

p/s//そして、一般的に。パターンというのは、典型的な問題を解決するための初歩的な例に過ぎないということに、みんな気づいていないんだ。そして実は、その作業は初歩的なものではなく、もっと複雑なものなのです。実際の問題を解決するためには、パターンが必要ですが、多くの場合、純粋な本の形ではなく、特定のタスクに適応させ、場合によっては互いに組み合わせ、場合によっては即興を加え、タスクが許すなら、時には簡略化して表現したり、逆に実現に「重み付け」したりするのです。

繰り返しになりますが、なぜカプセル化やインターフェースが必要なのか、これはIQがワッセルマン以下であったり、実際のプロジェクトに参加したことがなかったりすると、おそらく理解できないでしょう。プロジェクトの異なる部分が異なる人によって同時に変更され、OOPDの基本原則に従わないと、バグ捕捉に膨大なコストがかかるからです。本当に、なぜこれほどまでに市場向けEAに刻印を打つのか))

 
与えられた。
1.有限状態マシン(FSA)
2.KA の数は不明です。
3.宇宙船の状態：成功／失敗／動作中
4.CAは複数のスレッドで実行されるため、スレッド数は不明

パターンが許すこと。
1.プロセスごとにユニークなIDを発行する - カウンターが機能しない
2.スパ銭を糸で均一に 入れる
3.宇宙船の状態を取得する
4.KAの状態が先に発行されたタスクと同じであれば、KAを再スタートさせる
5.ACをデータベースに保存し、状態が成功した場合はフローから削除する
6.ACの状態（保存時のID）を復元し、フローに追加する。
7.EAのメッセージを交換するための共通のプールを持つために、プールはゴムではなく、削除されたEAはメッセージを受信しませんが、新しく作成されたEAは、殺されたEAから残っていない新しいメッセージを受信する必要があり、スレッドとEA間の同期が存在しない
8.パターン・メッセージプール全体の状態の保存と復元

* KA は同じタスクを実行しない
** メッセージプールが主な問題ですが、CAかDBか、あるいは？
*** もしかしたら、これはデータベースの仕事であって、パターンは必要ないのかもしれませんね？
 
?
 
Igor Makanu:
与えられた。
1.有限状態マシン(FSA)
2.KA の数は不明です。
3.宇宙船の状態：成功／失敗／動作中
4.CAは複数のスレッドで実行されるため、スレッド数は不明

パターンが許すこと。
1.プロセスごとにユニークなIDを発行する - カウンターが機能しない
2.スパ銭を糸で均一に入れる
3.宇宙船の状態を取得する
4.KAの状態が先に発行されたタスクと同じであれば、KAを再スタートさせる
5.ACをデータベースに保存し、状態が成功した場合はフローから削除する
6.ACの状態（保存時のID）を復元し、フローに追加する。
7.EAのメッセージを交換するための共通のプールを持つために、プールはゴムではなく、削除されたEAはメッセージを受信しませんが、新しく作成されたEAは、殺されたEAから残っていない新しいメッセージを受信する必要があり、スレッドとEA間の同期が存在しない
8.パターン・メッセージプール全体の状態の保存と復元

* CAは同じタスクを実行しない
** メッセージプールが主な問題ですが、CAかDBか、あるいは？
*** もしかしたら、これはデータベースの仕事であって、パターンは必要ないのかもしれませんね？
1.あなたは複雑な課題を抱えているので、質問の中でパターンという単語は、もしあれば複数形でしか使えません :)
2.スレッド間で均等に CAを追加する必要があります。シングルトンのidemakerとスレッドマネージャで実装されたファクトリーの何がいけないのか？なぜ、シンプルなカウンターが適さないのか、その理由は不明です。CAの作成はコントロールできないとか、なんなの？では、誰かのプロジェクトにアドオンを作っているのか、それとも自分のプロジェクトなのか？
7.宇宙船の作成時刻でフィルタリングしたオブザーバー。MT用のすべてのインプリメンテーション。
全てはデータベースに保存されます。データベース層は複雑ではありません。
データベースからのリストアで工場をリンクさせる - 複雑な操作は必要ありません。
そして、一般的に-ご質問の正解は-最低でもALLパターンが必要です。真面目な話です。それらをすべてマスターした上で、このような課題に取り組む必要があるのです。なぜなら、途中でデコレーターとファサード（DB用）の両方が必要になったり、エンドツーエンドイベントなどを実装するためのビジターが必要になったりすることがあるからです。

 

Sergey Dzyublik:

1.変更可能なコンテンツで タイピングする際に、これらの変更が1つではなく数百に及ぶ場合に変更をロールバックするために、状態を保存するために使用するパターンと同様の設計のキーパーである。例えば、フォトエディター、テキストエディター...。

2.むしろ、そこで何かを批判するために、その対象を知らない、理解しないというのは悪しき慣習なのでは......。

私も長い間、この問題に取り組んできましたが、経験を積むことで徐々に理解できるようになりました。オブジェクト（ポインタ）間の相互関係が多く、かつ、これらのオブジェクトが変更可能なコードは、変更不可能な恐ろしい麺です。 したがって、参照 オブジェクトを不変にするよう努力しなければ なりません。 変更可能なのは、値オブジェクト、すなわち、構造体と単純型、およびポインタだけであるべきです。

この場合、初期オブジェクトはクラスではなく構造体として宣言することが望ましい。 そうすれば、その内容を変更することができる。 もちろん、この場合、説明したパターンのようにポインタを取って保存することはなく、これは正しい。 オブジェクトを変更するには、明示的にそのメソッドを参照するか、関数への引数として渡す必要がある、すなわち

memento.restoreState(myObject);

または

myObject.restoreState(memento);

こんなもんじゃない。

memento.restoreState();

は、memento オブジェクトを変更しているように見えますが、実際には他のオブジェクトを変更しており、それはおそらくプログラムの他の場所にあります。これは、ある場所でグローバル変数を 変更し、その値を別の場所で使用するのと同じで、副作用を生みます。

すなわち、メメントには元のオブジェクトへの参照を保存してはならない。内容物だけを保存する必要があります。これは私の意見ですが、真実から遠くないと思っています )

 
Aleksey Mavrin:
一般的には、「すべてのパターンが最低限必要」というのが正しい答えです。真面目な話です。

私は自分の意見を主張するのではなく、おそらくどこかで読んだのだと思いますが、プログラミングの問題は、正しいプログラム構造と変数の良い名前を素早く見つけることの2つだけで、他のすべては非常に簡単に行うことができます。

私も本気です。

ありがとうございます、あなたのパターンを読んでみます

万が一、誰かが登場しても、初心者やトレーナーの質問アカデメイアの突撃レベルだけで、私は待ちます )))

 
Alexey Navoykov:

1) オブジェクト(ポインタ)間の相互関係が多く、しかもオブジェクトが変更可能なコードは、後で悪魔が理解できない不条理な麺である。したがって、参照オブジェクトを変更不可に する努力が必要 である。
2)変更可能なのは値オブジェクト、すなわち構造体と単純型、およびポインタだけであるべき です。
3) この場合、初期オブジェクトはクラスではなく構造体として宣言するのが望ましい。 そうすれば、その内容を変更することができる。 もちろん、議論されているパターンのように、それへのポインタを取って保存することはできないし、その 通りである。
 4)オブジェクトの変更は、明示的にそのメソッドを呼び出すか、関数の引数として渡す必要があります。
 まるでmementoオブジェクトを変更しているように見えますが、実際はプログラム内の別の場所にある別のオブジェクト です。これが副作用を生むのです。

1.データ構造の Treeは、すべて悪からきていることが判明...。
2.クラス==プライベート構造体の貧弱なC++、どうしよう、構造体やクラスは諦めた方がいいのでは？
3.そしてその通り、パターンもなく、ポインタによるソートもなく、特に大きなオブジェクトの場合はメモリの節約にもならない...。
4.インターフェイスやテンプレート関数の使用を禁止することも忘れてはならない。そうしないと、自分がどんなオブジェクトを扱っているのかが分からなくなる。

1...434445464748495051525354555657...96
新しいコメント