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

新しいコメント
 
Andrei:

その通り、特定の人物から。統合失調症でないプログラマーが、デバッグしている自分自身のコードの一部にアクセスすることを、なぜ必死で隠そうとするのだろうか。自分の手を縛る方がいいのでは？:)

さて、先ほども言ったように、Peterが上であげた構造ファイルを使って作業してみてください。そこから必要なデータを "フェッチ "し、正しい場所に戻す。

そして、同じ構造をほんの少し与えてくれる「トリミング」されたインターフェースから必要なデータを得ることと比較してみてください。インターフェイスがあれば、他のものを手に入れたり、「間違った」ものを書いたりすることはできないのです。

いや、もしあなたが記憶力の巨人で、忘却能力が萎縮しているのなら、幸運なことに、OOPは必要ないのだと理解できます。しかし、誰もがそんなに幸運なわけではありません。

そこでSanSanychは、OOPをドキュメントに置き換えることを提案します。原理的にはそれも選択肢の一つで、実際、Peterが提案した構造にかなり近いと思います。しかし、Peterの場合、すべてのドキュメントは「心の中」にあり、SanSanychの場合、紙（または電子メディア）にある。

 
Andrei:

この「おそろしさ」は何なのだろう。

ところで、Renat Fatkhullin さん、確かに例を見てみると面白いかも...。

 
George Merts:

いや、忘却能力が萎縮している暗記の巨人なら、ラッキーなことにOOPは必要ないというのは理解できる。しかし、誰もがそんなに幸運なわけではありません。

そこで、SanSanychは、OOPをドキュメントに置き換えることを提案しているが、これも原理的には、Peterが提案した構造にずっと近いオプションである。しかし、ピーターのドキュメントはすべて「頭の中」であるのに対し、サンサニッチのドキュメントは紙（あるいは電子媒体）である。

変数の意味はどんな場合でも知っていなければならないが、覚えておく必要はない。文脈から明らかでない場合は、コメントを書いてもよい。当たり前のようですが。

つまり、いつ、どのタイミングで、何が作成され、破棄され、どのインターフェイスを経由して、どのタイミングで、その他最終結果には全く役に立たないマウスフューズを記憶し、文書化しなければならないのです。

 

ところで、OOPに反対する人たちは、プログラムがアセンブリ言語で書かれていた時代を思い出すといいでしょう。

そして特に-BIOSとDOSを使ったファイル操作。

私の考えでは、手続き的アプローチとOOPアプローチの違いは、ちょうどBIOSとDOSツールによるディスクハンドリングの違いと同じだと思います。

BIOSもDOSも、ディスクを扱うために必要な機能はすべて備えている。

しかし、BIOSの機能を使ってファイルを作成し、そこに「Hello, world !」と書き込むことは、FATドライブであってもかなり大きな問題である。昔はあえてやっていたのですが、なかなかうまくいかなかったんです。DOSでは1つの関数で簡単にできます。

NTFSシステムでこのようなファイルをBIOSで作成するのは難しいことは想像がつきますが...。

 
Andrei:

よく読むと、クラスのことであって、クラスのコンストラクタのことではありません。

さらに、あなたは再び猿の仕事 - プロットにフィールドを植えるために、我々は外部変数の場合にANYTHINGまたは直接渡すことなくパラメータにアクセスすることができれば、コンストラクタ-デストラクタとすべての付随するメモリリークで不要な頭痛をせずに、作ることをお勧めします。


ああ、乗りたいんだけど、ここでドアに案内してくれるんだね。クラスのコンストラクタが 何であるかは、おそらくご存じないでしょう。

ただ、一般的なパラメータは、すでにクラス内部で見えているのですが、それを使うのはよくない、共通空間から脱出できるのがOOPのいいところです。

そして、直接的にどのように？ドアでなければ、壁？コンストラクタを通すと、直接渡すのと同じです。オブジェクトの作成時に、newなしでもすぐにパラメータを渡すことができます。では、クラスが受けなければならないパラメータを記述するのが面倒なのでしょうか？関数を書いたり、変数を宣言したりするのが面倒なのでは？

明らかに私が書いたものを理解していませんね))。

 

Dmitry Fedoseev:

関数を書いたり、変数を宣言したりするのが面倒なのでは？

どこでも、そしてOOPでも関数を書き、変数を宣言する必要があるのです。OOPの場合だけ、もっと大騒ぎになります。それは、プロジェクトの最後にどのようなデータ構造に なるのか、予言的にすべてを事前に予見していれば、100回も書き直す必要はありません。当たり前のようですが。

 
Andrei:

どこでも、そしてOOPでも関数を書き、変数を宣言する必要があるのです。OOPの場合だけ、もっと気難しくなります。それは、プロジェクトの最後にどんなデータ構造が あるのか、予言的にすべてを事前に予見していれば、100回も書き直す必要はありません。当たり前のようですが。


手間はかかるが、それに見合うだけの価値があるケースはいくらでもある。一般的には、致命的なものではありません。

 
Dmitry Fedoseev:

手間はかかるが、それに見合うだけの価値があるケースはいくらでもある。一概に致命的とは言えません。

手間をかける価値があるのは、時間単位で支払うときです。そうすれば、大騒ぎすればするほど、利益が上がるからです。:)
 
Dmitry Fedoseev:

このライブラリーはいつから制作しているのですか？

2年間、途切れることなく働き続けた。

GUIカーネル（ちなみに、プロトタイプの要素を含むプロトカーネルも存在する。2メガバイトを占有しています。引用したような表で構成され）、数千の変数が含まれている。カーネルを中心に、クラスや構造体に変数を分散させ、様々なアクセス制限で相互の通信を設定しなければ、私の課題に対処できたと思いますか？- 決して 自分一人の力ではありません。私のプログラムでは、エンティティの数を掛けたはずです。関数やクラスなどのコードのつながりが複雑になり、自分一人では作業が続けられなくなるのです。そうなると機構全体の効率は一気に落ちてしまいます。

私ならもっと早く限界に達してやめていたでしょう。

何度も「もしOOPを使って いたらどうなっていたか」と自問し、そのたびに日々の実践を踏まえて「自分一人ではそこまでできなかっただろう」と実感しました。

また、私の思考はすでに構造化されているので、この点ではOOPは必要ありません。

 
Renat Fatkhullin:

嬉しさのあまり、Rは「アクセスの区別がないオールインワンのゴミ箱」モードで書かれているのが、なんとも嫌らしい。20年前の古い手法で、可視化、保護、マルチセッションの領域がない。まるで自分だけがそうであるかのように書いています。そう、このプロジェクトは、プロではない開発者が一人の下で誕生させたものなのです。一から書き直さなければならない。少なくとも一度は。

MQL5からRで普通のインターフェースを作るというアイデアもあったのですが、深く掘り下げると、統合しないことを即決しました。データやセッションを保護することは、断固としてできない。

プログラマーは、要求の厳しい普通の開発チームで働くまで（少なくとも2、3年は手を叩いて）、普通の意味でのデベロッパーにはなれません。候補者を検討する際にテストジョブを見るとき、私たちは90％の確率で頭をつかいます。開発業界全体のトータルホラー

だから、またしても、OOP反対派は、ある種のバカ騒ぎをしているのです。

またまたすみません。


レナトさん、緊張しないでください。私自身はRの支持者ではありません。あなたは優秀な経営者でありプログラマーです、掲示板の声を真に受けてはいけません。

ラシードさんやチームの皆さんの健康とクリエイティブな成功を祈っています

1...33343536373839404142434445464748
新しいコメント