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

新しいコメント
 

そして、このような荒唐無稽な心理戦のポイントは？このパターンの「目的」は、「 カプセル化を壊さずに、オブジェクトの内部状態を固定し、保持 する」（引用符で囲む、なぜならgladiolus）ことです。しかし、setState()メソッドを使わない手はない。では、カプセル化の節約はどこにあるのでしょうか？各プライベートフィールドに対してさらに2つのメソッドを書くには...。うん...かっこいい！カプセル化は維持されてる。

そして、正直に言って、この方法を実際に使うかどうか？そうでしょうか。実際には、それを明示的かつ透過的にすることになります。たとえば、同じフィールドのセットを持つ構造体や、保存と復元のためのいくつかのメソッドなどです。そして、カプセル化は本当に維持され、状態を保存する方法と復元する方法の2つだけが新たに存在することになります。

 
Igor Makanu:

OK、私はそれを保存します、私は仕事の原則をテストする必要がありました、多分これは私が探していたものです - テスターとその状態を保存することができる作業EA用の一つのコード、そして逆にテスターで「余分なジェスチャー」にリソースを無駄にしない - このパターンの一部は #ifdef -ami ;) によってカバーされることができます。

このクレーマーの意味をキーパーで理解しようとしているのですが、特に使い道が見当たりません。 むしろ、副作用の発生によるプログラミングの悪しき慣習です。 あるオブジェクトを変更すると、別のオブジェクトも変更されます。それよりも、コードの純粋性を追求したほうがいいと思います。

オブジェクトを別のオブジェクトにコピーして、それをコピーして戻すだけで、何ができないのでしょうか？ 本質的に同じことですが、より正しく、より明確なことなのです。

もし、このシングルトンがセッターとゲッターを同時に持っているならば（つまり、状態を変更することも読むこともできる）、グローバル変数を 扱うのと同じことだ。 そして、プログラマーは誰でも、グローバル状態を変更しながら作業することは悪だと知っている。 しかし、シングルトンはなぜかカウントされない )

 
Alexey Navoykov:

このカストディアンというものの意味を理解しようとしているのですが、特に利点は見当たりません。 むしろ、副作用を生み出すことによって、悪いプログラミングのやり方になっています。 あるオブジェクトを変更すると、別のオブジェクトも変更されてしまうのです。それよりも、コードの純粋性を追求したほうがいいと思います。

よりシンプルに、技術的なことを学んでいる

私は、有限状態機械の観点から自動化されたシステムの状態を評価することに慣れており、予備としてシステムの状態の「スナップショット」を保持する機会を常に持ちたいと考えています ))) 。）

 
Igor Makanu:

私はどちらかというと、有限状態機械の観点から自動化されたシステムの状態を評価することに慣れているので、システムの状態の「キャスト」をバックアップとして保持できるようにしたいといつも思っています ))) 。

ただ、そのような実装は、過度に複雑で分かりにくいと私は思います。

 
Alexey Navoykov:

狙いははっきりしている。ただ、あまりにも複雑で分かりにくいと私は思う。

嗚呼、人間とはそういうものなのだ--私が蹴られ、凸されるまで、私はそれを手に入れることはできそうにない)))

 
Igor Makanu:

残念ですが、人間とはそういうものです。自分がノッてくるまでは、到底無理です)))

そして、よくよく調べてみると、それはある種の地獄のような偽物で、コンソールアプリケーションを書いてビジュアルBASICを学ぶのと同じように、カモを現実から引き離すためのミームのようなものだと判明するのである。

こうしたパターンを研究することは、誰かのゴキブリを知るという観点、つまり自然界にあるゴキブリの姿を知るという観点だけでも面白いですね。

そして、本当にオブジェクトの状態を保持するという課題に取り組むのであれば、その方法は、単純なメソッドでもオーバーロード＝過負荷でも、好きなほうに、あるオブジェクトから別のオブジェクトにコピーできるようにすることだ。そしてその後は、この機能をカプセル化しない方がいいかもしれません。

 
Dmitry Fedoseev:

