PLOについての興味深い見解
これはOOPの問題ではなく、その応用、さらに言えば応用する側の問題です。彼らが感じるのは...
OOPの助けを借りて、信じられないような文章を書くことができることに熱狂し、恍惚としているのです。
信じられないほど複雑なコード（そして、その中で競争することさえも）。彼らは自分たちを特別なエリートだと感じている。
さらに、自分たちの「偉大な本」を発明し、それを読んでも読んでも
が、読めないのです。デザイン パターン」と呼ばれるもので、人間の言葉で言うと
は、「ファジーでマズくて混乱するコードを書く究極の技術」と訳されています。しかし、もし
とてもクールなものです。
は、生活を簡素化し、シンプルにします。
ほら、いつも疑われる)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23このような記事は、FPに不慣れな人が書いている可能性が高く、20個のタブがあるような分かりにくいフックになっている...と理解すべきです。
ハードFPは別格として、OOPの饒舌さ、便利さ、機能をあらかじめ宣言できることなど、いろいろなことを考えさせられますね......。要するに、一方と他方が似ていること。それはちょうどそのような記事は、多くの場合、手続き型コードのみを習得した人々によって書かれている - そしてこれはFPに近いものでもないので、あなたがフックとその鮮やかな使用を知らない場合は、FPは論外でありません
また、記事にある「死にゆく言語」の多くは、FPとOOPの全機能をサポートしています。 そして、そのうちのいくつかは、CISで 最も高い報酬を得ています。FPに「溺れる」なんてことは全く考えず、むしろOOPで「スパゲティ化」しているのです。私の考えでは、手続き的なパラダイムは、OOPよりも現実的で資源効率に優れていると思います。
ただ、OOPの方がコード自体が長いということですか？ まあ、そうですね、コンストラクタがあるので、場合によってはその方がコードが長くなるのが普通ですが......。技術的にはFP展開の方がマシンコード生成の効率は良いはずなのですが...。が、コードがシンプルにならないし、タイピングに関しても普通のラッパーを作るのは無理だし......。
最近は混在していることが多いので、互いに干渉しあうことはない。
ただ、OOPの方がコード自体が長いということですか？ まあ、そうですね、コンストラクタがあるので、場合によってはその方がコードが長くなるのが普通ですが......。技術的にはFP展開の方がマシンコード生成の効率は良いはずなのですが...。が、コードがシンプルにならないし、タイピングに関しても普通のラッパーを作るのは無理だし......。
現在では、どちらか一方ともう一方が混在していることもよくあります。
OOPとFPがなければ、すべてが簡単で速く動きますが（そう、「美点」やパネルなどがなければ）、自分のコードでさえ理解するのが難しいことがあります)。
OOPとFPがなければ、すべてが簡単かつ迅速に動作しますが（そう、「美点」やパネルなどがなければ）、自分のコードでさえ理解するのが難しいことがあります）。
まずはどちらか、あるいは両方をマスターして、どちらがいいかを判断してください。そして、今のようなやり方では、やがて自分の理解できないこと（つまりほとんどすべて）に賛成するフェドセーエフになってしまうでしょう。
なんという破壊的な話題への反応と破壊的な議論でしょうか。手続き型プログラミングの信奉者である私に、OOPにおける「スパゲティ化」を回避する方法、パース方法、他人の「スパゲティ」を使うことに意味があるかどうかを教えてください。
結局のところ、OOPは読みやすさとチームプログラミングのため、つまり大規模なプロジェクトのためにあることがほとんどなのです。アカウント内のバランス/資金の最大リスクの制御とそのチャートにシンボルを取引Expert Advisorは、よく、大きなプロジェクトを呼び出すことはできません - それはメモリ/速度で十分かつより収益性の高いです - 手続き上のプログラミングを。
質問です。
- 個人的な経験から見たOOP(命令形)の欠点/長所
- FPのデメリット/長所（宣言的なものとして）個人的な経験から。
また、展望についての意見は、特に並列コンピューティングの 方向で、もちろん興味深いものです。量子の話題に触れても意味がないと思うのですが。
手続き型プログラマとして、OOPにおける「スパゲッティ化」を回避する方法を教えてください。
決定論的な関数を書くように努力する、というのが引用した記事にあるレシピです。
分解方法と、他人の「スパゲッティ」を使うことに意味があるのか？
確かに良いコードですが、スパゲッティではありません。
結局のところ、何が得られるかというと、OOPは主に可読性とチームプログラミングのため、つまり大きなプロジェクトのためのものなのです。
そうですね。
残高や口座資金を最大限にリスクコントロールしながら、シンボルをチャートに貼り付けて取引するEAは、まあ大きなプロジェクトとは言えませんので、手続き型プログラミングで十分ですし、メモリやスピードの面でもより収益性が高いです。
オーストラリアに行くには飛行機を使った方が便利（OOP）、近隣の都市に行くには車や自転車でも十分（PP）です。目的を達成するために、より便利な手段を選べばいいのです。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
ほら、いつも疑われる)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23