MQL5におけるOOPに関する質問 - ページ 55 1...484950515253545556575859606162...96 新しいコメント Aleksey Mavrin 2020.05.18 13:42 #541 Dmitry Fedoseev: 瑣末なことにとらわれている。面白みがない。ここでの「Keeper」パターンの議論の要点は、カプセル化の維持を約束するようなものでありながら、各フィールドにいくつかのパブリックメソッドを作成することで実装されていることでした。一番大事なメッセージを聞き取れなかったのはおかしい。 私は行き詰まっているのではなく、対談相手としてのあなたへの敬意から、あなたの言葉の意味を理解し、あなたの自己矛盾を解き明かそうとしているのです。どうやら無駄だったようだ。 あなたの「聖なるパターン」の泡に興味がある人は、ここにもいないと思います。 Aleksey Mavrin 2020.05.18 13:43 #542 Dmitry Fedoseev: ここでは、すべてが明確で、具体的で、正統的です。BOOKがあるんです!このBOOKでは、これらのパターンを整理しています。デザインパターンとかいう本です。しかし、本だけでなく、インターネット上でそれらについての多くのサイトがあり、さらにWikipediaで、主なものは、主題が正規化されていることです))...そして、デザインパターンを理解していない人 - 平民、それらをマスターした人 - 彼は人生自体をマスターしている!......と。アーメン! まるでピエロだな、アラフォー。そんなにムカつくならOOPスレから出ていけばいいじゃん) Valeriy Yastremskiy 2020.05.18 13:44 #543 Dmitry Fedoseev: ここでは、すべてが明確で、具体的で、正統的です。BOOKがあるんです!このBOOKでは、これらのパターンを整理しています。デザインパターンとかいう本です。しかし、この本に限らず、インターネットには彼らに関するWeb-siteがたくさんあり、wikipediaでも、主語が正典になっています))。 もちろん、グローバル変数が 100個までなら関数なしでもいいし、EAが50個以上ならクラスが適切だし、開発者が20人以上、メソッドが20個以上いて変数の数が不明ならパターンが必要だというのは正しく理解しています。開発者が一人しかいないのなら、もしそうなら、そうでもないのでは? Dmitry Fedoseev 2020.05.18 13:44 #544 Aleksey Mavrin: 私は行き詰まっているのではなく、対談相手としてのあなたへの敬意から、あなたの言葉の意味を理解し、あなたの自己矛盾を解き明かそうとしているのです。どうやら無駄だったようだ。 あなたの「聖なるパターン」の泡に興味がある人は、ここにもいないと思います。 私は何も矛盾していません。矛盾しているのはあなたのパターンの方で、それについてはすでに2回書きました。思い出させてあげましょう:「キーパー」パターンはカプセル化の維持を約束しますが、各プライベートフィールドに対して2つのパブリックメソッドを作成することで実装します。 私のパターンのどこに矛盾を感じたのか、教えてください。 Dmitry Fedoseev 2020.05.18 13:44 #545 Valeriy Yastremskiy: もちろん、グローバル変数が 100個までなら関数なしでもいいし、EAが50個以上ならクラスが適切だし、開発者が20人以上、メソッドが20個以上、変数の数が不明ならパターンが必要だと正しく理解しています。開発者が1人しかいないのなら、ともかく、そうでもないのでは? そもそも開発者には頭脳が必要です。 Dmitry Fedoseev 2020.05.18 13:48 #546 Aleksey Mavrin: まるでピエロだな、アラフォー。そんなに嫌ならOOPスレから出ればいいじゃん) 何が「それ」なのか?私はOOPが好きです。しかし、これらの悪名高いパターンは、実際のOOPとはむしろ遠い関係にある。 Aleksey Mavrin 2020.05.18 13:51 #547 Dmitry Fedoseev: 私は矛盾していません。矛盾しているのはあなたのパターンの方で、それについてはすでに2回書きました。思い出してください。「キーパー」パターンはカプセル化を維持することを約束していますが、プライベートフィールドごとに2つのパブリックメソッドを作成することで実装 されています。 今ならわかるよ。すべてのパターンに対して感情をぶつけただけで、言葉の意味がなくなってしまったんですね。 しかし、Snapshotでは、Snapshot用のネストされたクラスを使用することで、この問題を解決しています。 言語がサポートしていない場合、私は同意する、この欠点がありますが、私は覚えているいくつかの松葉杖のトリックで回避することができます。 Dmitry Fedoseev 2020.05.18 13:54 #548 Aleksey Mavrin: 今ならわかるよ。すべてのパターンに対して、感情を水増ししただけで、言葉の意味は失われてしまったということですね。 しかし、Snapshotでは、ネストされたクラスを使用することで、この問題を解決しています。 言語がサポートしていない場合、確かにこの欠点はありますが、いくつかの松葉杖のトリックで回避することができると記憶しています。 勘違いしていますね。 ネストしたクラスが書けるかどうかは、大きな違いではありません。このスレッドには、ネストされたクラスと、プライベートフィールドごとに2つのパブリックメソッドがあるコード例があります。 Aleksey Mavrin 2020.05.18 13:58 #549 Dmitry Fedoseev: それ」って何?私はOOPが好きです。しかし、これらの悪名高いパターンは、本当のOOPとはかなり遠い関係にある。 何度も言いますが、パターンの上で祈る人はいません。これらはあくまで参考となるパターンです。 しかし、「OOPとは関係ない」と言い切るのは、ちょっと違いますね。 私の謙虚な経験では、純粋な書籍の形態では、稀な例外を除いてほとんど使われることはありません。通常、あるパターンに適したタスクがあれば、それは少なくとも他のパターンのタスクと一緒になっていて、2~3~10以上のパターンをどう掛け合わせるか、それはプログラマー/アーキテクトの頭脳の仕事なんです。 Aleksey Mavrin 2020.05.18 14:01 #550 Dmitry Fedoseev: 何もわかっていない。 ネストしたクラスが書けるかどうかは関係なく、大きな違いではありません。このスレッドには、ネストされたクラスと、プライベートフィールドごとに2つのパブリックメソッドを持つコード例があります。 もう何度も何度も、私は馬鹿で何もわかっていないと言われているのに、とっくに失せろと送らなかった自分の冷静さを誇りに思います) 基本的に - ネストされたクラスは、プライベートフィールドのパブリックメソッドをオプションにする、それはあなたが書いているカプセル化違反です。 他に反論は? 1...484950515253545556575859606162...96 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
瑣末なことにとらわれている。面白みがない。ここでの「Keeper」パターンの議論の要点は、カプセル化の維持を約束するようなものでありながら、各フィールドにいくつかのパブリックメソッドを作成することで実装されていることでした。一番大事なメッセージを聞き取れなかったのはおかしい。
私は行き詰まっているのではなく、対談相手としてのあなたへの敬意から、あなたの言葉の意味を理解し、あなたの自己矛盾を解き明かそうとしているのです。どうやら無駄だったようだ。
あなたの「聖なるパターン」の泡に興味がある人は、ここにもいないと思います。
ここでは、すべてが明確で、具体的で、正統的です。BOOKがあるんです!このBOOKでは、これらのパターンを整理しています。デザインパターンとかいう本です。しかし、本だけでなく、インターネット上でそれらについての多くのサイトがあり、さらにWikipediaで、主なものは、主題が正規化されていることです))...そして、デザインパターンを理解していない人 - 平民、それらをマスターした人 - 彼は人生自体をマスターしている!......と。アーメン!
まるでピエロだな、アラフォー。そんなにムカつくならOOPスレから出ていけばいいじゃん)
ここでは、すべてが明確で、具体的で、正統的です。BOOKがあるんです!このBOOKでは、これらのパターンを整理しています。デザインパターンとかいう本です。しかし、この本に限らず、インターネットには彼らに関するWeb-siteがたくさんあり、wikipediaでも、主語が正典になっています))。
もちろん、グローバル変数が 100個までなら関数なしでもいいし、EAが50個以上ならクラスが適切だし、開発者が20人以上、メソッドが20個以上いて変数の数が不明ならパターンが必要だというのは正しく理解しています。開発者が一人しかいないのなら、もしそうなら、そうでもないのでは?
私は行き詰まっているのではなく、対談相手としてのあなたへの敬意から、あなたの言葉の意味を理解し、あなたの自己矛盾を解き明かそうとしているのです。どうやら無駄だったようだ。
あなたの「聖なるパターン」の泡に興味がある人は、ここにもいないと思います。
私は何も矛盾していません。矛盾しているのはあなたのパターンの方で、それについてはすでに2回書きました。思い出させてあげましょう:「キーパー」パターンはカプセル化の維持を約束しますが、各プライベートフィールドに対して2つのパブリックメソッドを作成することで実装します。
私のパターンのどこに矛盾を感じたのか、教えてください。
もちろん、グローバル変数が 100個までなら関数なしでもいいし、EAが50個以上ならクラスが適切だし、開発者が20人以上、メソッドが20個以上、変数の数が不明ならパターンが必要だと正しく理解しています。開発者が1人しかいないのなら、ともかく、そうでもないのでは?
そもそも開発者には頭脳が必要です。
まるでピエロだな、アラフォー。そんなに嫌ならOOPスレから出ればいいじゃん)
何が「それ」なのか?私はOOPが好きです。しかし、これらの悪名高いパターンは、実際のOOPとはむしろ遠い関係にある。
私は矛盾していません。矛盾しているのはあなたのパターンの方で、それについてはすでに2回書きました。思い出してください。「キーパー」パターンはカプセル化を維持することを約束していますが、プライベートフィールドごとに2つのパブリックメソッドを作成することで実装 されています。
今ならわかるよ。すべてのパターンに対して感情をぶつけただけで、言葉の意味がなくなってしまったんですね。
しかし、Snapshotでは、Snapshot用のネストされたクラスを使用することで、この問題を解決しています。
言語がサポートしていない場合、私は同意する、この欠点がありますが、私は覚えているいくつかの松葉杖のトリックで回避することができます。
今ならわかるよ。すべてのパターンに対して、感情を水増ししただけで、言葉の意味は失われてしまったということですね。
しかし、Snapshotでは、ネストされたクラスを使用することで、この問題を解決しています。
言語がサポートしていない場合、確かにこの欠点はありますが、いくつかの松葉杖のトリックで回避することができると記憶しています。
勘違いしていますね。
ネストしたクラスが書けるかどうかは、大きな違いではありません。このスレッドには、ネストされたクラスと、プライベートフィールドごとに2つのパブリックメソッドがあるコード例があります。
それ」って何?私はOOPが好きです。しかし、これらの悪名高いパターンは、本当のOOPとはかなり遠い関係にある。
何度も言いますが、パターンの上で祈る人はいません。これらはあくまで参考となるパターンです。
しかし、「OOPとは関係ない」と言い切るのは、ちょっと違いますね。
私の謙虚な経験では、純粋な書籍の形態では、稀な例外を除いてほとんど使われることはありません。通常、あるパターンに適したタスクがあれば、それは少なくとも他のパターンのタスクと一緒になっていて、2~3~10以上のパターンをどう掛け合わせるか、それはプログラマー/アーキテクトの頭脳の仕事なんです。
何もわかっていない。
ネストしたクラスが書けるかどうかは関係なく、大きな違いではありません。このスレッドには、ネストされたクラスと、プライベートフィールドごとに2つのパブリックメソッドを持つコード例があります。
もう何度も何度も、私は馬鹿で何もわかっていないと言われているのに、とっくに失せろと送らなかった自分の冷静さを誇りに思います)
基本的に - ネストされたクラスは、プライベートフィールドのパブリックメソッドをオプションにする、それはあなたが書いているカプセル化違反です。 他に反論は?