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

新しいコメント
 
Andrei:

押し付ける必要はないが、手続き型では余計なジェスチャーをしなくてもコードのロジックがすでに見えており、雇われプログラマーのジェスチャー一つ一つに雇用主への手数料がかかることは明らかである。したがって、雇用主が賢ければ、OOPに騙されることはありませんが、賢いプログラマーは、雇用主のリテラシーの低さを利用して、より多くのお金を得るために進歩的なOOPについての物語をねじ曲げることができます。:)

ハッ!

歩いて移動するのは「余計な手間がかからない」という理屈があるのですが、なぜかみんな交通機関を使いたがるんですよね。車に乗ってフィットネスセンターまで2キロ、トレッドミルで5キロの距離を「巻く」なんて、バカバカしいにもほどがある。

プログラミングといえば、DOSではビデオバッファに書き込むだけでウィンドウが作成される。しかし、Windowsで簡単なウィンドウを作るには - ウィンドウクラスを登録し、それを作成し、メッセージ処理のループを実行する必要があります - しかし、なぜか誰もがこれらの非常に「余分な手順」を作っています。

OOPは「進歩性」のためではなく、この方法論がもたらす利点のため、そして雇用主にとって最終的に安価であるため、選ばれているのです。なぜなら、手続き型で書いたものは、OOP型で書いたものと同じ効率でメンテナンスすることはできないからです。

Peter Konovのコードを例にとると、一方ではごく普通のプロシージャ指向のコードですが、他方では、このコードで作業するには、常にシステム構造に関する多くの情報を心に留めておく必要があり、個人的には、たとえ大金であってもこのような作業は引き受けないことにしています。同時に、OOPスタイルで書かれたSBは、保守や変更が非常に容易です。標準ライブラリの TCパターンにおけるオブジェクトのアーキテクチャは、Peterのコードよりもはるかに複雑ですが、理解するのも修正するのもずっと簡単です。

余計な手間のかからない手続き型スタイル」というのは、本当に複雑な構造を書く必要があるとき、特に修正を加える必要があるときまでの話なんです。このように、プログラマーにとって使いやすく、顧客にとっても安価であることが、OOPが広く使われている理由です。しかし、その中でごく簡単なことを行うには、「無駄な身振り」が必要なのです。単純に、誰もこの「シンプル」を必要としておらず、すべての人が「複雑」を必要としており、それはOOPを使用して行うのが良い。

P.S. そして、私はまだ理解していないのですが、あなた（「あなた」としましょう）は、OOPアクセス修飾子なしではどこにも使われるべきでない関数へのアクセスをどのように制限しようとしているのでしょうか？

 

George Merts:

なぜなら、手続き型で書いたものは、OOP型で書いたものと同じ効率でメンテナンスすることができないからです。

P.S. そして、私はまだ理解していないのですが、あなた（「あなた」と言わせてください）は、OOPアクセス修飾子なしではどこにも使われるべきでない関数へのアクセスをどのように制限することを提案しているのでしょうか？

いいえ、違います。ちょうどその逆です。

ただ、OOPesheのコードは、いろいろな紆余曲折があるため、メンテナンスや修正が難しく、後でもう一度コードを書くのが簡単なのです。実際、OOPの目的はロジックを隠すことだと言われているので、隠しておいて、急に開ける必要が出てきたら、追加料金を払ってサービスしているのです。

関数ラッパーは内部関数を隠すことができますが、突然この内部関数を好きなように追加したくなったら、DLLに隠したり、ソースコードを別ファイルにしたり、そのファイルを一番遠いディレクトリに隠したりすれば、探しても見つからないので、特に怒れるプログラマにはもっと選択肢があるかもしれませんね。:)

 
Andrei:

いいえ、そんなことはありません。ちょうどその逆です。

OOPのコードは、ロジックがいろいろなトリックで隠されているので、コードを書き換えるのが簡単なのですが、保守や修正が難しいのは同じです。実際、OOPの目的はロジックを隠すことだと言われているので、ロジックを隠しておき、突然それを暴く必要が出てきたら、追加料金を払ってサービスしているのです。

Wrapper機能で内部関数を隠すことができますが、突然何かの拍子にこの内部関数を追加したくなった場合、DLLの中に隠したり、ソースコードを別ファイルにしたり、そのファイルを一番遠いディレクトリに置いたりして、せいぜい見つからないようにしたいという、特に怒れるプログラマ向けのオプションがあるのかもしれませんね。:)

ロジックが隠されていると、なぜ「修正が難しい」のでしょうか？ ロジックが隠されているのは、修正できないところは修正できないようにするためなのです。

ただ、手続き的なアプローチでは、何かを変えたい、変えたのに、なぜ動かないのかがわからない（もっと悪いことに、理解不能なエラーが出ることもある）のです。そして、OOPアプローチでは、それを変更したいのですが、クラスの内部には一切アクセスできません。また、アクセスがないということは、何か理由があってのことで、そこには何かトリッキーな、暗黙の使用条件があるのでしょう。もし、何かを変更したいのであれば、そのクラスを継承して、必要な部分を変更すればよいのです。

また、継承しても、子孫でも利用できないプライベートメソッドやフィールドにつまずくことがありますが、これもまた理由があり、このフィールドは子孫でも変更されないように意図されているということです。

