再利用性は良いデザインと同義ですか？

再利用性は、優れたソフトウェア設計の特徴です。

優れたソフトウェア設計において、再利用性は許容できる光沢（「意味の簡単な表記」）ですか？どうして？

番号。

再利用は優れたデザインの指標です。これは、システムの結合が十分に緩く、特定のユニットの凝集度が十分に高いため、依存関係の問題が発生したり、ほとんどのコードを書き直したりせずに再利用できることを示しています。

再利用性は主に幻想です。ユニットがどこでどのように使用されるかを事前に知らなければ、ユニットの「再利用可能性」を測定することは検証不可能です。多くの開発者は、「再利用可能な」コンポーネントを設計しようとしますが、しばしば「柔軟」にしようと試みた特定の側面が、必ずしも必要のないものであることを発見します。

私は別の「光沢」、つまりテスト容易性を使用します。

現在、私はTDDの擁護者ではありませんし、何でもすべてを単体テストする必要性を感じていません。しかし、コンポーネントのテストを作成すると、そのカップリング/凝集特性の非常に優れたアイデアがすぐに得られます。それが抽象化に依存している場合、それは疎結合です。依存関係を模倣するのは簡単で、良いデザインを示唆しています。明確な目的がある場合（「単一責任の原則」も参照）、その動作は比較的直感的であり、何をテストするかを容易に理解でき、これも優れた設計を示唆しています。

もちろん、これは優れたデザインを保証するものではありません。実際の実装またはアーキテクチャ全体でさえ、その指定された目的には完全に不適切である可能性があります。しかし、少なくとも、スパゲッティコードやGod Objectsを使用していないことを示しています。

コンポーネントの「再利用性」については、特に「良い設計」の証拠として使用しないでください。これは、実際に再利用され、設計が大幅に変更された後で、後からしか確立できないものです。

番号。

再利用性は将来の開発を加速できるため、優れた機能です。（実際には、ほとんどの組織は、彼らが望んでいたものとほぼ同じ速度で将来の開発が加速されると考えています。）しかし、重要なソフトウェアには、そのアプリケーションに固有の部分があります。さらに、ドメインの経験がない人が再利用可能なソフトウェアを作成しようとすると、通常、その部分を難読化してパフォーマンスを低下させますが、実際に再利用可能にすることはできません。

したがって、優れた設計はモジュール式であり、再利用できるのは、その部分が再利用できることがわかり、実際に再利用性を実現する専門知識がある場合のみです。他の場所では、物事をきれいにしようとする必要がありますが、再利用性について心配する必要はありません。（メモを書いている頭の後ろを除いて、将来のいくつかのシステムでは、それを再利用可能にする方法がわかるようにします。）

私は、再利用性と優れたデザインの関係は再帰的ではないと信じています（そしてこれは私の個人的な信念です）。したがって、基本的で単純な答えは「いいえ」です。優れた設計ガイドに興味がある場合は、このウィキペディアの記事を確認してください。

システムのコアをさまざまな状況で再利用できるように設計することは非常に複雑であるため、優れたソフトウェア設計は、少なくとも一部のコアパーツで再利用可能でなければなりません。ソースコードを実際に再利用する人はほとんどいないと思います。 （そして私は経験からこれを言っています）

必要なすべてのタスクを実行するが、設計上の考慮事項がまったくない、非常に多くの責任を持つクラス（別名Blob）を検討してください。そのようなクラスを持つほとんどの人々は何度もそれを使用するでしょう、そして私はそれが再利用、デザインレスな再利用であることに同意する必要があると思います。

説明をあまりごちゃごちゃにしないでほしい

優れた設計のより良い指標は、単一責任の原則や各コンポーネントの凝集性の維持などの基本的な考え方を順守することです。簡潔で簡潔なインターフェースを備えた抽象化を使用し、Liskov Substitution Principalへの準拠を維持することで、何が再利用され、何が再利用されないかを予測しようとせずに、再利用を促進します。

これらの基本的な設計原則に従うことで、コードのテストと再利用が容易になります。

良いデザイン==良いデザイン、再利用性は副産物です。

多くの場合、再利用性は暗黙的な設計目標です。後で再利用できるようにコンポーネントまたはデザイン全体を作成できる場合、それを行う必要があることは明らかです。常に明白であるとは限らないのは、何かを再利用可能にするのに多くの時間と労力（そしてお金）がかかる可能性があるため、再利用可能性の利点とそのコストを比較検討する必要があることです。

特に顧客が再利用性を必要としない場合、顧客の必要性の2倍のコストや構築に2倍の時間がかかる再利用可能な設計は、顧客の観点からは良い設計ではありません。

それらは明らかに良いように見えるので、暗黙の設計目標であるとしばしば考えられる多くの同様の属性があります：

• コストを最小限に抑える

• 開発時間を最小化

• 複雑さを最小限に抑える

• 信頼性を最大化

これらはすべて客観的に優れていますが、特定のクライアントにとって特定の時間に常に重要であるとは限らないため、顧客が何を必要としているのかを完全に理解することが重要です（その顧客が単なる上司であっても）。この事実を思い出させることを意図した多くの格言があります（たとえば、「完了は完璧よりも優れている」および「良い、安い、速い：2つ選んでください」）。しかし、それでもなお、実際、あらゆる点で優れている必要がない場合でも、あらゆる点で優れているソフトウェアを作成します。

タイトルの質問に到達するには、次のようにします。いいえ、再利用性は優れたデザインと同義ではありません。再利用性は特定の優れた設計の有用なコンポーネントである可能性がありますが、それが必要な場合に限られます。

必ずしも。明らかに再利用できないものを再利用可能にすると、それは悪い設計になります。

たとえば、会社に固有のデータでいっぱいのファイルを書き込んでいて、そのデータを別の場所に一度インポートする場合、なぜそれを再利用可能にする必要があるのでしょうか。

ただし、フレームワークにまだフレームワークがない場合は、ファイルに書き込むコードを再利用可能にする必要がある場合があります。それは良いデザインでしょう。

私はノーと言います、それは主にそれがコードの小さなセグメントを記述するだけだからです。使いやすさが最も重要なのは、ユーティリティ領域の中心と外側であり、その中間ではないことがわかりました。再利用性が品質設計の有用な測定基準であると私が考えるいくつかの例を挙げます。

コアスタッフ

• ページを簡単かつ一貫して（またはあらゆる種類のUIに対して）追加できるWebformテンプレート
• すべてのMVVMアプリケーションに含まれるViewModel基本クラスのようなデザインパターンヘルパー

ユーティリティスタッフ

• SMTPメッセージを送信するメールクラス（常に使用）
• GIS距離計算機クラス（多くのアプリで使用されています）

ほとんどのアプリの70〜80％を占めるCRUDについては、再利用性が価値のある指標であるとはまったく思いません。