学童のためのEOPです。 - ページ 4 1234567891011...18 新しいコメント Ivan Butko 2019.10.04 10:13 #31 Dmitry Fedoseev: いや、彼ら（小学生）には理解できないだろう。特にマトリックスみたいなのはダメですね。なぜ、このようなポリモーフィズムが必要なのか......」と言われるでしょう。ある種のポリモーフィズム？ ポリなん Dmitry Fedoseev 2019.10.04 10:14 #32 Ihor Herasko: 何がNGなんだ？ゲッターの定義を開いて 読みます。 しかし、個人情報を取得する仕組みは異なる場合があります。C#ではある方法で、C++とMQLでは別の方法です。しかし、これはメソッドから "ゲッター "の定義を奪うものではありません。 ここでは「特殊」方式と読みます。 Реter Konow 2019.10.04 10:14 #33 Dmitry Fedoseev: どの要素がxで、どの要素がyなのかを知る必要があるのです。構造を使うと、すべてが明確になり、ミスをなくし、コードの量を減らすことができます。 この場合（としましょう）、構造体は構文技術として使われており、そのデータにアクセスする際には、配列とは逆にインスタンスを掛け合わせる必要があり、不都合と釣り合いが取れているのです。 構造を使う意味はもっと深いのですが、TCはあくまでそのように提示しています。つまり、OOPとは構文技術の集合体であることがわかったのです。これが「小学生」が学ぶことです。そして、タスクの中で構文を簡略化できることを理解し、OOPを否定するようになるのです。 OOPの必要性を証明するには、構文的な証明ではなく、概念的な証明が必要です。 Ivan Butko 2019.10.04 10:15 #34 分岐をありがとうございます。好きなんです。 Ihor Herasko 2019.10.04 10:17 #35 Dmitry Fedoseev: ここでは、「特殊」な方法を読み解きます。 もう少し下にスクロールして、記事をお読みください。MQLはないが、C++はある。それともC++にもゲッターはないのでしょうか？ Dmitry Fedoseev 2019.10.04 10:19 #36 Реter Konow: この場合（としましょう）、構造体は構文技術として使われており、そのデータにアクセスする際には、配列とは逆にインスタンスを掛け合わせる必要があり、不都合と釣り合いが取れているのです。 構造を使う意味はもっと深いのですが、TCはあくまでそのように提示しています。つまり、OOPとは構文技術の集合体であることがわかったのです。これが「小学生」が学ぶことです。そして、タスクの中で構文を簡略化できることを理解し、OOPを否定するようになるのです。 OOPが必要であるという概念的な証明は必要ですが、構文的な証明は必要ありません。 何も糞をする必要はない。通常の配列と同じように使えるので、より便利です。 概念的な証明...となると、レンガ作りの分野でも必要になってくる......。を、粘土から直接壁を塗る方が便利で、そうでないことを証明しようとします。 Dmitry Fedoseev 2019.10.04 10:21 #37 Ihor Herasko: 記事をもう少しスクロールしてください。MQLはないが、C++はある。それともC++でもゲッターはないのでしょうか？ この記事も開いていない。そこで何を見ればいいのだろう？C++と何の関係があるのですか？ Реter Konow 2019.10.04 10:32 #38 Dmitry Fedoseev: 掛け算は必要ないんです。通常の配列と同じように動作しますが、すべてがより便利になっています。 概念的な証明...となると、レンガを作る分野でも必要になってきますね...。粘土をそのまま壁に塗る方が便利だし、そうでないことを証明してみてください。 データ操作におけるOOPの必要性。繰り返すが、データで。 OOPは、データを分散させ、アクセスを整理するのに役立ちます。そのためには、クラスや構造体が必要です。 座標系タスクでは、データが少なすぎるため、構造体やクラスは必要ない。タスクを拡大し、多くの種類の データをその「場」に持ち込めば、分類が必要になる。そして、クラスや構造は後からついてくるものです。 分類の必要性がなければ、クラスも必要ない。構造化の必要性がなければ、構造物は必要ない。 異なるオブジェクトが一体となった多様なデータがなければ、OOPは必要ないのです。 単調なデータの平坦なプログラムにOOPを入れるのは、コンセプトが間違っているので、トレーニングでも有害です。人々は、OOPは構文の集合体であり、それを好きなように使うものだと考えるようになりました。すべきところ、すべきでないところ。 Dmitry Fedoseev 2019.10.04 10:37 #39 Реter Konow: 1.データハンドリングにおけるOOPの必要性。再び、データで。 OOPは、データの配布やアクセスを容易にするのに役立ちます。には、クラスと構造体が必要です。 2.座標系タスクでは、データが少なすぎるため、構造やクラスは必要ない。もし、タスクの規模が大きくなり、その「場」に多くの種類の データが追加されるようになれば、分類が必要になる。この後、授業や構造物が行われる予定です。 分類の必要性がなければ、クラスも必要ない。構造化の必要性がなければ、構造も必要ない 3. 3.異なるオブジェクトが一体となった多様なデータがなければ、OOPは必要ない。 単調なデータの平坦なプログラムにOOPを入れると、トレーニングでも、コンセプトが誤って露呈してしまい、有害です。人々は、OOPを構文上のトリックのセットだと考え、それを好きなように使うようになるのです。すべきところ、すべきでないところ。 1.虚しい話だ。すべてのプログラミングは、例外なく、データを扱うことである。 2.座標タスク自体のデータは少ないですが、作業量が多ければ楽でしょう。OOPに壮大なものを求めてはいけない。データやそれを扱う方法をグループ化したものであり、コードの再利用の手段でもある。 3.どんな多様体でも、その中で独立した集団が区別できれば、クラスに分けることができ、問題ないでしょう。 Koldun Zloy 2019.10.04 10:47 #40 Реter Konow: さて、コードに移りましょう。 目的は何だったのでしょうか？- 点の座標を便利に保存するため。何のために？- クイックアクセスに POINT構造とそのインスタンスは、データに素早くアクセスするためだけのタスクで あれば、ソリューションには不要なエンティティです。 マトリックス経由でアクセスするのがどれだけ簡単か見てみましょう。 あなたは哲学者ではないとおっしゃいますが、「構造」は哲学的な概念であり、解答におけるその存在は正当化されなければならない のです。 手1」「手2」と呼ぶ方がわかりやすいかもしれませんが、「左」「右」と呼びたい方が多いでしょう。 1234567891011...18 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
いや、彼ら（小学生）には理解できないだろう。特にマトリックスみたいなのはダメですね。なぜ、このようなポリモーフィズムが必要なのか......」と言われるでしょう。ある種のポリモーフィズム？
ポリなん
何がNGなんだ？ゲッターの定義を開いて 読みます。
しかし、個人情報を取得する仕組みは異なる場合があります。C#ではある方法で、C++とMQLでは別の方法です。しかし、これはメソッドから "ゲッター "の定義を奪うものではありません。ここでは「特殊」方式と読みます。
どの要素がxで、どの要素がyなのかを知る必要があるのです。構造を使うと、すべてが明確になり、ミスをなくし、コードの量を減らすことができます。
この場合（としましょう）、構造体は構文技術として使われており、そのデータにアクセスする際には、配列とは逆にインスタンスを掛け合わせる必要があり、不都合と釣り合いが取れているのです。
構造を使う意味はもっと深いのですが、TCはあくまでそのように提示しています。つまり、OOPとは構文技術の集合体であることがわかったのです。これが「小学生」が学ぶことです。そして、タスクの中で構文を簡略化できることを理解し、OOPを否定するようになるのです。
OOPの必要性を証明するには、構文的な証明ではなく、概念的な証明が必要です。
ここでは、「特殊」な方法を読み解きます。
もう少し下にスクロールして、記事をお読みください。MQLはないが、C++はある。それともC++にもゲッターはないのでしょうか？
この場合（としましょう）、構造体は構文技術として使われており、そのデータにアクセスする際には、配列とは逆にインスタンスを掛け合わせる必要があり、不都合と釣り合いが取れているのです。
構造を使う意味はもっと深いのですが、TCはあくまでそのように提示しています。つまり、OOPとは構文技術の集合体であることがわかったのです。これが「小学生」が学ぶことです。そして、タスクの中で構文を簡略化できることを理解し、OOPを否定するようになるのです。
OOPが必要であるという概念的な証明は必要ですが、構文的な証明は必要ありません。
何も糞をする必要はない。通常の配列と同じように使えるので、より便利です。
概念的な証明...となると、レンガ作りの分野でも必要になってくる......。を、粘土から直接壁を塗る方が便利で、そうでないことを証明しようとします。
記事をもう少しスクロールしてください。MQLはないが、C++はある。それともC++でもゲッターはないのでしょうか？
この記事も開いていない。そこで何を見ればいいのだろう？C++と何の関係があるのですか？
掛け算は必要ないんです。通常の配列と同じように動作しますが、すべてがより便利になっています。
概念的な証明...となると、レンガを作る分野でも必要になってきますね...。粘土をそのまま壁に塗る方が便利だし、そうでないことを証明してみてください。
データ操作におけるOOPの必要性。繰り返すが、データで。
OOPは、データを分散させ、アクセスを整理するのに役立ちます。そのためには、クラスや構造体が必要です。
座標系タスクでは、データが少なすぎるため、構造体やクラスは必要ない。タスクを拡大し、多くの種類の データをその「場」に持ち込めば、分類が必要になる。そして、クラスや構造は後からついてくるものです。
分類の必要性がなければ、クラスも必要ない。構造化の必要性がなければ、構造物は必要ない。
異なるオブジェクトが一体となった多様なデータがなければ、OOPは必要ないのです。
単調なデータの平坦なプログラムにOOPを入れるのは、コンセプトが間違っているので、トレーニングでも有害です。人々は、OOPは構文の集合体であり、それを好きなように使うものだと考えるようになりました。すべきところ、すべきでないところ。
1.データハンドリングにおけるOOPの必要性。再び、データで。
OOPは、データの配布やアクセスを容易にするのに役立ちます。には、クラスと構造体が必要です。
2.座標系タスクでは、データが少なすぎるため、構造やクラスは必要ない。もし、タスクの規模が大きくなり、その「場」に多くの種類の データが追加されるようになれば、分類が必要になる。この後、授業や構造物が行われる予定です。
分類の必要性がなければ、クラスも必要ない。構造化の必要性がなければ、構造も必要ない 3.
3.異なるオブジェクトが一体となった多様なデータがなければ、OOPは必要ない。
単調なデータの平坦なプログラムにOOPを入れると、トレーニングでも、コンセプトが誤って露呈してしまい、有害です。人々は、OOPを構文上のトリックのセットだと考え、それを好きなように使うようになるのです。すべきところ、すべきでないところ。
1.虚しい話だ。すべてのプログラミングは、例外なく、データを扱うことである。
2.座標タスク自体のデータは少ないですが、作業量が多ければ楽でしょう。OOPに壮大なものを求めてはいけない。データやそれを扱う方法をグループ化したものであり、コードの再利用の手段でもある。
3.どんな多様体でも、その中で独立した集団が区別できれば、クラスに分けることができ、問題ないでしょう。さて、コードに移りましょう。
目的は何だったのでしょうか？- 点の座標を便利に保存するため。何のために？- クイックアクセスに
POINT構造とそのインスタンスは、データに素早くアクセスするためだけのタスクで あれば、ソリューションには不要なエンティティです。 マトリックス経由でアクセスするのがどれだけ簡単か見てみましょう。
あなたは哲学者ではないとおっしゃいますが、「構造」は哲学的な概念であり、解答におけるその存在は正当化されなければならない のです。
手1」「手2」と呼ぶ方がわかりやすいかもしれませんが、「左」「右」と呼びたい方が多いでしょう。