MQL5トレーニング - ページ 19 1...1213141516171819202122 新しいコメント TheXpert 2012.04.06 19:36 #181 papaklass: 質問させてください。手続き型プログラミングとOOPの根本的な違いは何ですか？ひと言、つまり違いのエッセンスです。そもそも、手続き的なアプローチであっても、構造がないと難しいですから。これは少なくとも、ある種のデータ整理である。OOPでは、設計の 段階で抽象的な実体やその関係を気楽に確認することができます。そして、実装の特殊性を特に気にすることなく、個々にでもシンプルにコーディングすることができるのです。そして、すべてがより論理的で読みやすくなっているように見えます。そして、その方が早く効果が出ることが多いのです。そして、より早く実装されることが最大のポイントです。コードが増えるかもしれないにもかかわらず。 Yedelkin 2012.04.07 00:49 #182 papaklass:本末転倒な定式化をするのではなく、自分の理解を表現してほしかったのです。ノーとは、ノーという意味です。私のことを話します。 まあ、「本の処方箋を渡した」わけではないのですが......。）全然形になってないんですけどね～、説明付きで。私は、この質問は試験問題で、ピルのおかげですでに答えがわかっているのだとばかり思っていました。そうして出来上がったのが、この作品です :)個人的な経験について答えることを拒否したわけではありません。時には、現象を「感じる」だけで十分であり、「どうしてそうなるのか」「その深い意味は何か」といった哲学的な問いを立てることなく、単純に「仕組み」を例示することで理解することができるのです。リファレンスマニュアルにあるテトリスへの言及は、私にとって十分なものでしたし、この例は、ごくごく初歩の段階で十分なものだったのです。どのクラスオブジェクトを作成するかによって、派生クラスの仮想関数が呼び出さ れます。void CTetrisField::NewShape() { //--- случайным образом создаём одну из 7 возможных фигур int nshape=rand()%7; switch(nshape) { case 0: m_shape=new CTetrisShape1; break; case 1: m_shape=new CTetrisShape2; break; case 2: m_shape=new CTetrisShape3; break; case 3: m_shape=new CTetrisShape4; break; case 4: m_shape=new CTetrisShape5; break; case 5: m_shape=new CTetrisShape6; break; case 6: m_shape=new CTetrisShape7; break; } //--- отрисовываем m_shape.Draw(); //--- }初期データによって挙動が異なるオブジェクトを直感的に作成できるのは、見ていて十分理解できました。次に-フォーラムからテトリスの全ファイルと、Reference、ライブラリなどの資料を要求しました。そして、オフとなった。フォーラムでは、このテーマでたくさんの質問が寄せられています。papaklassホームページの情報をいろいろ読んでみても、やはりOOPが何なのかよくわからない。 ただ、アプローチの仕方が決定的に違うんです。特に科学的な観点から「OOPとは何か」と考えたことはありません。- 新しい、そして理解しがたい用語のファサードの背後にある本質を失わないために。 ぶっきらぼうに、利用可能な事例を勉強しに行ったのです。 papaklassホームページでいろいろな情報を読んでも、まだOOPが何なのか理解できませんでした。 MQL5 Reference/Fundamentals / Object-Oriented Programming.ページを読んでみてください。どうやら、これだけで十分だったようだ。第三者による資料で他の定義を探す必要はない。 --- 2012.04.07 07:03 #183 papaklass:私の質問の答えです。プロデュアプログラミングは動作（動詞）に着目し、オブジェクト指向プログラミングは対象（名詞）に 着目する。ここが大きな違いです。理論上も実際もそうです。手続き型プログラミングは、「何をすべきか（動詞） 」という問いに答えるものです。 オブジェクト指向プログラミングの動詞と 対象物（名詞）を説明する（形容詞）。つまり、OOPはコードを多くの品詞を持つ意味のある文章に一般化した上位構造である。動詞だけで話す者は、手続きで生きることを許される。自分のコードを語りたいと思う人は、OOPで書かせればいい。PS.どんだけプログラマー論者ばかりでうんざりしてるんだよ、クソが。 もうすぐ「OOP vs プロシージャ」というトピックを容赦なく潰します。 Yedelkin 2012.04.07 07:15 #184 sergeev:PS.プログラマー論者ばかりで嫌になるぜ、クソが。 もうすぐ、「OOP vs Procedures」という題材を容赦なく殺すことになる。 なぜ、一度に「殺す」必要があるのですか？MQL5の初心者の多くは、「手続き型プログラミング」に慣れています。また、OOPの必要性や意味について質問があれば、根気よく説明・理解させる必要があります。学校の先生のように、毎年同じことを繰り返す。辛抱強く説明し、教師がこのトピックを繰り返すのに飽きたからといって、「失せろ」と言わないことです。 Andrey F. Zelinsky 2012.04.07 07:19 #185 sergeev:PS.どんだけプログラミング論者に辟易してるんだよ、クソが。 もうすぐ「OOP vs プロシージャ」というテーマが無慈悲に殺されることになる。"句読点を自在にアレンジするのではなく、用語集を書けば「無慈悲に殺す」人はいなくなる。しかし、OOPの「プラクティショナー」を読むと、OOPの高度な思想を持った専門家の「カースト」のようなものなのです。MQL5は、カスタマだけでなく、あらゆるレベルの理解と能力に対応した言語です。インジケーターとエキスパートアドバイザーの標準例が、これを証明しています。プログラミング言語は目的ではなく、手段です。PPが目的を達成するのに十分であれば - そうであるように。もし、誰かがOOPを使う方が簡単でわかりやすいのであれば、そうしてください。そして、目標を達成するために - 根本的な違いはありません - 特に90％のローコードマイクロファンクションインジケータとExpert Advisorは、主に書かれています。 Dmitriy Skub 2012.04.07 07:25 #186 papaklass:講座の冒頭でこのようなフレーズに出会うと、その本全体が何であるかが一目瞭然です。そして、なぜかすべてがうまくいくのです。属性はオブジェクトのプロパティ であること、実装とメソッドは同じもの（関数）であること、そして最後にクラスはオブジェクトで構成されていることを理解していますね。オブジェクトは属性（プロパティ）やメソッド（機能）を持つだけでなく、相互に作用することができます。同時に、彼ら（オブジェクト）は他のオブジェクトの属性やメソッドを知る必要はない。このような構成要素からクラスが作られ、それがまた相互に影響し合うというわけです。 お粥も作れないほど、何もかもが山盛りになってしまいましたね)))本に書いてあるなんてことはありえない。 Yedelkin 2012.04.07 07:35 #187 abolk:プログラミング言語は目的ではなく、手段です。目標を達成するためにPPで十分なら、それでいいのです。OOPが誰かにとってより明確でシンプルであるなら、それはそれでいいのです。 ワイズ自分の経験から判断すると：単一通貨の指標はPPに書かれている。また、マルチカレンシーエキスパートアドバイザーはOOPを使って 書かれています（OOPがなければ、私の場合、全く登場しなかったでしょうから）。 削除済み 2012.04.07 08:13 #188 Как уже надоели все эти программистские теоретики, блин. もうすぐ「OOP vs プロシージャ」のスレッドは容赦なく潰されるでしょう。これは、両者のメリット、デメリット、使用場所、使用方法などが理解されていないためです。PPはこのタスク_1にこのような利点と欠点を与え、OOPはこのタスク_1にこのような利点と欠点を与え、PPはこのタスク_2にこのような利点と欠点を与え、OOPはこのタスク_2にこのような利点と欠点を与える...といった簡単な例で説明した記事。クラスとインターフェースの比較は、もし後者が5つ出てきたら、その微妙な違いにもっと注意を払うことが肝要だと思うのです。そして、すべて単純な問題を解決することに偏っており、ここが難しいところです。説明や例はできるだけ単純で短く、しかしPPやOOPの原則を使う必要があります。そうすれば、あるトピックに沿って体系化された、簡単な応用例が棚に並んだ場所に、すべてを送り込んで、スレッドをクラッシュさせることが可能になるはずです。イェデルキン ワイズ自分の経験から判断すると、1通貨単位の指標はPPに書かれている。そして、マルチカレンシーエキスパートアドバイザーはOOPを使って書かれています（OOPがなければ全く登場しなかったでしょう）。 イェデルキン様もし興味があれば、手続き的に設計された多通貨カーネルを送ることができます（オープンバーで動作します）。このコードは4用に書かれたものですが、5にも対応します - その上で両バリアントのパフォーマンスを比較することができます。 Yedelkin 2012.04.07 08:25 #189 -Alexey-: イェデルキン様もし興味があれば、手続き的に設計された多通貨カーネルを送ることができます（オープンバーで動作します）。4のコードが書かれています。 できれば、みんなが平和に、理解し合いながら生きていくために。私の書き込みに関しては、OOPについての理解を述べただけです。それは三度間違うかもしれないが、「私の」理解なのだ。私がOOPの助けを借りて解決できた問題の一部は、PPの枠組みの中でも解決できる可能性があることを全く否定するものではありません。abolkの 発言の知恵は、まさに「PPで目標が達成されるなら、それでいいのだ」ということだ。もし、誰かがOOPを使う方が明確でシンプル であるなら、それはそれでいいのです。追記をさせていただきました。 削除済み 2012.04.07 08:34 #190 Yedelkin: 私は、可能な限り、皆が相互理解のもとに一緒に暮らすことに賛成です。私のメッセージでは、もっぱらOOPの理解について述べました。それは（理解）3回間違っているかもしれない-しかし、それは「私の」理解である。私がOOPの助けを借りて解決できた問題の一部は、PPの枠組みの中でも解決できる可能性があることを全く否定するものではありません。abolkの 発言の知恵は、まさに「PPで目標が達成されるなら、それでいいのだ」ということだ。もし、誰かがOOPを使う方が簡単でわかりやすい のなら、そうしてください」。 私もそう思います。そして、どちらか一方の好みの気分で戦うためには、フォーラムのユーザー同士で競争させるのが一番です。そのようなタスクがあります...: パフォーマンス、メモリ消費量、コードサイズ、移植性...の面で、どのアプローチが正確に勝てるでしょうか? 1...1213141516171819202122 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
質問させてください。手続き型プログラミングとOOPの根本的な違いは何ですか？ひと言、つまり違いのエッセンスです。
そもそも、手続き的なアプローチであっても、構造がないと難しいですから。これは少なくとも、ある種のデータ整理である。
OOPでは、設計の 段階で抽象的な実体やその関係を気楽に確認することができます。そして、実装の特殊性を特に気にすることなく、個々にでもシンプルにコーディングすることができるのです。
そして、すべてがより論理的で読みやすくなっているように見えます。そして、その方が早く効果が出ることが多いのです。そして、より早く実装されることが最大のポイントです。コードが増えるかもしれないにもかかわらず。
本末転倒な定式化をするのではなく、自分の理解を表現してほしかったのです。ノーとは、ノーという意味です。私のことを話します。
まあ、「本の処方箋を渡した」わけではないのですが......。）全然形になってないんですけどね～、説明付きで。私は、この質問は試験問題で、ピルのおかげですでに答えがわかっているのだとばかり思っていました。そうして出来上がったのが、この作品です :)個人的な経験について答えることを拒否したわけではありません。
時には、現象を「感じる」だけで十分であり、「どうしてそうなるのか」「その深い意味は何か」といった哲学的な問いを立てることなく、単純に「仕組み」を例示することで理解することができるのです。リファレンスマニュアルにあるテトリスへの言及は、私にとって十分なものでしたし、この例は、ごくごく初歩の段階で十分なものだったのです。
どのクラスオブジェクトを作成するかによって、派生クラスの仮想関数が呼び出さ れます。
初期データによって挙動が異なるオブジェクトを直感的に作成できるのは、見ていて十分理解できました。次に-フォーラムからテトリスの全ファイルと、Reference、ライブラリなどの資料を要求しました。そして、オフとなった。フォーラムでは、このテーマでたくさんの質問が寄せられています。
ホームページの情報をいろいろ読んでみても、やはりOOPが何なのかよくわからない。
ただ、アプローチの仕方が決定的に違うんです。特に科学的な観点から「OOPとは何か」と考えたことはありません。- 新しい、そして理解しがたい用語のファサードの背後にある本質を失わないために。
ぶっきらぼうに、利用可能な事例を勉強しに行ったのです。
ホームページでいろいろな情報を読んでも、まだOOPが何なのか理解できませんでした。
MQL5 Reference/Fundamentals / Object-Oriented Programming.ページを読んでみてください。どうやら、これだけで十分だったようだ。第三者による資料で他の定義を探す必要はない。
私の質問の答えです。
プロデュアプログラミングは動作（動詞）に着目し、オブジェクト指向プログラミングは対象（名詞）に 着目する。ここが大きな違いです。
理論上も実際もそうです。
手続き型プログラミングは、「何をすべきか（動詞） 」という問いに答えるものです。
オブジェクト指向プログラミングの動詞と 対象物（名詞）を説明する（形容詞）。
つまり、OOPはコードを多くの品詞を持つ意味のある文章に一般化した上位構造である。
動詞だけで話す者は、手続きで生きることを許される。
自分のコードを語りたいと思う人は、OOPで書かせればいい。
PS.
どんだけプログラマー論者ばかりでうんざりしてるんだよ、クソが。
もうすぐ「OOP vs プロシージャ」というトピックを容赦なく潰します。PS.
プログラマー論者ばかりで嫌になるぜ、クソが。
もうすぐ、「OOP vs Procedures」という題材を容赦なく殺すことになる。PS.
どんだけプログラミング論者に辟易してるんだよ、クソが。
もうすぐ「OOP vs プロシージャ」というテーマが無慈悲に殺されることになる。"句読点を自在にアレンジするのではなく、用語集を書けば「無慈悲に殺す」人はいなくなる。
しかし、OOPの「プラクティショナー」を読むと、OOPの高度な思想を持った専門家の「カースト」のようなものなのです。
MQL5は、カスタマだけでなく、あらゆるレベルの理解と能力に対応した言語です。インジケーターとエキスパートアドバイザーの標準例が、これを証明しています。
プログラミング言語は目的ではなく、手段です。PPが目的を達成するのに十分であれば - そうであるように。もし、誰かがOOPを使う方が簡単でわかりやすいのであれば、そうしてください。そして、目標を達成するために - 根本的な違いはありません - 特に90％のローコードマイクロファンクションインジケータとExpert Advisorは、主に書かれています。
papaklass:
講座の冒頭でこのようなフレーズに出会うと、その本全体が何であるかが一目瞭然です。そして、なぜかすべてがうまくいくのです。属性はオブジェクトのプロパティ であること、実装とメソッドは同じもの（関数）であること、そして最後にクラスはオブジェクトで構成されていることを理解していますね。オブジェクトは属性（プロパティ）やメソッド（機能）を持つだけでなく、相互に作用することができます。同時に、彼ら（オブジェクト）は他のオブジェクトの属性やメソッドを知る必要はない。このような構成要素からクラスが作られ、それがまた相互に影響し合うというわけです。
プログラミング言語は目的ではなく、手段です。目標を達成するためにPPで十分なら、それでいいのです。OOPが誰かにとってより明確でシンプルであるなら、それはそれでいいのです。
Как уже надоели все эти программистские теоретики, блин.
もうすぐ「OOP vs プロシージャ」のスレッドは容赦なく潰されるでしょう。これは、両者のメリット、デメリット、使用場所、使用方法などが理解されていないためです。PPはこのタスク_1にこのような利点と欠点を与え、OOPはこのタスク_1にこのような利点と欠点を与え、PPはこのタスク_2にこのような利点と欠点を与え、OOPはこのタスク_2にこのような利点と欠点を与える...といった簡単な例で説明した記事。クラスとインターフェースの比較は、もし後者が5つ出てきたら、その微妙な違いにもっと注意を払うことが肝要だと思うのです。そして、すべて単純な問題を解決することに偏っており、ここが難しいところです。説明や例はできるだけ単純で短く、しかしPPやOOPの原則を使う必要があります。
そうすれば、あるトピックに沿って体系化された、簡単な応用例が棚に並んだ場所に、すべてを送り込んで、スレッドをクラッシュさせることが可能になるはずです。
ワイズ自分の経験から判断すると、1通貨単位の指標はPPに書かれている。そして、マルチカレンシーエキスパートアドバイザーはOOPを使って書かれています（OOPがなければ全く登場しなかったでしょう）。
私は、可能な限り、皆が相互理解のもとに一緒に暮らすことに賛成です。私のメッセージでは、もっぱらOOPの理解について述べました。それは（理解）3回間違っているかもしれない-しかし、それは「私の」理解である。私がOOPの助けを借りて解決できた問題の一部は、PPの枠組みの中でも解決できる可能性があることを全く否定するものではありません。abolkの 発言の知恵は、まさに「PPで目標が達成されるなら、それでいいのだ」ということだ。もし、誰かがOOPを使う方が簡単でわかりやすい のなら、そうしてください」。