私は、オブジェクトがコードの再利用に関して配信されていないと言ったことをよく耳にします。同意しますか？あなたは彼らがそうではないと信じているなら、なぜですか？

いいえ、必ずしもそうではありません。

オブジェクトは、より優れたセマンティクス、コード/機能の編成、そしておそらく使いやすさを実現します。

適切に設計されたライブラリは、オブジェクト自体ではなく、コードの再利用を約束します。

正直なところ、「コードの再利用」が本当に後を追うものであるかどうかはわかりません（少なくとも後でなければなりません）。私の哲学は「ソフトウェアコンポーネント」です。これは、優れたインターフェイスを介した保守性の向上と、不要な結合の回避を意味します。「コードの再利用」は、時にはそれから外れることの1つです。不必要に重複したコードは、物事を間違った方法で整理したことを示し、もちろん維持するのが苦痛です。

質問にもう少し直接答えるために、自分自身の繰り返しを避けるための非常に良いツールのコレクションがあります：継承、特性、委任、高階関数など。あなたが私に尋ねると、彼らはそれを少し使いすぎる傾向があります。たぶん、そこから「OO sucks」バイブの一部が生まれます：継承が自然な権利を持たない場所でスタックしていることを見つける:)

いいえ、「オブジェクト」はコードの再利用を簡単または一般的にしていません。モジュラープログラムでコードの再利用を妨げる同じ懸念事項（汎用APIの設計、テスト、文書化には、1回限りのルーチンを書くよりもかなり多くの先行作業が必要です。なしのマスター-再利用することを意図したロジックは、実際に使用される用途に最適化されていない可能性があります）OOプログラムに適用します。不適切に設計されたオブジェクトモデルは、再利用可能な再利用を妨げる可能性がありますコード。

OOは、多くの問題に対する便利な抽象概念ですが、80年代から90年代の誇大宣伝には注意してください。寝ている間にワッフルを作る以上に、私たちの貿易の根本的な問題を魔法のように解決することはありません。

すべてのオブジェクトが再利用されることを期待していませんが、多くの異なるプロジェクトで再利用するオブジェクトがたくさんあります。また、1つのプロジェクトで再利用されるオブジェクトもあります。多くの場合、同じビジネスオブジェクト（またはデータ転送オブジェクト）およびClick-Onceデスクトップアプリ、Webアプリ、電話アプリからのビジネスロジックオブジェクトをすべて同じプロジェクトで使用します。

OOが再利用で配信しないと聞いたことはありますか？そして、理由は何でしたか？おそらく彼らのオブジェクトの設計は、彼らをそのような状況に追いやったのでしょう...

一部のプログラマは、任意の言語とスタイルでコピーして貼り付けます。

本当に優れたプログラマーは、ほぼすべての言語でほとんどのコピーアンドペーストを回避できます。

オブジェクト指向のパターンは再利用を促進する傾向があると思います。私は、非OOスタイル（データが安っぽいORMのためにコードから分離されていた）で書かれたJavaコードを見てきましたが、再利用は本当に悲惨でしたが、OOでは同じプログラマーが設計でより良い仕事をしました（および再利用）。

また、セッター/ゲッター、switchステートメント、匿名の内部クラス、巨大な関数など、非ooパターンまたはooアンチパターンを使用する場合、コードの再利用が低下し、ボイラープレートが上昇することを確認しました...

追伸 前の段落で問題が発生することはわかっているので、少し説明します。

セッターとゲッターはオブジェクトのメンバーを操作できるためオブジェクト指向の問題を引き起こします（オブジェクトはそのOWNメンバーを操作する必要があります）これにより、セッター/ゲッターの周りの機能をコピーする必要がある他のクラスにクラスで動作するコードが配布されます。これはプロパティにも当てはまります。プロパティが簡単だからといって、すべての状況で「良い」とは限りません。

匿名内部クラスのコードはまったく再利用できず、人々は多くのこと（リスナーなど）が本格的なクラスであり、そうあるべきであることを忘れています。これはクロージャーにも当てはまります。リスナーのようなものを実装するために匿名内部クラスを使用した場合、メソッドまたは独自のクラスにコードを抽出して代わりに呼び出すよりも、実装をコピーして貼り付けるだけの可能性が高くなります。クロージャーは、再利用性を向上させることもできます。クロージャーの使用方法によって異なります。

多くの場合、利用可能な機能により、コードの構造が決まります。オブジェクト指向は、すべてのコードとそれがどのように相互作用するかを視覚化することに関してはさらに強力ですが、それは別の質問です。

オブジェクトには、階段を登る人や他のフィットネス機器が減量できるよりも、コードを再利用する能力がありません。開発者はツールを適切に使用するように動機付けられなければなりません。

ソフトウェアチームがテスト済みコードの再利用に、すべての詳細を頭に入れておくよりも高い価値を置くと、はるかにきめの細かいオブジェクトとメソッドが見られるため、コードの再利用が増えます。

はい

OOPは、コードを再利用するためのより多くの方法を提供します

番号

特効薬はありません

場合によります

あなたがそれに入れたもの、そして見返りにあなたが期待したものに！

はい。優れたオブジェクト指向プログラミングは、懸念の分離、低い結合、高い凝集性、および情報の隠蔽を促進します。これらはすべて、再利用可能なコードにとって重要です。

OOPの主な利点は、再利用ではなくモジュール性と変更可能性であると主張しますが、それは別の質問です。

オブジェクトを使用するとコードの再送信が可能になりますが、そのための手法はほとんどありません。コードの再利用は、継承、ポリモーフィズム、オーバーロード、テンプレートなどのオブジェクト関連の技術を通じて促進されると思います。

はい、彼らはそうです、スーパークラスのクリアから拡張する（継承する）能力はコードの再利用に貢献します、私は誰かがそうでなければ議論する方法がわかりません。あなたは単にクラスを拡張し、スーパークラスの残りを使用しながら1つのメソッドをオーバーライドできますが、これがコードの再利用を支援していない場合、私は何がわからない

これまでのところ、彼らはコードの再利用の約束を果たしましたか？はい、OOPを念頭に置いて作成されたプログラムが設計パターンを賢く適用する場合。それ以外の場合、ほとんどありません。しかし、アドビシステム、グーグルなどがC ++またはJavaまたはその他のOOP言語で作成する大規模な非自明なプログラムの人気を見ると、OOPが段階的に廃止されるまでには長い道のりがあると思います。その時間は、この質問をするのにはるかに適しており、新しいパラダイムの基礎を提供するのに役立つ可能性があります。