OOPの専門家に質問です。 - ページ 15 1...8910111213141516171819202122...55 新しいコメント Igor Makanu 2019.08.29 14:23 #141 Alexey Navoykov: だから、あなたの「カンフー」を具体的にOOPと対比させる意味がわからないのです。 本気だ！ タグコノウ。 コンセプトの特許を取ろうと思っているところです。投資家がいる。だから、真剣なんです。 昨夜、夢遊病のスレッドを読みました...。なぜか、スターウォーズのクレジットのように、Windowsの開発者の長いリストを想像してしまいました。 そしてリストの最後には、大きな文字でReTeg Konow ! Peter Konow さん、こんな感じのテキストスプライトを作れませんか？） Georgiy Merts 2019.08.29 14:50 #142 Alexey Navoykov: 今やっているプロジェクトのすべてを記憶しているんですね。過去のコードはどうなっていますか？1年前に書いたことをそのまましっかり覚えていますか？今までのコードに手を加えたり、修正したりする作業です。 そして、いずれもOOPとは関係ない。もし、あなたのコードがグローバル変数へのパブリックアクセスで構築されているなら、これは手続き型でも、OOPでも、ましてや関数型でも、どんなパラダイムでも受け入れられません。 したがって、あなたの「カンフー」をOOPと対比する意味はないでしょう。 すべてはピーターの驚異的な記憶力に懸かっている。 また、プロジェクト 全体で使われるすべての変数を記憶し、いつ、どこで変更されたか、間違った変更の箇所を簡単に見つけることができれば、まさにOOPは無意味になりますね。 Peterは、実は「アセンブラレベル」で動いているのです。どんなOOPハックやデザインパターンを考え出したとしても、結局はどんなデータアクセスも普通のメモリアドレスであり、プロセスに割り当てられたアドレス空間内では、すべてのメモリアドレスに完全にアクセスできるのだ。プロセッサ自身はカプセル化について何も知らない。 そこへ、ピーターが操作するのです。 私自身もアセンブラにハマっていた時期がありました。 ただ、メモリ機能の面でどのようにプロセッサーに対抗していくのかが課題です。 Alexey Navoykov 2019.08.29 15:11 #143 Georgiy Merts:すべてはピーターの驚異的な記憶力による。...問題は、メモリ容量でどうやってプロセッサーに対抗するかだ。 では、彼がずっと取り組んでいる1つの同じプロジェクトについて話して いるときに、どのような現象が起きているのでしょうか。当然ながら、どんなプログラマーでも、常に頭の中にあるのはそればかりである。もし、時間が経ってからコードをはっきり覚えていたら、話は別だ。 Georgiy Merts 2019.08.29 16:47 #144 Alexey Navoykov: では、彼がずっと取り組んでいる同じプロジェクトについてなら、フェノムは何なのか。当然ながら、どんなプログラマーでも、常に頭の中にあるのはそればかりである。 しばらくしてコードをはっきり覚えていたら、また次の会話。 それなら、私も只者ではありませんね。私も、ほとんど同じプロジェクトに携わって いますが、基本的な要点しか覚えていません。何を、どのような手順で修正するのか、といった詳細は、直接開発の瞬間にしかわからない。そして、この分野に戻ってくると--なぜそうで、そうでないのかを理解するために、多くの時間を費やすことになるのです。その結果、私はすべての権利を断ち切ることを支持します。理想的には、プログラムのどの場所でも、その場所でやるべきことだけにアクセスできるようにすることです。 Реter Konow 2019.08.30 14:36 #145 Alexey Navoykov: 今やっているプロジェクトのすべてを記憶しているんですね。過去のコードはどうなっていますか？1年前に書いたことをしっかり覚えていますか？今までのコードに手を加えたり、修正したりする作業です。 そして、いずれもOOPとは関係ない。もし、あなたのコードがグローバル変数へのパブリックアクセスで構築されているなら、これは手続き型でも、OOPでも、ましてや関数型でも、どんなパラダイムでも受け入れられません。 したがって、あなたの「カンフー」をOOPと対比する意味はないでしょう。 はい、古いコードはすぐに覚えて理解します。プロジェクトが 大きすぎて、何ヶ月も何年も変更されていない部分もあり、何かを改善する時が来たら（例えば古代のリスト）、ソースコードにはほとんど存在しないコメントなしで、短時間ですべての詳細を調べ、どう動くかの記憶をリフレッシュしています。素のコードを見た記憶があります。そして、なぜかそれが誰にでもできるような気がするのです。 Реter Konow 2019.08.30 14:46 #146 Alexey Navoykov: ... そして、いずれもOOPとは関係ない。もし、あなたのコードがグローバル変数へのパブリックアクセスで構築されているなら、手続き型でも、OOPでも、ましてや関数型でも、どんなパラダイムでも受け入れられません。 したがって、あなたの「カンフー」をOOPと対比する意味はないでしょう。 いや、ここのカンフーはまさにOOPなんです。多くの技やテクニックがあり、その中でも戦いの中で10％は役に立つ。しかし、なんという美しいスタイルなのでしょう。そして、ドラゴン、サル、フラミンゴ、ヒキガエル...。具体的なサンボがあるんです。刻んで、結果を出す。 Georgiy Merts 2019.08.30 15:19 #147 Реter Konow: いや、ここでカンカンになっているのはOOPです。たくさんの技やトリックがありますが、そのうち10%は戦闘で役に立ちます。しかし、なんという美しいスタイルなのでしょう。ドラゴン、サル、フラミンゴ、ヒキガエル...。具体的なサンボがあるんです。刻んで、結果を出す。 そうではありません。 カプセル化や権利関係の制約の有用性については、これまで何度も言ってきたとおりです。 継承とポリモーフィズムの有用性は、共通の仮想インターフェースがありながら、実装が大きく異なる項目のリストを扱うときによくわかる。 今週、私が遭遇した最も単純な状況を紹介します。構造体のリストがあり、その中の1つのフィールドがダブルバリューです。そこで、この値をOOPで近似することを思いついた。 OOPがなければ、対応するSLAEを作成し、それを解決するプロシージャを完全に書かなければならない。あるいは、値の配列を扱うようなプログラムがすでにある場合、そのような配列を作成し、ライブラリ関数に渡すようなプロシージャを書きます。 OOPでは、CLSMCoreクラスを継承し、ポイント値を返す仮想関数を オーバーロードしています。すぐに近似多項式の係数を求めることができる。 つまり、同じ条件下（ライブラリ関数やクラスがある場合）であれば、余計な中間配列を導入することでOOPせずに損をしてしまうのです。もちろん、どのように充填するかを正確に把握する必要があるのは言うまでもありません。(値取得関数-OOPの有無にかかわらず-を記述する必要がある）。私が思うに、最大のメリットはサポートや改造が簡単なことです。OOPでは、理解することが少なくなります。また、当初はCLSMCoreクラスを書くのにOOPなしでライブラリ近似関数を書くのと全く同じ労力を使っていました。 Реter Konow 2019.08.30 15:44 #148 Georgiy Merts: そうではありません。 カプセル化や権利関係の制約の有用性については、これまで何度も言ってきたとおりです。 継承とポリモーフィズムの有用性は、共通の仮想インタフェースを持つアイテムのリストを扱うときにはっきりとわかりますが、その実装は大きく異なります。 今週、私が遭遇した最も単純な状況を紹介します。構造体のリストがあり、その中の1つのフィールドがダブルバリューです。そこで、この値をOOPで近似することを思いついた。 OOPがなければ、対応するSLAEを作成し、それを解決するための手続きを完全に書く必要があるのです。あるいは、値の配列を扱うようなプログラムがすでにある場合、そのような配列を作成し、ライブラリ関数に渡すようなプロシージャを書きます。 OOPでは、CLSMCoreクラスを継承し、ポイント値を返す仮想関数を オーバーロードしています。すぐに近似多項式の係数を求めることができる。 つまり、同じ条件下（ライブラリ関数やクラスがある場合）であれば、余計な中間配列を導入することでOOPせずに損をしてしまうのです。もちろん、どのようにポピュレーションするかを正確に把握する必要があるのは言うまでもありません。(値取得関数-OOPの有無にかかわらず-を記述する必要がある）。私が考える最大のメリットは、まさにサポートと改造の簡便さです。OOPでは、理解することが少なくなります。また、当初はCLSMCoreクラスを書くのにOOPなしでライブラリ近似関数にかけるのと同じくらいの労力をかけていました。 例えば、関数のオーバーロードが何のために必要なのか、私には理解できないのです。不条理な話ですよね。パラメータを持たない関数を作り、その中にオーバーロードされた関数のすべての計算を書き、変数をグローバルにし、他のどの関数からの結果にもアクセスできるようにするのです。まあ、いいんじゃないですか！？ でも、違うんです!すべての計算を、同じ名前で、異なるパラメータを持つ関数に分割することにします。そして、各関数の入力パラメータを山ほど作ることになる。いいえ、それだけでは不十分です。パラメータ名を読めないようにしよう。そして、それらに混じって渡される様々な配列を作ります。そして、そのような機能を何十個も作って、一つ一つをじっくり考えるようにします。そして、それらへのアクセスは暗号化されるようにします。構文がより洗練されたものになるために。これぞプロフェッショナリズム! ごめんね、ジョージ。もう十分だ。 10個のオーバーロードされた関数の結果を格納するグローバル配列と、それらの処理を行うパラメータなしの関数を1つだけ用意したZS。それよりもどう悪いのか？構文が10倍少ない。 Georgiy Merts 2019.08.30 16:20 #149 Реter Konow: 私は、なぜ関数がオーバーロードされる必要があるのか、全く理解できません。バカみたいでしょう？パラメータを持たない関数を作り、その中にオーバーロードされた関数の計算を全て書き、変数をグローバルにし、他の関数からの結果にアクセスできるようにします。まあ、いいんじゃないですか！？ でも、違うんです!すべての計算を、同じ名前で、異なるパラメータを持つ関数に分割することにします。そして、各関数の入力パラメータを山ほど作ることになる。いいえ、それだけでは不十分です。パラメータ名を読めないようにしよう。そして、それらに混じって渡される様々な配列を作ります。そして、そのような機能を何十個も作って、一つ一つをじっくり考えるようにします。そして、それらへのアクセスは暗号化されるようにします。構文がより洗練されたものになるために。これぞプロフェッショナリズム! ごめんね、ジョージ。ごめんね、ジョージ。 10個のオーバーロードされた関数の結果を格納するグローバル配列と、それらの処理を行うパラメータなしの関数を1つだけ用意したZS。 それよりもどう悪いのか？構文が10倍少ない。 そうだ、この機能について詳しく教えてくれ。十数種類の機能を選択するモンスターサイズのスイッチを搭載したものがありますね。このようなスイッチでは、そこにないブランチのどれかに属するコードを誤って書いてしまうというミスが起こりやすいのです。 オーバーロードでは、物事はもっとシンプルになります。10種類の子孫を持ち、常に1つのクラスを扱い、そのクラスには1つのオーバーロード可能な関数があります。そのために全く別のファイルを開かなければならないので、誤って別のクラスに書き込むことはできないのです。 さらに - この非常に巨大なスイッチにおけるパースそのものは、必要な1つのクラスを開いて、1つの関数だけをパースするよりも、ずっとストレスがかかると私は考えています。 実は、アセンブラコードでは、このスイッチの処理は、いずれにしてもこのポインタに依存して、同じスイッチになるのです。しかし、OOPの場合、これらはすべてプログラマーから隠されており、プログラマーの仕事を邪魔することはない。OOPがなければ-対処する必要があります。 大雑把に言うと、歩くと--結局、筋肉に一定の順序で信号を送って動かしているわけです。しかし、意識のレベルでは、どの動きをすればいいかを覚えているだけなのです。ここで、OOPとはまさにそのような「どのような動きをするかという記憶」のことです。 あなたは「筋肉がたくさんあって、そこに神経が配線されているのに、なぜ動きを記憶する必要があるのか理解できない」のですが、さて......。何度も言いますが、暗記力のある人は、どの筋肉をどの順番で緊張させればいいかを覚えていれば十分なんです。ムーブメントを全部覚えても意味がない。それほど記憶できない他の人にとっては、動作全体を記憶し、筋肉に何が起こっているのか、どの順番でどの程度緊張しているのか--それを頭から隠してしまう方がよほど合理的なのです。 削除済み 2019.08.30 16:28 #150 Реter Konow: 私は、なぜ関数がオーバーロードされる必要があるのか、全く理解できません。バカみたいでしょう？パラメータを持たない関数を作り、その中にオーバーロードされた関数の計算を全て書き、変数をグローバルにし、他の関数からの結果にアクセスできるようにします。まあ、いいんじゃないですか！？ とてつもなく、一般的なアプローチをきちんと勉強せずに、何かしらの自転車作りをやっているんですね。Peterさん、何か良い本を探してください。おそらくStroustrupさんでしょう、何かの本で彼はテキストエディタを書きました、実際の問題であなたは何かを学ぶでしょう、私は内容を覚えていませんが、それはあなたに悪いことを教えることはまずないでしょう。 1...8910111213141516171819202122...55 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
本気だ！
コンセプトの特許を取ろうと思っているところです。投資家がいる。だから、真剣なんです。
昨夜、夢遊病のスレッドを読みました...。なぜか、スターウォーズのクレジットのように、Windowsの開発者の長いリストを想像してしまいました。
そしてリストの最後には、大きな文字でReTeg Konow !
Peter Konow さん、こんな感じのテキストスプライトを作れませんか？）今やっているプロジェクトのすべてを記憶しているんですね。過去のコードはどうなっていますか？1年前に書いたことをそのまましっかり覚えていますか？今までのコードに手を加えたり、修正したりする作業です。
すべてはピーターの驚異的な記憶力に懸かっている。
また、プロジェクト 全体で使われるすべての変数を記憶し、いつ、どこで変更されたか、間違った変更の箇所を簡単に見つけることができれば、まさにOOPは無意味になりますね。 Peterは、実は「アセンブラレベル」で動いているのです。どんなOOPハックやデザインパターンを考え出したとしても、結局はどんなデータアクセスも普通のメモリアドレスであり、プロセスに割り当てられたアドレス空間内では、すべてのメモリアドレスに完全にアクセスできるのだ。プロセッサ自身はカプセル化について何も知らない。
そこへ、ピーターが操作するのです。 私自身もアセンブラにハマっていた時期がありました。
ただ、メモリ機能の面でどのようにプロセッサーに対抗していくのかが課題です。
すべてはピーターの驚異的な記憶力による。
...
問題は、メモリ容量でどうやってプロセッサーに対抗するかだ。
では、彼がずっと取り組んでいる同じプロジェクトについてなら、フェノムは何なのか。当然ながら、どんなプログラマーでも、常に頭の中にあるのはそればかりである。
それなら、私も只者ではありませんね。私も、ほとんど同じプロジェクトに携わって いますが、基本的な要点しか覚えていません。何を、どのような手順で修正するのか、といった詳細は、直接開発の瞬間にしかわからない。そして、この分野に戻ってくると--なぜそうで、そうでないのかを理解するために、多くの時間を費やすことになるのです。その結果、私はすべての権利を断ち切ることを支持します。理想的には、プログラムのどの場所でも、その場所でやるべきことだけにアクセスできるようにすることです。
今やっているプロジェクトのすべてを記憶しているんですね。過去のコードはどうなっていますか？1年前に書いたことをしっかり覚えていますか？今までのコードに手を加えたり、修正したりする作業です。
Alexey Navoykov:
...
いや、ここのカンフーはまさにOOPなんです。多くの技やテクニックがあり、その中でも戦いの中で10％は役に立つ。しかし、なんという美しいスタイルなのでしょう。そして、ドラゴン、サル、フラミンゴ、ヒキガエル...。具体的なサンボがあるんです。刻んで、結果を出す。
いや、ここでカンカンになっているのはOOPです。たくさんの技やトリックがありますが、そのうち10%は戦闘で役に立ちます。しかし、なんという美しいスタイルなのでしょう。ドラゴン、サル、フラミンゴ、ヒキガエル...。具体的なサンボがあるんです。刻んで、結果を出す。
そうではありません。
カプセル化や権利関係の制約の有用性については、これまで何度も言ってきたとおりです。
継承とポリモーフィズムの有用性は、共通の仮想インターフェースがありながら、実装が大きく異なる項目のリストを扱うときによくわかる。
今週、私が遭遇した最も単純な状況を紹介します。構造体のリストがあり、その中の1つのフィールドがダブルバリューです。そこで、この値をOOPで近似することを思いついた。
OOPがなければ、対応するSLAEを作成し、それを解決するプロシージャを完全に書かなければならない。あるいは、値の配列を扱うようなプログラムがすでにある場合、そのような配列を作成し、ライブラリ関数に渡すようなプロシージャを書きます。
OOPでは、CLSMCoreクラスを継承し、ポイント値を返す仮想関数を オーバーロードしています。すぐに近似多項式の係数を求めることができる。
つまり、同じ条件下（ライブラリ関数やクラスがある場合）であれば、余計な中間配列を導入することでOOPせずに損をしてしまうのです。もちろん、どのように充填するかを正確に把握する必要があるのは言うまでもありません。(値取得関数-OOPの有無にかかわらず-を記述する必要がある）。私が思うに、最大のメリットはサポートや改造が簡単なことです。OOPでは、理解することが少なくなります。また、当初はCLSMCoreクラスを書くのにOOPなしでライブラリ近似関数を書くのと全く同じ労力を使っていました。
そうではありません。
カプセル化や権利関係の制約の有用性については、これまで何度も言ってきたとおりです。
継承とポリモーフィズムの有用性は、共通の仮想インタフェースを持つアイテムのリストを扱うときにはっきりとわかりますが、その実装は大きく異なります。
今週、私が遭遇した最も単純な状況を紹介します。構造体のリストがあり、その中の1つのフィールドがダブルバリューです。そこで、この値をOOPで近似することを思いついた。
OOPがなければ、対応するSLAEを作成し、それを解決するための手続きを完全に書く必要があるのです。あるいは、値の配列を扱うようなプログラムがすでにある場合、そのような配列を作成し、ライブラリ関数に渡すようなプロシージャを書きます。
OOPでは、CLSMCoreクラスを継承し、ポイント値を返す仮想関数を オーバーロードしています。すぐに近似多項式の係数を求めることができる。
つまり、同じ条件下（ライブラリ関数やクラスがある場合）であれば、余計な中間配列を導入することでOOPせずに損をしてしまうのです。もちろん、どのようにポピュレーションするかを正確に把握する必要があるのは言うまでもありません。(値取得関数-OOPの有無にかかわらず-を記述する必要がある）。私が考える最大のメリットは、まさにサポートと改造の簡便さです。OOPでは、理解することが少なくなります。また、当初はCLSMCoreクラスを書くのにOOPなしでライブラリ近似関数にかけるのと同じくらいの労力をかけていました。
例えば、関数のオーバーロードが何のために必要なのか、私には理解できないのです。不条理な話ですよね。パラメータを持たない関数を作り、その中にオーバーロードされた関数のすべての計算を書き、変数をグローバルにし、他のどの関数からの結果にもアクセスできるようにするのです。まあ、いいんじゃないですか！？
でも、違うんです!すべての計算を、同じ名前で、異なるパラメータを持つ関数に分割することにします。そして、各関数の入力パラメータを山ほど作ることになる。いいえ、それだけでは不十分です。パラメータ名を読めないようにしよう。そして、それらに混じって渡される様々な配列を作ります。そして、そのような機能を何十個も作って、一つ一つをじっくり考えるようにします。そして、それらへのアクセスは暗号化されるようにします。構文がより洗練されたものになるために。これぞプロフェッショナリズム!
ごめんね、ジョージ。もう十分だ。
10個のオーバーロードされた関数の結果を格納するグローバル配列と、それらの処理を行うパラメータなしの関数を1つだけ用意したZS。それよりもどう悪いのか？構文が10倍少ない。
私は、なぜ関数がオーバーロードされる必要があるのか、全く理解できません。バカみたいでしょう？パラメータを持たない関数を作り、その中にオーバーロードされた関数の計算を全て書き、変数をグローバルにし、他の関数からの結果にアクセスできるようにします。まあ、いいんじゃないですか！？
でも、違うんです!すべての計算を、同じ名前で、異なるパラメータを持つ関数に分割することにします。そして、各関数の入力パラメータを山ほど作ることになる。いいえ、それだけでは不十分です。パラメータ名を読めないようにしよう。そして、それらに混じって渡される様々な配列を作ります。そして、そのような機能を何十個も作って、一つ一つをじっくり考えるようにします。そして、それらへのアクセスは暗号化されるようにします。構文がより洗練されたものになるために。これぞプロフェッショナリズム!
ごめんね、ジョージ。ごめんね、ジョージ。
10個のオーバーロードされた関数の結果を格納するグローバル配列と、それらの処理を行うパラメータなしの関数を1つだけ用意したZS。 それよりもどう悪いのか？構文が10倍少ない。
そうだ、この機能について詳しく教えてくれ。十数種類の機能を選択するモンスターサイズのスイッチを搭載したものがありますね。このようなスイッチでは、そこにないブランチのどれかに属するコードを誤って書いてしまうというミスが起こりやすいのです。
オーバーロードでは、物事はもっとシンプルになります。10種類の子孫を持ち、常に1つのクラスを扱い、そのクラスには1つのオーバーロード可能な関数があります。そのために全く別のファイルを開かなければならないので、誤って別のクラスに書き込むことはできないのです。
さらに - この非常に巨大なスイッチにおけるパースそのものは、必要な1つのクラスを開いて、1つの関数だけをパースするよりも、ずっとストレスがかかると私は考えています。
実は、アセンブラコードでは、このスイッチの処理は、いずれにしてもこのポインタに依存して、同じスイッチになるのです。しかし、OOPの場合、これらはすべてプログラマーから隠されており、プログラマーの仕事を邪魔することはない。OOPがなければ-対処する必要があります。
大雑把に言うと、歩くと--結局、筋肉に一定の順序で信号を送って動かしているわけです。しかし、意識のレベルでは、どの動きをすればいいかを覚えているだけなのです。ここで、OOPとはまさにそのような「どのような動きをするかという記憶」のことです。 あなたは「筋肉がたくさんあって、そこに神経が配線されているのに、なぜ動きを記憶する必要があるのか理解できない」のですが、さて......。何度も言いますが、暗記力のある人は、どの筋肉をどの順番で緊張させればいいかを覚えていれば十分なんです。ムーブメントを全部覚えても意味がない。それほど記憶できない他の人にとっては、動作全体を記憶し、筋肉に何が起こっているのか、どの順番でどの程度緊張しているのか--それを頭から隠してしまう方がよほど合理的なのです。
Реter Konow:
私は、なぜ関数がオーバーロードされる必要があるのか、全く理解できません。バカみたいでしょう？パラメータを持たない関数を作り、その中にオーバーロードされた関数の計算を全て書き、変数をグローバルにし、他の関数からの結果にアクセスできるようにします。まあ、いいんじゃないですか！？
とてつもなく、一般的なアプローチをきちんと勉強せずに、何かしらの自転車作りをやっているんですね。Peterさん、何か良い本を探してください。おそらくStroustrupさんでしょう、何かの本で彼はテキストエディタを書きました、実際の問題であなたは何かを学ぶでしょう、私は内容を覚えていませんが、それはあなたに悪いことを教えることはまずないでしょう。