記事"グラフィカルインターフェイスXI：ライブラリコードのリファクタリング(ビルド14.1)"についてのディスカッション - ページ 3 1234 新しいコメント Реter Konow 2017.07.03 15:19 #21 Anatoli Kazharski:あなたの口から出るのはお喋りだけだ。) これまでのことはすべて、あなたがそう言ったからではない。すべては最初から計画され、一定の順序で厳密に公表されたものだ。しかし、あなたはもちろんそう考えず、あなたが言うように「新しい自分を必死に探す混沌」の中にあり続けることもできる。私は気にしない。)私はまた、技術的な成長は機能の拡張や追加だけでなく、コードの圧縮や普遍化によっても条件付けられると述べた。バラバラの機能をブロックにまとめる。これはまさにあなたが記事で示したことだ。 あなたは複数のクラスを1つに統合し、コードを圧縮することを繰り返してきた。同時に、1つのクラスがいくつかの類似した要素を含み、それらの選択がモードによって実行されるという意味で、クラスはより普遍的になった。これが圧縮であり、普遍化である。繰り返すが、私は正しかった。では、どこが間違っていたのか？もちろん、私が言ったからといってすべてを実行したわけではない。それは分かっている。でも、私の言ったことは正しかった。 Andrey Khatimlianskii 2017.07.03 16:14 #22 Anatoli Kazharski:荒らしを追い払う唯一の方法を覚えていますか？そう、餌を与えないことだ。 Anatoli Kazharski 2017.07.03 16:32 #23 Andrey Khatimlianskii:荒らしを追い払う唯一の方法を覚えていますか？そう、餌を与えないことだ。説明をしてあげよう。デザートに。)Retag Konow: ...もちろん、僕が言ったから全部やったわけじゃない。それは分かっている。私の言っていることが正しかったことを除けば...。君が正しいか正しくないかなんて、誰が気にするんだ？)他人が何を言おうと、君は君が思っているとおりの人間なんだ。)あなたは自明のことを言ったし、それは最初から指摘されていた。しかし、それ以外にもあなたはナンセンスなことをたくさん放送している。例えば、このようなスキームをOOPの助けを借りて効率的に実装することは不可能だというようなことだ。OOPを知らないのに、どうしてそんな結論が出せるのか？一般的なスキームはリファクタリング前と変わっていないことにお気づきだろうか？そして、このような移行に困難はなかった。主な時間は、数十のファイルとテストに目を通すためだけに費やされた。現在の実装では、第3段階への移行はさらに簡単だろう。難しいのはまさにそこではない。もし私がそのような実装をするのであれば、最初から最後まですべてを1つのオブジェクトに描画します。一部のフォーラム・メンバーが示したように、いくつかのオブジェクトが（使用時のために）メインGUIの上に表示されることはありません。プログラマーとしての個人的な成長の観点から、私はもはやそのような中途半端な方法には興味がありません。この記事で紹介されているバージョンで現在行われていることに遠く及ばない。そして、MQLアプリケーションのユーザーにはまったく違いはわからないだろう。私の現在のバージョンでは、すべての要素は別々のオブジェクトに描かれており、唯一の例外はオブジェクト-グラフィックス（OBJ_CHART）である。このような要素を、このような品質で、このような機能で、描画された形で実現できたら面白いのですが、現時点では意味がありません。このサイトでMQ開発者が紹介しているMQサービスには、私にとってもっと興味深いものがある。近い将来、文字通り「GUI」に関する記事が2つか3つ増えるだけで、その後更新されることは、あったとしてもごく稀だろう。ほとんどの場合、リソースの消費を可能な限り最小限に抑えるライブラリの深い最適化が行われるだろう。 Реter Konow 2017.07.03 17:01 #24 Anatoli Kazharski:いくつか説明しよう。デザートに)1.自分が正しいか間違っているかなんて、誰が気にする？)他人が何を言おうとも、自分にとっては自分が思っている通りの自分であることに変わりはない。)2.あなたは自明なことを言ったし、それは最初から指摘されていた。しかし、それ以外にもあなたはナンセンスなことをたくさん放送した。 3.例えば、このようなスキームをOOPの助けを借りて効率的に実装することは不可能だと。OOPを知らないのに、どうしてそんな結論が出せるのですか？4.一般的なスキームはリファクタリング前と変わっていないことにお気づきですか？そして、そのような移行に困難はなかった。主な時間は、数十のファイルとテストに目を通すためだけに費やされた。5.現在の実装では、第3段階への移行はさらに簡単だろう。難しいのはまさにそこではない。このような実装をした場合、私は最初から最後まですべてを1つのオブジェクトに描画することになり、一部のフォーラム・メンバーによって実演されたように、いくつかのオブジェクトが（使用時のために）メインGUIの上に表示されることはありません。プログラマーとしての個人的な成長の観点から、私はもはやそのような中途半端な方法には興味がない。この記事で紹介されているバージョンで現在行われていることに遠く及ばない。そして、MQLアプリケーションのユーザーにはまったく違いはわからないだろう。私の現在のバージョンでは、すべての要素は別々のオブジェクトに描かれており、唯一の例外はオブジェクト-グラフィックス（OBJ_CHART）である。このような要素を、このような品質で、このような機能で、描画された形で実現できたら面白いのですが、現時点では意味がありません。このサイトでMQ開発者が紹介しているMQサービスには、私にとってもっと興味深いものがある。近い将来、文字通り「GUI」に関する記事が2つか3つ増えるだけで、その後更新されることは、あったとしてもごく稀だろう。ほとんどの場合、ライブラリの深い最適化が行われ、リソースの消費は可能な限り最小限に抑えられるだろう。1.そうではない。もし私が間違っていて、それに対する説得力のある証拠があれば、私はそれを認め、自分の見解を変える。2.多くの場合、このような明白なことはまったく明白ではない。開発者が抽象的な思考ができ、大規模な開発プロセスを理解できることはプラスだ。あなたからはそのような理解は得られなかった。私が興味があるのは、ディテールやルーティンを掘り下げることではなく、その行動の哲学的な背景です。核心に迫り、本質を見抜く。台本やプロセスのロジックを知ることは、人によっては貴重なことなんだ。)3.今、実行されているスキームがどれほど効果的であるかを言うのは難しい。相対的なものだからだ。しかし、導入の効果を判断できるパラメーターはある。それを見つけることはできると思う。この場合、同じメカニズムを別の技術で実装した場合の効率を比較することができる。そうすれば、効果について結論を出すことができる。もしお望みなら、私たちもそれを試してみることができる。 それでも私は、この実装は十分な効果がないと思う。残念ながら、それには理由がある。 4.全く同じスキームではないあなたは基本クラスに変更を加えた。ライブラリーの「コア」に。記事の中であなたが言ったこと。外見上、スキームは似ていますが、あなたは要素を作成する異なる技術に切り替えました。5.ちなみに、私は1枚のビットマップ上に完全に描画されたGUIを作りたいとは一言も言っていない。私はその考えは悪い考えだと思っています。多くの観点から見て、明らかにベストな解決策ではない。だから私にとっては、-「中途半端な対策」ではなく、より現実的な選択肢への選択なのです。付け加えると、次のように1つのビットマップですべてを行うことができます：すべての描画要素はイメージ・ピクセルの配列です。すべての描画要素は画像ピクセルを持つ配列です。それらが作成されたら、1つのビットマップと大きな画像配列を作成し、各要素の内容を順次そこに押し込みます。その結果、ウィンドウの全内容を完全に画像化したビットマップができあがる。私はあと一歩のところまで来ている。あなたにもできると思います。 Anatoli Kazharski 2017.07.03 17:49 #25 Реter Konow:... その時に効果を結論づけることができる。あなたが望むなら、私たちはそれを見つけようとすることができる。 私はまだ、この導入が十分に効果的だとは思っていない。残念だが、理由がある。 ... まずは効果的な発表をすべきです。あなたの "効率性 "というテーマを手にした者は、あなた以外にはいない。おそらく、それを見せるのが怖いほど効果的だという事実があるからだろう。)...付け加えると、次のように1つのビットマップですべてを行うことができる：すべての描画要素はイメージ・ピクセルの配列である。すべての描画要素は画像ピクセルを持つ配列である。それらが作成されたら、1つのビットマップと大きな画像配列を作成し、各要素の内容を順次そこに押し込む。その結果、ウィンドウの全内容を完全に画像化したビットマップができあがる。...ノーコメント、Captain Obvious。) Реter Konow 2017.07.03 18:12 #26 Anatoli Kazharski: まずは効率的に出版すべきだ。なぜなら、あなたの「効率」の対象を手にしたことがある人は、あなた以外にはいないからだ。おそらく、それを見せるのが怖いほど効果的だという事実があるからだろう。)ノーコメント、キャプテン・オブライト。) では、効率を比較してみようか？私が直接提案したんだ。 Anatoli Kazharski 2017.07.03 18:15 #27 Реter Konow: では、効率を比較しましょうか？私は直接的な提案をした。 構わないよ。比べてください。) Реter Konow 2017.07.03 18:22 #28 Anatoli Kazharski: 私は気にしない。比べてみて。)OK 1.まず、使用する技術の有効性を評価する基準を定義する。2.次に、実装されたメカニズムの有効性を評価する基準を定義する。3.3.私とあなたの作った同じメカニズムを選び、テストを行う。その後、明確な結論を出す。この計画に同意しますか？ Anatoli Kazharski 2017.07.03 18:25 #29 Реter Konow:...まず我々は... 私たちじゃなくて、あなた。やることがあるんだ（よく読んで）。時間を無駄にする気はない。) Реter Konow 2017.07.03 18:31 #30 Anatoli Kazharski: 私たちじゃなくて、あなた。やることがあるんだ（もっとよく読んで）。時間を無駄にする気はない。)それは残念だ。 闘志が今どこかで休んでいるのは残念だ...）。 1234 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
あなたの口から出るのはお喋りだけだ。)
これまでのことはすべて、あなたがそう言ったからではない。すべては最初から計画され、一定の順序で厳密に公表されたものだ。しかし、あなたはもちろんそう考えず、あなたが言うように「新しい自分を必死に探す混沌」の中にあり続けることもできる。私は気にしない。)
私はまた、技術的な成長は機能の拡張や追加だけでなく、コードの圧縮や普遍化によっても条件付けられると述べた。バラバラの機能をブロックにまとめる。これはまさにあなたが記事で示したことだ。
あなたは複数のクラスを1つに統合し、コードを圧縮することを繰り返してきた。同時に、1つのクラスがいくつかの類似した要素を含み、それらの選択がモードによって実行されるという意味で、クラスはより普遍的になった。これが圧縮であり、普遍化である。
繰り返すが、私は正しかった。
では、どこが間違っていたのか？
もちろん、私が言ったからといってすべてを実行したわけではない。それは分かっている。でも、私の言ったことは正しかった。
荒らしを追い払う唯一の方法を覚えていますか？そう、餌を与えないことだ。
荒らしを追い払う唯一の方法を覚えていますか？そう、餌を与えないことだ。
説明をしてあげよう。デザートに。)
...
もちろん、僕が言ったから全部やったわけじゃない。それは分かっている。私の言っていることが正しかったことを除けば...。
君が正しいか正しくないかなんて、誰が気にするんだ？)他人が何を言おうと、君は君が思っているとおりの人間なんだ。)
あなたは自明のことを言ったし、それは最初から指摘されていた。しかし、それ以外にもあなたはナンセンスなことをたくさん放送している。例えば、このようなスキームをOOPの助けを借りて効率的に実装することは不可能だというようなことだ。OOPを知らないのに、どうしてそんな結論が出せるのか？
一般的なスキームはリファクタリング前と変わっていないことにお気づきだろうか？そして、このような移行に困難はなかった。主な時間は、数十のファイルとテストに目を通すためだけに費やされた。
現在の実装では、第3段階への移行はさらに簡単だろう。難しいのはまさにそこではない。もし私がそのような実装をするのであれば、最初から最後まですべてを1つのオブジェクトに描画します。一部のフォーラム・メンバーが示したように、いくつかのオブジェクトが（使用時のために）メインGUIの上に表示されることはありません。プログラマーとしての個人的な成長の観点から、私はもはやそのような中途半端な方法には興味がありません。この記事で紹介されているバージョンで現在行われていることに遠く及ばない。そして、MQLアプリケーションのユーザーにはまったく違いはわからないだろう。
私の現在のバージョンでは、すべての要素は別々のオブジェクトに描かれており、唯一の例外はオブジェクト-グラフィックス（OBJ_CHART）である。このような要素を、このような品質で、このような機能で、描画された形で実現できたら面白いのですが、現時点では意味がありません。このサイトでMQ開発者が紹介しているMQサービスには、私にとってもっと興味深いものがある。近い将来、文字通り「GUI」に関する記事が2つか3つ増えるだけで、その後更新されることは、あったとしてもごく稀だろう。ほとんどの場合、リソースの消費を可能な限り最小限に抑えるライブラリの深い最適化が行われるだろう。
いくつか説明しよう。デザートに)
1.自分が正しいか間違っているかなんて、誰が気にする？)他人が何を言おうとも、自分にとっては自分が思っている通りの自分であることに変わりはない。)
2.あなたは自明なことを言ったし、それは最初から指摘されていた。しかし、それ以外にもあなたはナンセンスなことをたくさん放送した。
3.例えば、このようなスキームをOOPの助けを借りて効率的に実装することは不可能だと。OOPを知らないのに、どうしてそんな結論が出せるのですか？
4.一般的なスキームはリファクタリング前と変わっていないことにお気づきですか？そして、そのような移行に困難はなかった。主な時間は、数十のファイルとテストに目を通すためだけに費やされた。
5.現在の実装では、第3段階への移行はさらに簡単だろう。難しいのはまさにそこではない。このような実装をした場合、私は最初から最後まですべてを1つのオブジェクトに描画することになり、一部のフォーラム・メンバーによって実演されたように、いくつかのオブジェクトが（使用時のために）メインGUIの上に表示されることはありません。プログラマーとしての個人的な成長の観点から、私はもはやそのような中途半端な方法には興味がない。この記事で紹介されているバージョンで現在行われていることに遠く及ばない。そして、MQLアプリケーションのユーザーにはまったく違いはわからないだろう。
私の現在のバージョンでは、すべての要素は別々のオブジェクトに描かれており、唯一の例外はオブジェクト-グラフィックス（OBJ_CHART）である。このような要素を、このような品質で、このような機能で、描画された形で実現できたら面白いのですが、現時点では意味がありません。このサイトでMQ開発者が紹介しているMQサービスには、私にとってもっと興味深いものがある。近い将来、文字通り「GUI」に関する記事が2つか3つ増えるだけで、その後更新されることは、あったとしてもごく稀だろう。ほとんどの場合、ライブラリの深い最適化が行われ、リソースの消費は可能な限り最小限に抑えられるだろう。
1.そうではない。もし私が間違っていて、それに対する説得力のある証拠があれば、私はそれを認め、自分の見解を変える。
2.多くの場合、このような明白なことはまったく明白ではない。開発者が抽象的な思考ができ、大規模な開発プロセスを理解できることはプラスだ。あなたからはそのような理解は得られなかった。私が興味があるのは、ディテールやルーティンを掘り下げることではなく、その行動の哲学的な背景です。核心に迫り、本質を見抜く。台本やプロセスのロジックを知ることは、人によっては貴重なことなんだ。)
3.今、実行されているスキームがどれほど効果的であるかを言うのは難しい。相対的なものだからだ。しかし、導入の効果を判断できるパラメーターはある。それを見つけることはできると思う。この場合、同じメカニズムを別の技術で実装した場合の効率を比較することができる。そうすれば、効果について結論を出すことができる。もしお望みなら、私たちもそれを試してみることができる。 それでも私は、この実装は十分な効果がないと思う。残念ながら、それには理由がある。
4.全く同じスキームではないあなたは基本クラスに変更を加えた。ライブラリーの「コア」に。記事の中であなたが言ったこと。外見上、スキームは似ていますが、あなたは要素を作成する異なる技術に切り替えました。
5.ちなみに、私は1枚のビットマップ上に完全に描画されたGUIを作りたいとは一言も言っていない。私はその考えは悪い考えだと思っています。多くの観点から見て、明らかにベストな解決策ではない。だから私にとっては、-「中途半端な対策」ではなく、より現実的な選択肢への選択なのです。
付け加えると、次のように1つのビットマップですべてを行うことができます：すべての描画要素はイメージ・ピクセルの配列です。すべての描画要素は画像ピクセルを持つ配列です。それらが作成されたら、1つのビットマップと大きな画像配列を作成し、各要素の内容を順次そこに押し込みます。その結果、ウィンドウの全内容を完全に画像化したビットマップができあがる。私はあと一歩のところまで来ている。あなたにもできると思います。
...
その時に効果を結論づけることができる。あなたが望むなら、私たちはそれを見つけようとすることができる。 私はまだ、この導入が十分に効果的だとは思っていない。残念だが、理由がある。
...
...
付け加えると、次のように1つのビットマップですべてを行うことができる：すべての描画要素はイメージ・ピクセルの配列である。すべての描画要素は画像ピクセルを持つ配列である。それらが作成されたら、1つのビットマップと大きな画像配列を作成し、各要素の内容を順次そこに押し込む。その結果、ウィンドウの全内容を完全に画像化したビットマップができあがる。
...
ノーコメント、Captain Obvious。)
まずは効率的に出版すべきだ。なぜなら、あなたの「効率」の対象を手にしたことがある人は、あなた以外にはいないからだ。おそらく、それを見せるのが怖いほど効果的だという事実があるからだろう。)
ノーコメント、キャプテン・オブライト。)
では、効率を比較しましょうか？私は直接的な提案をした。
私は気にしない。比べてみて。)
OK
1.まず、使用する技術の有効性を評価する基準を定義する。
2.次に、実装されたメカニズムの有効性を評価する基準を定義する。
3.3.私とあなたの作った同じメカニズムを選び、テストを行う。
その後、明確な結論を出す。
この計画に同意しますか？
...
まず我々は
...
私たちじゃなくて、あなた。やることがあるんだ（もっとよく読んで）。時間を無駄にする気はない。)
それは残念だ。
闘志が今どこかで休んでいるのは残念だ...）。