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

新しいコメント
 

クラスも入らないのに、どうやってOOPを使う んだ？単純にいらないんです。構造物は必要ない。それは人為的な区分であり、私のプログラムの自己開発によって正当化されるものではない。その通り、自己啓発です。それ以外の名称はありません。

そこで、このプロセスでは、コードブロックそのものを改良したり、新しい機能を追加したりする過程で生まれる必然性によって分割しているのです。まず機能を作り、それを徐々に大きなブロックにまとめ、磨きをかけ、新しい機能を追加していく。時間が経つと、これらのブロックは崩壊し、新たなブロックが出現します。すべては自然に起こること。新機能を獲得するために「回す」だけ回して、品質の良い状態まですり減らすのです。同時に、コード構造も常に変化し、変容している。明確なスキームを持たず、すべてが予測不可能な方向に展開していくのです。その中で突然、質的な飛躍の機会を見出すことができるのです。そして、私はこのように飛躍するのです。

そうやって、私のプログラムは進化していくのです。膨張し、収縮し、崩れ、そして変身して現れる。世界的な変化、質的飛躍がある一方で、長期的に安定した状態もあります。

その際、不要なルールや異言語のシンタックスは、物事を遅らせるだけです。

 
Реter Konow:

クラスも入らないのに、どうやってOOPを使う んだ？単純にいらないんです。構造物は必要ない。それは人為的な区分であり、私のプログラムの自己開発によって正当化されるものではない。その通り、自己啓発です。それ以外の言葉はない。

そこで、このプロセスでは、コードブロックそのものを改良したり、新しい機能を追加したりする過程で生まれる必然性によって分割しているのです。まず機能を作り、それを徐々に大きなブロックにまとめ、磨きをかけ、新しい機能を追加していく。時間が経つと、これらのブロックは崩壊し、新たなブロックが出現します。すべては自然に起こること。新機能を獲得するために「回す」だけ回して、品質の良い状態まですり減らすのです。同時に、コード構造も常に変化し、変容している。明確なスキームを持たず、すべてが予測不可能な方向に展開していくのです。その中で突然、質的な飛躍の機会を見出すことができるのです。そして、私はこのように飛躍するのです。

そうやって、私のプログラムは進化していくのです。膨張し、収縮し、崩れ、そして変身して現れる。世界的な変化、質的飛躍がある一方で、長期的に安定した状態もあります。

その際、外国語で無駄なルールや構文があると、かえってスピードが落ちてしまいます。


しかし、1週間かけて構造を整理する価値はあるかもしれませんね。構造物なんていらない」という発言は、本当に馬鹿にされているように見えます。結論は、「まったくわからない」ということだけです。

 
Dmitry Fedoseev:

手続き的に最適な方法で解決できないタスクがあります。

最適とはどういう意味かにもよりますが )

私が考えるに、OOPは便利なラッパーに過ぎず、問題を解決するものではありません。だから、ここで議論が止まっているのです。

全体として、どんな仕事でも構造化プロシージャのアプローチを使えば、より速く、よりコンパクトに解決できることは誰もが認めているようです。そして、コーディングそのものよりも、クラスへのラッピングに多くの時間が費やされています。調子に乗って、授業をめちゃくちゃにして、「なんでこんなことまで...」と思うこともあります。

もう一つ、「関数ポインタを使った手続き型プログラミング」についてですが、なぜ別カテゴリーにする必要があるのでしょうか？関数ポインタはあくまで構造的手続き的なスタイルだと思うんです。

 
Alexey Navoykov:

最適な方法」というのが何を意味するかによりますが )

私が考えるに、OOPは便利なラッパーに過ぎず、問題の解決策にはなりません。だから、ここで議論が止まっているのです。

全体として、どんな仕事でも構造化プロシージャのアプローチを使えば、より速く、よりコンパクトに解決できることは誰もが認めているようです。そして、コーディングそのものよりも、クラスへのラッピングに多くの時間が費やされています。調子に乗って、授業をめちゃくちゃにして、「なんでこんなことまで...」と思うこともあります。

もう一つ、「関数ポインタを使った手続き型プログラミング」についてですが、なぜ別カテゴリーにする必要があるのでしょうか？関数ポインタはあくまで構造的手続き的なスタイルだと思います。


ポリモーフィズムは、関数ポインタを除けば、手続き的な手段ではどうにも実現不可能です。OOPは決定的にポリモーフィズムですが、手続き型プログラミングでは、必ずしも関数へのポインタがあるわけではありません。

何でもかんでもクラスでくくるのはよくない。

 
Dmitry Fedoseev:

少なくとも1週間は構造物の処理に時間をかけるべきじゃないのか？構造物なんていらない」という発言は、本当に馬鹿にされているように見えます。結論は、「まったくわからない」ということだけです。

構造は自明なことです。異なるタイプの名前付き変数のセットを結合します。私のプログラムでは、主にint型を使用しています。ダブルを使うのは一部の場所だけです。の文字列は、特定の1ブロックにのみ含まれます。

OOPの文脈でなぜ構造体が必要なのか？

カーネルに属する構造体を1つ持っています。つまり、その中にあるカーネルそのものの構造です。それだけでいいんです。

 
Реter Konow:

構成は自明である。異なるタイプの名前付き変数のセットを結合します。私のプログラムでは、主にint型を使用しています。ダブルは数カ所でしか使いません。の文字列は、特定の1ブロックにのみ含まれます。

OOPの文脈でなぜ構造体が必要なのか？

カーネルに属する構造体を1つ持っています。つまり、その中にあるカーネルそのものの構造です。それだけでいいんです。


3年間、自分のために1つのプログラムを書き続けていること。

 
Dmitry Fedoseev:

できますが、操作の効率は異なります。ここではサポートは問題ではなく、あまりにも相対的なものです。

手続き上、最適な方法で解決できないタスクがあるのです。


私はOOPの支持者ですが、実はプロセッサはOOPの存在など何も知らず、マシン・コードを実行できる、ただそれだけなのです。コンピュータの初期には、このように直接機械語コードでプログラムを書いていた。

だから、女性プログラマーが多かったんですね。この仕事のために、男たちは酔っ払っておかしくなってしまうからだ）。

 
Реter Konow:

結局のところ、同意する - 重要なのは、ソリューションの効率性である。

構文の過負荷やルールの複雑さは、ソリューションの効率性を維持するのに貢献したことはありません。コードブロックの簡潔さ、普遍性、読みやすさで表現されたシンプルさ、簡潔さが役に立ったのです。

また、効率的なソリューションとは何を指すのでしょうか。

私のプログラミングのルールは、「コードを少なく、規則を少なく、構文を少なく」...です。

"私のルール：ルールなし")))
 

私はOOPが好きではありません。

しかし、保守性、拡張性、サードパーティーの使い勝手という点では、TC（カルプトフではなくピーター）が推すものは石器時代としか言いようがないのです。

私は、プログラマーは 4人以上のチームで仕事をするのが理想だと考えています。

 
Alexey Volchanskiy:

私はOOPの支持者ですが、実はプロセッサはOOPの存在など何も知らず、マシン・コードを実行できる、ただそれだけなのです。コンピュータの初期には、そうやって機械語コードで直接プログラムを書いていたのです。

だから、女性プログラマーが多かったんですね。男はこの仕事のために、たくさん飲んでおかしくなったからだ)。


それがどうした？これまでのところ、ひとつの結論として、最初のうちは機械語コードでプログラムをたくさん書かなければならなかったということです))

1...5678910111213141516171819...48
新しいコメント