ラウンジでPLOについて語る - ページ 19

新しいコメント
 

ボルチャンスキー、そして "Do you needgoto?" というコーラストピックを自分で書くこともできる。

 
Andrei:
ベリログ

まあ、握りつぶされたようなものですね（笑)電子回路を設計するためのものです。

 
o_o:

Volchansky、そして自分で別のhullabalooトピックを書く "あなたはgotoが 必要ですか？"


ネガティブな感情を抱いていると考えてよいのでしょうか？それはなぜでしょうか？

 
Комбинатор:

どんな違いがあるのでしょうか？

Googleで "OOP "と入力し、いくつかの否定的な性質を入力し、記事を取り、それを読まずに、フォーラムにそれを投げます。

本当か嘘か、それは関係ない。私がそうであるかどうかは関係ない。あなたのように、わざわざ読んで確認してくれる気配りのある人がいれば、同じように別の記事を投げることができます。

私はOOPの初心者なので、OOPの重大な欠点に気づいていない可能性が高いことは認めます。この記事をトップで取り上げたのは、本格的なプログラミングの資料のようだと思ったからです。そうではないのかもしれませんが、私もプログラマーではありません。

その結果、社会の一部（個人）が、なぜあるものに対して攻撃的ともいえる執拗な嫌悪感を抱くのか、社会学的（あるいは心理学的）な研究を行うべきかもしれませんね。
 
George Merts:

まあ、俺も女には嫌われてるけどな...。その他、多数...いつものことだが、アレクセイ、彼らは皆動物だ、誰もが訓練に成功するわけではない、だから妬む男がたくさんいるだろう。

でも、教えてほしいんです。あなたのコースはどこにあるんですか？私も見てみようかな...。


必要ないだろ、直に送ったんだから。

 
fxsaber:

OOPの重大な欠点は、複雑なものは設計が 難しい、つまり、うまく機能し、松葉杖なしで収まるアーキテクチャを作るのが非常に難しいので、リファクタリングが非常に頻繁に発生することです。デザインの経験が浅い人ほど、地獄を見ることになるのです。要は、OOPでは、普通に設計されたオブジェクトモデルの構造は、現実のオブジェクト（我々が想像するもの）とほとんど共通しないことが多いということです。

そして、ある言語があるパラダイムをサポートすることで、"良い/悪い"、"適用できる/できない "を語ることができるようになります。

例えば、上記のバナナを持ったゴリラはOOPの問題ではなく、依存関係を追跡せずにパッケージマネージャを無頓着に使っていることが問題なのです。特に最近のウェブでは

 
fxsaber:

記事の 内容は嘘！？

この文章を読んだとき、私はとても疑問に思った。すぐに転がして、頭の中がぐちゃぐちゃになっていないことを確認しました。

記事の著者が変更を提案している行を強調しました。交換しても結果は変わりません。続きは読んでません。もっとも、コメントで筆者のこの戯言に指摘があったのだろう。


記事に嘘はない。そこに仮想関数があるので、すべて著者の言うとおりに動くのです。

でも、OOPに対する真剣な反論と受け取らないでほしいですね。

ベースクラスの変更はいくらでも可能であり、それが派生クラスの作業に影響を与えないことを期待するのは愚かなことです。

 
Koldun Zloy:

記事に嘘はない。そこには仮想関数があり、すべてが作者の書いたとおりに動くのです。

しかし、これがOOPに対する真剣な反論だとは思わないでほしい。

ベースクラスへの変更はいくらでも可能であり、派生クラスの作業に影響を与えないことを期待するのは、まさに愚かなことです。

バーチャルなら意味があり、著者はバーチャル機能の 問題点や課題に無能なだけです。

さらに、独立する必要があったのなら、そうするべきだったのだ。

virtual void Array::addAll( const int &elements[] )
{
  for (int i = 0; i < ArraySize(elements); i++)
//      this.a.add(elements[i]);
    Array:: add(elements[i]);
}
しかし、この例は初心者には良い例だと思います。自分が何をしているのかを理解する必要があります。
 
Комбинатор:

OOPの重大な欠点は、複雑なものは設計が難しい、つまり、うまく機能し、松葉杖なしで収まるアーキテクチャを作るのが非常に難しいので、リファクタリングが非常に頻繁に発生することです。デザインの経験が浅い人ほど、地獄を見ることになるのです。要は、OOPでは、普通に設計されたオブジェクトモデルの構造は、現実のオブジェクト（我々が想像するもの）とほとんど共通点がないことが多いということです。

そして、ある言語があるパラダイムをサポートすることで、"良い/悪い"、"適用/不適用 "について話すことができるようになります。

例えば、上記のバナナを持ったゴリラはOOPの問題ではなく、依存関係を追跡せずにパッケージマネージャを無頓着に使っていることが問題なのです。特に最近のウェブでは。

そうですね、建築の選び方が悪いという場面に何度か遭遇しました。編集するよりも、一から書き直したほうが楽なこともありました。

手続き型コーディングでは、コードを書きながらプログラムのアーキテクチャを構成することがほとんどです。自由度や柔軟性は皆無だが、ガラクタが大きいからだ。

一方、OOPでは、最初の1行を書く前に、アーキテクチャ全体をボードに書き込むことが推奨される。準備が整ったら、コードを書くのはとても簡単です。そして、もしそのアーキテクチャが成功すれば（ここでは経験と個人のスキルのみが役立つ）、たとえそのプロジェクトの ことをすっかり忘れていたとしても、改良／拡張することは同じように簡単なことなのです。

 
Alexey Volchanskiy:

いやあ、なかなかの握力ですな（笑)電子回路を設計するためのものです。

それだけではありません。
1...121314151617181920212223
新しいコメント