私のアプローチコアはエンジンです。 - ページ 137 1...130131132133134135136137138139140141142143144...184 新しいコメント Реter Konow 2019.01.10 21:19 #1361 Nikolai Semko: ピーターさんは、OOPの応用について何か誤解しているようですね。申し訳ないが、統合失調症の臭いがする。ニコライさん、HIERARCHYを作るのか、描画機構を作るのか、どちらですか？ もしHIERARCHY（描画にこだわらない）を構築するのであれば、なぜどこでもOOPが必要なのかは明らかでしょう。 ONEクラスに基づいて動作する描画機構を 作るのであれば、クラスそのものは必要ありません。 Class, - Classificationという言葉から。分類とは、属性による区分のことである。クラスはクラシフィケーションの派生形である。クラスが一つなら、クラシフィケーションは存在しない。 だから、その場合のクラスは、抽象的なデタラメなんです。意味がないんです。 Алексей Тарабанов 2019.01.10 21:43 #1362 クラス単体ではなく、実装が問題なのです。 Dmitry Fedoseev 2019.01.11 02:38 #1363 Реter Konow:... OOPが果たすべき役割よりも、OOPそのものが先行してしまっている印象があります。つまり、機構は完全性を追求しなければならず、そのためにブロックの数を最小にしなければならない。しかし、OOPはこれらのブロックを何らかの理由で強制的に増殖させる。その結果、メカの構造がボロボロになり、うまく動かなくなるのです。そして、さらに悪い方向に発展していくのです。 ...まあ、妄想してないで、少しはOOPを勉強した方がいいんじゃない？妄想もせず、デレデレしているはずです。 Dmitry Fedoseev 2019.01.11 02:39 #1364 Реter Konow:ニコライさん、あなたのOOPに対する愛情は、ほとんど抽象的な理由以外では正当化されないと思ったことはありませんか？ 例えば、このOOPで巨大な機構を作るのであれば、なぜそこまで必要なのかは明らかでしょう。なぜOOPが必要なのか、具体的に説明することになります。でも、比較的小さな機構を作るんですね。この手法の欠点や利点について結論を出すには、十分なコードがありません。しかし、あなたはとにかくOOPについて話し続けています。一方、OOPはあくまでツールであり、それ自体に意味はない。つまり、作るべき仕組みがなければ、OOPは必要ないのです。しかし、もしメカニズムがあるとすれば、それを作る際にOOPを必要とするほど重大なものでなければなりません。 OOPを掲げる人のほとんどは、まともなものは作らない。小さなことしかやらない。しかし、彼らのOOPに対する信念は揺るがない。また、もっと本格的な仕組みを作っている人は、OOPの素晴らしさを叫ぶことはあまりないでしょう。中には批判を口にする人もいる（何度かあった）。 ですから、あなたの主張は理論だけでなく、実践に裏打ちされたものである必要があるのです。例えば、GUI開発におけるOOPの利点について、Anatolyと議論することができます。なぜなら、ソリューションとそのニュアンスを実際に比較することができるからです。でも、あなたには理解できないから、私の主張を展開することはできない。そうだろうけど、理解できないだろうね（悪気はない）。アナトリーは逆に、よく理解できる。グローバルな仕組みづくりの経験の差が、誤解を生む主な原因です。 SZY：実務家として言わせてもらえば、プログラマーの頭脳のポテンシャルを最大限に 引き出すようなアプローチでなければなりません。そんなアプローチを自分自身で見つけてきました。OOPに関する妄想がどんどん膨らんでいく...。 仕事の真剣さは、費やした年数ではなく、結果で決まります。 Dmitry Fedoseev 2019.01.11 02:41 #1365 Реter Konow:残念ですが、ナンセンスではありません。 canvasでの描画はクラスのラッパーを必要としません。機能一覧で十分です。描画するためのメソッドアクセス 権は必要ありません。そして、あなたはそれを知っている。しかし、あなたはこの事実を否定する。当たり前のことを否定していますね。そうそう、バナナを食べるには、皮を剥くんですよ。でも、牛に角があるなら、角のある人はみんな牛なんです。 Dmitry Fedoseev 2019.01.11 02:44 #1366 Реter Konow:まあ、この辺りにはそういう人はあまりいないんですけどね。私もその一人なのでしょう。とはいえ、教えるためではありません。ただ、賢明な答えを聞くために。ONEクラスしか使わないのに、なぜ描画時にオブジェクトでクラス機能を参照するのですか？キャンバス上の描画関数は、キャンバス上の描画を参照するだけで、それ以外は何もしないので、別のビンに入れる理由がないため、1つのクラスに集めているわけです。でも、どうせ理解できないでしょう。 Dmitry Fedoseev 2019.01.11 02:45 #1367 Реter Konow:ニコライさん、HIERARCHYを作るのか、描画機構を作るのか、どちらですか？ もしHIERARCHY（描画にこだわらない）を構築するのであれば、なぜどこでもOOPが必要なのかは明らかでしょう。 ONEクラスに基づいて動作する描画機構を 作るのであれば、クラスそのものは必要ありません。 Class, - Classificationという言葉から。分類とは、属性による区分のことである。クラスはクラシフィケーションの派生形である。クラスが一つなら、クラシフィケーションは存在しない。 だから、その場合のクラスは、抽象的なデタラメなんです。意味がないんです。ヒエラルキーと何の関係があるのですか？OOPでは継承を多用する......と、またまた妄想の嵐...。 Dmitry Fedoseev 2019.01.11 02:48 #1368 ...そして、ケーキの上のチェリー。 Vitaly Muzichenko 2019.01.11 02:58 #1369 Fast235 2019.01.11 03:28 #1370 別のかなり高価なソフトウェアで同様のプロジェクトを行ったことがあり、その時も（モジュールを追加購入しないように）回避策を使ってアイデアを実現しました。 別の高価な専用ソフトで同様のプロジェクトを行い、回避策（追加モジュールを購入しない）を講じて実装したところ、うまくいったが、一部の顧客でデッドロックに陥り、時間を無駄にした。 でも、まったく違う球体で、お客さんも見つけやすかったんです 1...130131132133134135136137138139140141142143144...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
ピーターさんは、OOPの応用について何か誤解しているようですね。
ニコライさん、HIERARCHYを作るのか、描画機構を作るのか、どちらですか？
もしHIERARCHY（描画にこだわらない）を構築するのであれば、なぜどこでもOOPが必要なのかは明らかでしょう。
ONEクラスに基づいて動作する描画機構を 作るのであれば、クラスそのものは必要ありません。
Class, - Classificationという言葉から。分類とは、属性による区分のことである。クラスはクラシフィケーションの派生形である。クラスが一つなら、クラシフィケーションは存在しない。
だから、その場合のクラスは、抽象的なデタラメなんです。意味がないんです。
...
OOPが果たすべき役割よりも、OOPそのものが先行してしまっている印象があります。つまり、機構は完全性を追求しなければならず、そのためにブロックの数を最小にしなければならない。しかし、OOPはこれらのブロックを何らかの理由で強制的に増殖させる。その結果、メカの構造がボロボロになり、うまく動かなくなるのです。そして、さらに悪い方向に発展していくのです。
...
まあ、妄想してないで、少しはOOPを勉強した方がいいんじゃない？妄想もせず、デレデレしているはずです。
ニコライさん、あなたのOOPに対する愛情は、ほとんど抽象的な理由以外では正当化されないと思ったことはありませんか？
例えば、このOOPで巨大な機構を作るのであれば、なぜそこまで必要なのかは明らかでしょう。なぜOOPが必要なのか、具体的に説明することになります。でも、比較的小さな機構を作るんですね。この手法の欠点や利点について結論を出すには、十分なコードがありません。しかし、あなたはとにかくOOPについて話し続けています。一方、OOPはあくまでツールであり、それ自体に意味はない。つまり、作るべき仕組みがなければ、OOPは必要ないのです。しかし、もしメカニズムがあるとすれば、それを作る際にOOPを必要とするほど重大なものでなければなりません。
OOPを掲げる人のほとんどは、まともなものは作らない。小さなことしかやらない。しかし、彼らのOOPに対する信念は揺るがない。また、もっと本格的な仕組みを作っている人は、OOPの素晴らしさを叫ぶことはあまりないでしょう。中には批判を口にする人もいる（何度かあった）。
ですから、あなたの主張は理論だけでなく、実践に裏打ちされたものである必要があるのです。例えば、GUI開発におけるOOPの利点について、Anatolyと議論することができます。なぜなら、ソリューションとそのニュアンスを実際に比較することができるからです。でも、あなたには理解できないから、私の主張を展開することはできない。そうだろうけど、理解できないだろうね（悪気はない）。アナトリーは逆に、よく理解できる。グローバルな仕組みづくりの経験の差が、誤解を生む主な原因です。
SZY：実務家として言わせてもらえば、プログラマーの頭脳のポテンシャルを最大限に 引き出すようなアプローチでなければなりません。そんなアプローチを自分自身で見つけてきました。
OOPに関する妄想がどんどん膨らんでいく...。
仕事の真剣さは、費やした年数ではなく、結果で決まります。
残念ですが、ナンセンスではありません。
canvasでの描画はクラスのラッパーを必要としません。機能一覧で十分です。描画するためのメソッドアクセス 権は必要ありません。そして、あなたはそれを知っている。しかし、あなたはこの事実を否定する。当たり前のことを否定していますね。
そうそう、バナナを食べるには、皮を剥くんですよ。でも、牛に角があるなら、角のある人はみんな牛なんです。
まあ、この辺りにはそういう人はあまりいないんですけどね。私もその一人なのでしょう。とはいえ、教えるためではありません。ただ、賢明な答えを聞くために。ONEクラスしか使わないのに、なぜ描画時にオブジェクトでクラス機能を参照するのですか？
キャンバス上の描画関数は、キャンバス上の描画を参照するだけで、それ以外は何もしないので、別のビンに入れる理由がないため、1つのクラスに集めているわけです。でも、どうせ理解できないでしょう。
ニコライさん、HIERARCHYを作るのか、描画機構を作るのか、どちらですか？
もしHIERARCHY（描画にこだわらない）を構築するのであれば、なぜどこでもOOPが必要なのかは明らかでしょう。
ONEクラスに基づいて動作する描画機構を 作るのであれば、クラスそのものは必要ありません。
Class, - Classificationという言葉から。分類とは、属性による区分のことである。クラスはクラシフィケーションの派生形である。クラスが一つなら、クラシフィケーションは存在しない。
だから、その場合のクラスは、抽象的なデタラメなんです。意味がないんです。
ヒエラルキーと何の関係があるのですか？OOPでは継承を多用する......と、またまた妄想の嵐...。
...そして、ケーキの上のチェリー。
別のかなり高価なソフトウェアで同様のプロジェクトを行ったことがあり、その時も（モジュールを追加購入しないように）回避策を使ってアイデアを実現しました。
別の高価な専用ソフトで同様のプロジェクトを行い、回避策（追加モジュールを購入しない）を講じて実装したところ、うまくいったが、一部の顧客でデッドロックに陥り、時間を無駄にした。
でも、まったく違う球体で、お客さんも見つけやすかったんです