そして、オブジェクトの状態を保持するという課題に本気で取り組むなら、その方法は、あるオブジェクトを別のオブジェクトに、メソッドだけでもオーバーロード=でも、好きなほうにコピーできるようにすることです。そしてその後は、この機能をカプセル化しない方がいいかもしれません。

実際のところ、どんな技術システムも3つの基本原則に基づいて設計することができます。

- 最新規格に準拠

- 祖父がそうしてきたのだから、車輪の再発明は必要ない。

- 糞と棒で作って改造するのはやめたほうがいい

)))


冗談です。オプションを読んで遊ぶ時間があるので、フォーラムで不明な点を簡単に説明してもらう機会もあり、活用しています ;)

 
Alexey Navoykov:

このカストディアンというものの意味を理解しようとしているのですが、特に利点は見当たりません。 むしろ、副作用を生み出すことによって、悪いプログラミングのやり方になっています。 あるオブジェクトを変更すると、別のオブジェクトも変更されてしまうのです。それよりも、コードの純粋性を追求したほうがいいと思います。

オブジェクトを別のオブジェクトにコピーして、それをコピーして戻すだけで、何ができないのでしょうか？ 実質的には同じことですが、より正しく、より明確な方法です。

このシングルトンがセッターとゲッターを同時に持っている（つまり、状態を変更することも読むこともできる）場合、グローバル変数を 扱うのと同じことになる。 そして、プログラマーは誰でも、グローバル状態を変更しながら作業するのは悪だと知っている。 しかし、シングルトンはなぜか数えない ）。

大規模なプロジェクトを経験したことのないプログラマーらしい視点だと思います。 鈍感で申し訳ありませんが、基本が悪いというのは他に説明がつきません )

 
Dmitry Fedoseev:

そして、よくよく調べてみると、それはある種の地獄のような偽物で、コンソールアプリケーションを書いてビジュアルBASICを学ぶのと同じように、カモを現実から遠ざけるためのミームのようなものだと判明するのです。

こうしたパターンを研究することは、誰かのゴキブリを知るという観点、つまり自然界にあるゴキブリの姿を知るという観点だけでも面白いですね。

そして、本当にオブジェクトの状態を保持するという課題に取り組むのであれば、その方法は、単純なメソッドでもオーバーロード＝過負荷でも、好きなほうに、あるオブジェクトから別のオブジェクトにコピー できるようにすることだ。そして、その先には、この機能をカプセル化したいという思いが落ちていくのかもしれません。

ドミトリー この場合、キーパーとプロトタイプ、そしてそれらの組み合わせと発現の可能性のタスクを少し混同しているのでしょう。最初のSnapshotは、Prototypeと違って必ずしもオブジェクト全体をコピーする必要はない。

そして、カプセル化の必要性は、多くの人が参加する大規模なプロジェクトで 主に現れます。ここにあるほとんどのタスクのようなおもちゃの場合、もちろんオーバーキルです)

 
Alexey Navoykov:

1）このカストマーというものの意味を考えているのですが、メリットがわかりません。
2) 副作用を作るのは、本質的に悪いプログラミングのやり方です。
3）ある対象を変えると、別の対象も変わる。やはり、コードの純粋性を追求したほうがいいんです。
4) 単純にオブジェクトを別のオブジェクトにコピーして、それをコピーバックすることを妨げるものは何ですか？ 本質的には同じですが、より正しく、より明確です。

もし、このシングルトンがセッターとゲッターを同時に持っているならば（つまり、状態を変更することも読むこともできる）、グローバル変数を 扱うのと同じことだ。 そして、グローバル状態を変更して作業することが悪であることは、プログラマーなら誰でも知っている。 しかし、シングルトンはなぜかカウントされない )

設置したのは向こう、要らないから自分のものに......」という派ではないのですか？???


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


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