DLLで隠す "という話ですが、問題はDLLではALLしか隠せないということです。オブジェクトの一部ではありません。そして、そのためにアクセス修飾 子があり、オブジェクトの一部分だけを隠すことができるのです。そのため、プログラマーが必要なものだけにアクセスでき、「上からの」アクセスはできないように、すべてが考えられているのです。では、DLLは何のためにあるのでしょうか？DLLコードを開く - すると、部分的ではなく、コード全体が開かれます。閉じる - 再び、すべてのアクセスを閉じます。

private-protected-publicセクションを使わずに手続き型でアクセス制限をする方法がわからない。そして、この制約が私を大いに助けてくれています。

 
George Merts:

ロジックが隠されているのに、なぜ「修正しにくい」のか？ ロジックが隠されているから、修正できないところは修正できないのでは？

ただ、手続き的なアプローチでは、何かを変えたい、変えたのに、なぜ動かないのかがわからない（もっと悪いことに、理解不能なエラーが出ることもある）のです。そして、OOPアプローチでは、それを変更したいのですが、クラスの内部には一切アクセスできません。また、アクセスがないということは、何か理由があってのことで、そこには何かトリッキーな、暗黙の使用条件があるのでしょう。もし、何かを変更したいのであれば、そのクラスを継承して、必要な部分を変更すればよいのです。

また、継承しても、子孫でも利用できないプライベートメソッドやフィールドにつまずくことがありますが、これもまた理由があり、このフィールドは子孫でも変更されないように意図されているということです。

DLLで隠す "という話ですが、問題はDLLではALLしか隠せないということです。オブジェクトの一部ではありません。そして、そのためにアクセス修飾 子があり、オブジェクトの一部分だけを隠すことができるのです。そのため、プログラマーが必要なものだけにアクセスでき、「上からの」アクセスはできないように、すべてが考えられているのです。では、DLLは何のためにあるのでしょうか？DLLコードを開く - すると、部分的ではなく、コード全体が開かれます。閉じる - 再び、すべてのアクセスが閉じられます。

private-protected-publicセクションを使わずに、手続き型でアクセス制限をする方法がわからない。そして、この制約が私を大いに助けてくれています。


ジョージ、また太鼓を叩いているのか ))))これでは意味がない。

 
Alexey Volchanskiy:

ジョルジュ、また叩いてるのか ))))意味がないんです。

たぶん、たぶん。

でも、あなたはパートタイムのカサノバだから...。そして、私は家庭教師のアルバイトをしています。なるほど、"クライアントは迷っていない "ということですね。だから、私は説明を続けています。プロの奇形」みたいな。

 
George Merts:

たぶん、たぶん。

でも、バイトのカサノバは...。そして、私は家庭教師のアルバイトをしています。なるほど、「クライアントは迷っていない」のですね。だから、私は何度も説明する。プロの奇形」みたいな。


カサノバはもういいや。子供がファーザー・クリスマスを信じるように、自分でおとぎ話を作り上げて、それを信じているんだ、頼むよ)

 
Andrei:

それを押し付ける必要はないが、手続き型では余計なジェスチャーをしなくても コードの論理がすでに見えていることは明らかであり、雇われプログラマーのジェスチャー一つ一つが雇用主のコストになるのである。

上記のプロシージャーコードのジェスチャー数は、変更が必要な場合はさらに必要になります。

関数（プロシージャ）を持たないコードを書くことも可能です。しかし、コーディングはやがて「コンクリートを流し込む」ことによって書かれることをやめ、「レンガ」から作り始めるようになりました。そこで、手続き型プログラミングが登場した。

OOPは、全体の作業をよりシンプルな構成要素に分解するためのもう一つのステップです。

分業化、その結果、あらゆるものの生産がコンベア化され、産業革命を起こし、人類の工業化が進んだのである。


ハンドメイドとは、「手順を踏まずにコードを書くこと」です。

コンベアは「手続き的なコード書き」であり、コンベアの多くの要素は他の要素に依存している。つまり、ある要素を変更すると、別の要素も変更しなければならない場合があるのです。

"OOPプログラミング "とは、要素間の依存関係を低減したパイプラインのことです。つまり、ある要素を別の要素に置き換えることで、パイプラインが機能しなくなる可能性が低くなるのです。あらゆる生産を独立したパーツに分解し、規格を入力できること、など。- は、オブジェクト指向のものづくり（プログラミングではない）です。


プログラミングそのものは、プロダクションの特殊なケースである。OOPの考え方は、どんなものでも原則的に制作するものです。ですから、プログラミングの話をするのは非常に狭量です。OOPは、プログラミングに登場する以前から応用に成功していたのです。

 
Alexey Volchanskiy:

カサノバはもういいや。あなたは自分でおとぎ話を作り上げ、それを信じていたのです。）

レッチー、うらやましいです。

かなり本気で。まあ、ちょっと芸術的に誇張する権利は残しておいてください......。

 
fxsaber:

上記の手続き上の体動の数...

О !よくぞ言ってくれました。

完全対応。

 
fxsaber:

変更が必要な場合は、上記の手順コードの体積を大きくする必要があります。

原則的に、OOPにおける身体的労力は少なくすることはできません。なぜなら、これらのインターフェースはすべて追加のオーバーヘッドであり、しばしばロジックそのものを書くコストを上回ってしまうからです。そして、どんな関数もすでにインターフェースを持っているにもかかわらず、つまり、本質的に意味のない別の生け垣を作ることが提案されているのです。

同時に、インターフェースと機能の両方で、コードを変更すると、一方が他方にフックされるため、非常に複雑になり、少なくとも2次関数的にバグの可能性が増え、労働集約的になる...ということです。当たり前といえば当たり前なんですけどね。

1...34567891011121314151617...23
新しいコメント