OOPの専門家に質問です。 - ページ 4 1234567891011...55 新しいコメント Реter Konow 2019.08.25 12:14 #31 Igor Makanu: アクセス権修飾子により、コンパイル時にエラーを検出可能 一般的に、すべてのこれは、クラスとの仕事を複雑にしない、それを使用しないでください、公共の場ですべてを書き込む。といった具合に、仕事がしやすくなります。 SZZY：OOP、カプセル化、継承など、素敵なフレーズがたくさん......。しかし、他のプログラミングスタイルと比べた場合、OOPの最も重要な利点は、すべてのデータ（クラスフィールド）とこれらのデータを扱う機能（クラスメソッド）を一つの場所（クラス）に格納することである - 本で言えばカプセル化である。もし、タスクがクラスを拡張することが できるのであれば、階層が必要になり、ベースクラスとその子孫が存在することになります - これを使うかどうかは、あなた次第です。 また、すべてのオブジェクトのプロパティは、配列に「カプセル化」することができます。また、特定のポインタプロパティを介してオブジェクト間の関係を指定することができます。各プロパティにはインデックスが付けられ、その値は特定のセルに格納されるため、そこには秩序がある。 オブジェクト自体はカーネルにカプセル化されています。アクセスは、オブジェクト番号とプロパティ番号で行うのが最もシンプルです。同一コントロールのオブジェクト間の遷移は、プロパティポインタを介して行われます。 Igor Makanu 2019.08.25 12:30 #32 Реter Konow: また、オブジェクトのすべてのプロパティを配列に「カプセル化」することも可能です。また、特定のポインタプロパティによって、オブジェクト間の関係を指定することもできます。各プロパティにはインデックスが付けられ、その値は特定のセルに格納されるため、そこには秩序がある。オブジェクト自体はカーネルにカプセル化されています。アクセスは、オブジェクト番号とプロパティ番号で行うのが最もシンプルです。同一コントロールのオブジェクト間の遷移は、プロパティポインタを介して行われます。 そもそも、こんなの便利じゃない！？ さらに、あなたはすでにコードの読みやすさについて上に書きました（同様に上に速度について言及しました - 実行速度は、プログラミングスタイルではなく、何か他のものに依存します）。 一般的に、他のどこでもそうですが、やってみるまでわからない、OOPスタイルで書き始めると、特定のアクションや特定の質問を受けることになります。 AIを語るなら、データとそれを使った作業を分離する必要もあり、OOPならそれが容易にできるだろう SZZ：OOPでは何が良いかというと、例えばMQLでExpert Advisorの設定を例に挙げると、様々なタイプのデータがあり、その設定はブロック単位で繰り返されています。 この設定を一つのブロックにしてクラスのフィールドを記述し、その設定をクラスに渡すのですが、パラメータ付きのコンストラクタを作って、そのEA設定を使って動作するメソッドを書いた方が簡単なのです。これらをすべて行った上で、クラスのインスタンスの配列、あるいはクラスのインスタンスをいくつか作成する（「クラス型変数」）、それで終わりです。問題は、複数の配列を作成せず、それぞれの配列を識別するメソッドを作成し、配列の変更を行う以外に、この呼び出しで処理されるべきではないデータを損なわない程度の関数群を作成し、一つのクラスを書くことで解決します......。 ZZZY：イマイチ、OOPは便利なだけで、継承がなければOOPを使う必要はない、というある種の伝説があるのですが......。ノーコメント、私がいないと泡沫の議論になる Реter Konow 2019.08.25 12:41 #33 Igor Makanu: そもそも、こんなの便利じゃない！？ さらに、あなたはすでにコードの読みやすさについて上に書きました（同様に上に速度について言及しました - 実行速度は、プログラミングスタイルではなく、何か他のものに依存します）。 一般的に、他のどこでもそうですが、やってみるまでわからない、OOPスタイルで書き始めると、特定のアクションや特定の質問を受けることになります。 AIを語るなら、データとそれを使った作業を分離する必要もあり、OOPならそれが容易にできるだろう SZZ：OOPでは何が良いかというと、例えばMQLでExpert Advisorの設定を例に挙げると、様々なタイプのデータがあり、その設定はブロック単位で繰り返されています。 設定を1ブロックとして、その設定をクラスに渡すためのクラスフィールドを記述しますが、パラメータ付きのコンストラクタを作って、そのEA設定と連携するメソッドを記述する方が簡単です。これらをすべて行った上で、クラスのインスタンスの配列、あるいはクラスのインスタンスをいくつか作成する（「クラス型変数」）、それで終わりです。問題は、複数の配列を作成せず、それぞれの配列を識別するメソッドを作成し、配列の変更を行う以外に、この呼び出しで処理されるべきではないデータを損なわない程度の関数群を作成し、一つのクラスを書くことで解決します......。 ZZZY：イマイチ、OOPは便利なだけで、継承がなければOOPを使う必要はない、というある種の伝説があるのですが......。ノーコメント、私がいないと泡沫の議論になる 快適かどうか、主観的な質問です。データのレイアウトは表形式がいい。また、葡萄の房や木の形を好む人もいます。また、葡萄の房や木のようなものを好む人もいます。でも、お言葉を真摯に受け止め、OOPでデータを扱う基本原則を身につけようと思います。 Artyom Trishkin 2019.08.25 12:50 #34 Реter Konow: 快適かどうか、主観的な質問です。データのレイアウトは表形式がいい。また、葡萄の房や木の形を好む人もいます。また、葡萄の房や木のようなものを好む人もいます。でも、おっしゃることを真剣に考え、OOPでデータを扱う基本原則を把握するようにします。 ポインタの配列へのポインタの配列が2次元のテーブルであることは、すでに一度お話ししたとおりです。1つのリストが行、1つ目に位置するリストが列です。自分たちのリストを持つことができる。といった具合に、日が暮れるまで。これが、あなたが求めている階層です。しかも、たった1クラスで実行される。 Nikolai Semko 2019.08.25 13:42 #35 Реter Konow: OOPでは、「オブジェクト」は、そのフィールド（プロパティ）が宣言されたクラスへの参照である。私は、オブジェクトは、プロパティの番号付けされたセットであり、各プロパティは配列のセルであると理解しています。そこが違うんです。 Peterさん、クラスそのものが定義されているときは、そのクラスの中に他のクラスのインスタンスがプロパティとして存在していても、メモリは確保されないということを明確に理解する必要がありますね。したがって、クラスへの参照はできず、クラス・オブジェクトへの参照のみが可能です。 クラスのインスタンス（オブジェクト）が宣言（生成）された時点でメモリが 確保される。 HHすなわち、プログラム中にクラスがあっても、そのインスタンスがなければ、コンパイラはそのクラスを無視（気づかない）する。 ただし、1つだけ例外があります。静的メソッドやパラメータがある場合は、クラス定義時にメモリを確保することができます。 Реter Konow 2019.08.25 13:54 #36 Artyom Trishkin: 以前、ポインタの配列へのポインタの配列は2次元のテーブルであると言ったことがあります。1つのリストが行、最初のリストに横たわるリストが列です。自分たちのリストを持つことができる。といった具合に、日が暮れるまで。これが、あなたが求めている階層です。しかも、たった1クラスで実行される。 理論的にはそうです。しかし、階層的なリンク間の遷移（条件付き-帰納と演繹、すなわち特定から一般への往復）が連鎖的に行われるように整理することが必要である。つまり、ポインタの順序は、ループの中で過剰な「ターン」や「ジャンプ」をせずに、任意の（正しい）方向に移動できるような特別な方法で構成されるべきなのです。したがって、ポインターの単純なテーブルレイアウトは、おそらくうまくいかないでしょう。 追加されました。 でも、うまくいくかもしれない。まだわかりません。 Реter Konow 2019.08.25 13:57 #37 Igor Makanu: この疑問を実践してみないと、何が便利で何が不便に思えるのかが見えてきません )))。 ここでは、MQLで何百回となく使われている、新しいバーの 決定という些細な例を紹介します。 OK、これは動作するコードですが、2つのTFに対して新しいバーを定義する必要がある場合はどうなりますか？ また、ターミナルからすべてのTFを使用したい場合はどうなりますか？ というのは、OOPではこのようになります。 そして、私が今しなければならないことは、CNewbar クラスのインスタンスをいくつか宣言することです。 この問題は、すでに公開で解決済みです。すべてのシンボルとすべてのタイムフレームのテーブルを作成し、それをループして、新しいバーのイベントを固定することでした。このイベントのいずれかの関数が最初に呼び出された後、そのフラグはテーブルから消去される。OOPに比べ、どの程度複雑なのか判断がつきません。しかし、実際には、むしろシンプルで便利なソリューションです。 Реter Konow 2019.08.25 14:00 #38 Nikolai Semko: Peterさん、クラスの中に他のクラスのインスタンスがプロパティとして入っていても、クラス自体にはメモリが割り当てられないということを明確に理解する必要があります。 したがって、クラスへの参照はできず、クラス・オブジェクトへの参照のみが可能です。 クラスのインスタンス（オブジェクト）が宣言（生成）されるときにメモリが 確保される。 HHすなわち、プログラム中にクラスがあっても、そのインスタンスがなければ、コンパイラはこのクラスを無視（気づかない）する。 それは知りませんでした。面白いですね。問題は、OOPを使うことで、どの程度まで全階層のデータをループで簡単に扱えるようになるかです。どんなエンジンでも、その主要なメカニズムであるループがあります。ループワークが優れているほど、つまりデータを掘り下げることができるほど、できる仕事が増えるのです。 Nikolai Semko 2019.08.25 14:06 #39 クラスオブジェクトが生成されると、クラスのすべてのプロパティ（変数）のためのメモリが確保される 以外に、コンストラクタの1つが起動されます（複数存在する場合もあります）。コンストラクタには、ノンパラメトリック（デフォルト）、パラメトリック（クラスのインスタンス生成時に何らかのパラメータを指定する場合）、コピーコンストラクタ（クラスのインスタンスのパラメータに別のクラスのインスタンスを指定する場合）があります。 Artyom Trishkin 2019.08.25 14:07 #40 Реter Konow: 理論的にはそうです。しかし、階層的なリンク間の遷移（条件付き-帰納と演繹、すなわち特定から一般への往復）が連鎖的に行われるように整理することが必要である。つまり、ポインタの順序は、ループの中で過剰な「ターン」や「ジャンプ」をせずに、任意の（正しい）方向に移動できるような特別な方法で構成されるべきなのです。したがって、ポインターの単純なテーブルレイアウトでは、おそらくうまくいかないでしょう。 すべてのリストには、すでにバイナリサーチが備わって います。これは、検索されたプロパティをひとつひとつ見ていくのではなく、そのプロパティでフィルタリングすることを意味します。その結果、探している項目のインデックスを得ることができる。 1234567891011...55 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
アクセス権修飾子により、コンパイル時にエラーを検出可能
一般的に、すべてのこれは、クラスとの仕事を複雑にしない、それを使用しないでください、公共の場ですべてを書き込む。といった具合に、仕事がしやすくなります。
SZZY：OOP、カプセル化、継承など、素敵なフレーズがたくさん......。しかし、他のプログラミングスタイルと比べた場合、OOPの最も重要な利点は、すべてのデータ（クラスフィールド）とこれらのデータを扱う機能（クラスメソッド）を一つの場所（クラス）に格納することである - 本で言えばカプセル化である。もし、タスクがクラスを拡張することが できるのであれば、階層が必要になり、ベースクラスとその子孫が存在することになります - これを使うかどうかは、あなた次第です。
また、オブジェクトのすべてのプロパティを配列に「カプセル化」することも可能です。また、特定のポインタプロパティによって、オブジェクト間の関係を指定することもできます。各プロパティにはインデックスが付けられ、その値は特定のセルに格納されるため、そこには秩序がある。オブジェクト自体はカーネルにカプセル化されています。アクセスは、オブジェクト番号とプロパティ番号で行うのが最もシンプルです。同一コントロールのオブジェクト間の遷移は、プロパティポインタを介して行われます。
そもそも、こんなの便利じゃない！？
さらに、あなたはすでにコードの読みやすさについて上に書きました（同様に上に速度について言及しました - 実行速度は、プログラミングスタイルではなく、何か他のものに依存します）。
一般的に、他のどこでもそうですが、やってみるまでわからない、OOPスタイルで書き始めると、特定のアクションや特定の質問を受けることになります。
AIを語るなら、データとそれを使った作業を分離する必要もあり、OOPならそれが容易にできるだろう
SZZ：OOPでは何が良いかというと、例えばMQLでExpert Advisorの設定を例に挙げると、様々なタイプのデータがあり、その設定はブロック単位で繰り返されています。 この設定を一つのブロックにしてクラスのフィールドを記述し、その設定をクラスに渡すのですが、パラメータ付きのコンストラクタを作って、そのEA設定を使って動作するメソッドを書いた方が簡単なのです。これらをすべて行った上で、クラスのインスタンスの配列、あるいはクラスのインスタンスをいくつか作成する（「クラス型変数」）、それで終わりです。問題は、複数の配列を作成せず、それぞれの配列を識別するメソッドを作成し、配列の変更を行う以外に、この呼び出しで処理されるべきではないデータを損なわない程度の関数群を作成し、一つのクラスを書くことで解決します......。
ZZZY：イマイチ、OOPは便利なだけで、継承がなければOOPを使う必要はない、というある種の伝説があるのですが......。ノーコメント、私がいないと泡沫の議論になる
そもそも、こんなの便利じゃない！？
さらに、あなたはすでにコードの読みやすさについて上に書きました（同様に上に速度について言及しました - 実行速度は、プログラミングスタイルではなく、何か他のものに依存します）。
一般的に、他のどこでもそうですが、やってみるまでわからない、OOPスタイルで書き始めると、特定のアクションや特定の質問を受けることになります。
AIを語るなら、データとそれを使った作業を分離する必要もあり、OOPならそれが容易にできるだろう
SZZ：OOPでは何が良いかというと、例えばMQLでExpert Advisorの設定を例に挙げると、様々なタイプのデータがあり、その設定はブロック単位で繰り返されています。 設定を1ブロックとして、その設定をクラスに渡すためのクラスフィールドを記述しますが、パラメータ付きのコンストラクタを作って、そのEA設定と連携するメソッドを記述する方が簡単です。これらをすべて行った上で、クラスのインスタンスの配列、あるいはクラスのインスタンスをいくつか作成する（「クラス型変数」）、それで終わりです。問題は、複数の配列を作成せず、それぞれの配列を識別するメソッドを作成し、配列の変更を行う以外に、この呼び出しで処理されるべきではないデータを損なわない程度の関数群を作成し、一つのクラスを書くことで解決します......。
ZZZY：イマイチ、OOPは便利なだけで、継承がなければOOPを使う必要はない、というある種の伝説があるのですが......。ノーコメント、私がいないと泡沫の議論になる
快適かどうか、主観的な質問です。データのレイアウトは表形式がいい。また、葡萄の房や木の形を好む人もいます。また、葡萄の房や木のようなものを好む人もいます。でも、おっしゃることを真剣に考え、OOPでデータを扱う基本原則を把握するようにします。
OOPでは、「オブジェクト」は、そのフィールド（プロパティ）が宣言されたクラスへの参照である。私は、オブジェクトは、プロパティの番号付けされたセットであり、各プロパティは配列のセルであると理解しています。そこが違うんです。
HHすなわち、プログラム中にクラスがあっても、そのインスタンスがなければ、コンパイラはそのクラスを無視（気づかない）する。
以前、ポインタの配列へのポインタの配列は2次元のテーブルであると言ったことがあります。1つのリストが行、最初のリストに横たわるリストが列です。自分たちのリストを持つことができる。といった具合に、日が暮れるまで。これが、あなたが求めている階層です。しかも、たった1クラスで実行される。
理論的にはそうです。しかし、階層的なリンク間の遷移（条件付き-帰納と演繹、すなわち特定から一般への往復）が連鎖的に行われるように整理することが必要である。つまり、ポインタの順序は、ループの中で過剰な「ターン」や「ジャンプ」をせずに、任意の（正しい）方向に移動できるような特別な方法で構成されるべきなのです。したがって、ポインターの単純なテーブルレイアウトは、おそらくうまくいかないでしょう。
追加されました。
でも、うまくいくかもしれない。まだわかりません。
この疑問を実践してみないと、何が便利で何が不便に思えるのかが見えてきません )))。
ここでは、MQLで何百回となく使われている、新しいバーの 決定という些細な例を紹介します。
OK、これは動作するコードですが、2つのTFに対して新しいバーを定義する必要がある場合はどうなりますか？ また、ターミナルからすべてのTFを使用したい場合はどうなりますか？
というのは、OOPではこのようになります。
そして、私が今しなければならないことは、CNewbar クラスのインスタンスをいくつか宣言することです。
この問題は、すでに公開で解決済みです。すべてのシンボルとすべてのタイムフレームのテーブルを作成し、それをループして、新しいバーのイベントを固定することでした。このイベントのいずれかの関数が最初に呼び出された後、そのフラグはテーブルから消去される。OOPに比べ、どの程度複雑なのか判断がつきません。しかし、実際には、むしろシンプルで便利なソリューションです。
Peterさん、クラスの中に他のクラスのインスタンスがプロパティとして入っていても、クラス自体にはメモリが割り当てられないということを明確に理解する必要があります。 したがって、クラスへの参照はできず、クラス・オブジェクトへの参照のみが可能です。 クラスのインスタンス（オブジェクト）が宣言（生成）されるときにメモリが 確保される。
理論的にはそうです。しかし、階層的なリンク間の遷移（条件付き-帰納と演繹、すなわち特定から一般への往復）が連鎖的に行われるように整理することが必要である。つまり、ポインタの順序は、ループの中で過剰な「ターン」や「ジャンプ」をせずに、任意の（正しい）方向に移動できるような特別な方法で構成されるべきなのです。したがって、ポインターの単純なテーブルレイアウトでは、おそらくうまくいかないでしょう。