OOPと手続き型プログラミングの比較 - ページ 22

新しいコメント
 
Nikolay Ivanov:

最近のシステムがすべてOOPを採用していることは、優位性の証明にはならないのでは？理解する準備ができていないだけで、簡単な質問をして複雑な答えを受け取れない...そして、答えがないと思っている...。それはおかしいな......。


考え方が変わる、そう、最初は「何のために？しかし、プロジェクトが何千行ものコードラインになると、その恩恵を受け始め))、なぜ、何のためだったのかを理解することができます。）


あるプロジェクトが保守や更新が困難で費用がかかり、拡張するにも費用がかかるのに、別のプロジェクトが手早く簡単にできるとしたら、最初のプロジェクトは死んでしまうでしょう - これは自然淘汰です。

私のプログラムも何千行ものコードがあります。不要な存在がないことが、私にとっての救いです。これ以外の開発方法はあり得ません。最も純粋な練習です。

でも、それはもういい。このスレッドから離脱します。

 
Nikolay Ivanov:

1.現代のすべてのシステムがOOPを採用していることは、優劣の証明にはならない？

2.理解する準備ができていないだけで、簡単な質問をして複雑な答えを把握できない...そして答えがないと思っている......。それはおかしい。


考え方が変わると、そうですね、最初は何のためにと思いますよね。しかし、プロジェクトが何千行ものコードラインになると、その恩恵を受け始め))、なぜ、何のためだったのかを理解することができます。）


あるプロジェクトが保守や更新が困難で費用がかかり、別のプロジェクトが迅速で簡単に拡張できる場合、最初のプロジェクトは死んでしまう。これが自然淘汰だ


1) ここにいるみんなはとてもクールで、それが彼らに証明されることはなく、逆に彼ら自身がとてもクールで、周りはみんな悲しいカモであること-彼らはOOPにひっかかったのです。

2.非常に逸話的であるが、気づいていない。

 
Alexey Volchanskiy:


このトピックと同様 ))昔、ポピュラー・メカニクス誌を購読していたら、ユーモアのあるページがあった。

レオはある日、戦意を喪失していた。だから、あからさまに歩いているんです。彼は一匹の狐に出会う。フォックス、早く、獣の王は誰だ？

- レバさん、もちろんです!

そして、「これでいいんだ」と納得した。

ウサギに会ったが、同じ結果だった。

そして象は熱くなり、ハエから幹を振って、ライオンは飛び去りました。

そして、藪の中に座っている去り行く象に何と言ったと思う？

- そして、答えが分からなくても怒らないでください（笑)。


ハリネズミについて。

"ハリネズミ "は空き地に立ち、上腕二頭筋を曲げながらポーズをとっています。- 私は強い、私は勇敢だ、私は機敏だ、私は強い、私は勇敢だ、私は機敏だ...。

熊が通りかかり、一蹴りすると、ハリネズミは木の陰に飛び、立ち上がって体を揺する。

- 私は強い、私は勇敢だ、私は機敏だ......。でも、私はやさしいから...。

 
Реter Konow:

でも、その話はもういい。このトピックを去ります。


他人を信用せず、自分で理解しようとすることは、良いことでさえある。他人は間違っているかもしれない、自分で理解する方が簡単なこともある


ドミトリー・フェドセーエフ

1.ここにいる誰もがとてもクールなので、彼らにとっては証明ではなく、むしろ自分たちがとてもクールであることを確認し、どのように知っていて、すべての周りの悲しいカモ - PLOにひっかかった。

2）非常に逸話的であるが、本人は気づいていない。


))) Anecdoticは、あまり理解していない人がMarket Expert Advisorを10Kドルで売ったり、2Kの加入者のシグナルを売って、本当に大きなお金を手にすることです))

 
Dmitry Fedoseev:

これは本論ではありません。

手続き型プログラミングにはポリモーフィズムの 類型はありません。

あなた自身が数ページ前に関数へのポインタに言及したのなら、どうしてそれがないのですか？これはまさにポリモーフィズムのアナログであり、動的に変更できるため、より広い可能性を持っています。

 

どうやらおしゃべりを見逃してしまったようですね :-) 司会者は炎上するような話題を取り締まっていますが・・・ここではOOP対OOPの話です。

ちなみに、@Peter Konowの 99%はOOPを使っていますが、本人は意識していません :-)。OOPは必ずしも "クラス＆テンプレート "ではない

その逆もまた然りで、プログラム中にオブジェクトやクラスがあるからといって、OOPであることを示すものではありません。

 
Alexey Navoykov:

数ページ前に、あなた自身が関数ポインタに言及しているのに、どうしてそうしないのですか？これはまさにポリモーフィズムのアナログであり、動的に変更できるため、より広い可能性を持っています。

それは昨日のことで、野党の方がいいという意見がある中で。最近、MQLの関数へのポインタが登場しましたが、今日、すべての論者にとって、それは全く存在しないことが判明しました。彼らは自分たちが何を主張しているのか、まったく分かっていないことが分かった。きっと、「ポリモーフィズム」や「ポインタ」という言葉を目や耳で聞き逃しただけなのだろう。彼らは、たとえここに1000の証拠を見ても、「あなたは何の証拠も挙げていない」という一点張りです。

クラスへのポインタも動的に変更できます。ただ、関数の方が簡単なのは、最初にクラスを作成する必要がないことです。

 
Реter Konow:

効果的な解決策とは、メカニズム（プログラムも間違いなくメカニズムである）が最も安定した形で機能するような解決策の質を意味する。その仕組みは、明確で一貫性があり、生産性の高いものでなければなりません。エンジンの機能は、割り当てられたすべてのタスクを実装する必要があります。この機構は余分なものを受け入れないので、この機構の開発においては、余分なものを切り捨てることが必要である。

あなたの場合だけ、この「不要なもの」が、型制御や、偶発的なプログラミングエラーからコードを守るための基本的なものなのです。そのため、コードが非常に信頼性の低いものになってしまうのです。安定性が全くない。今はデバッグしてきれいになっていても、しかし、さらに手を加えると、見つけにくいエラーが発生し、きれいにするのがとても難しくなります。

 

OOPには、開発者が使えるツールがたくさん追加されていることは間違いない。しかし、これらのツールを使用するためには、その代償を理解する必要があります。つまり、OOPパラダイムとそれに対応したコード 構造にどっぷり浸かることです。OOPツールキット全体を使用し、多くのオブジェクトを作成する。主な価格は、コードの急激な複雑化にあります。しかし、実際には、作成された機構の効率性の観点から、機構は単純であるべきで、機構にエンティティが存在することは、効率性の向上によって絶対的に証明されるべきであり、それ以上のものはないのです。

 
Alexey Navoykov:

ただ、あなたの場合、この「余分なもの」は、型制御や、偶発的なプログラミングエラーからコードを安全に保つために設計された他の基本的なものです。そのため、コードが非常に信頼性の低いものになってしまうのです。安定性が全くない。今はデバッグしてきれいになっていても、しかし、さらに手を加えると、見つけにくいエラーが発生し、きれいにするのが非常に難しくなります。

そうかもしれませんね。見てみよう。今のところ、そのような困難はありません。
1...151617181920212223242526272829...48
新しいコメント