ほとんどの人は、Javaの「相続」と「組み合わせ」の2つのことに精通していると思います。この記事では、主にこれら2つのトピックについて説明します。私が何か間違ったものを書いたり、それが幼稚であり、議論が明確ではない場合、誰もが私を修正するためにメッセージを残すことを歓迎します。
2つのクラスがあるとします： AとB ：
extends場合、aはb、aはサブクラスであり、bは親クラスであり、このケースは継承であると言います。私たちは通常、これらの2つのことをどのような状況を考慮していますか？私はそれについて簡単に考えました、そして、しばしば次のシナリオがあります：
abstract classまたはinterfaceが抽出されますそれについて考えた後、実際にはこれら2つの状況しかないようですが、これら2つの状況は特別な関係を持っています。たとえば、パブリックコードのものは、 abstract classとinterface （Java 8のデフォルトメソッド）によって実際に実現できます。
さて、そんなにナンセンスを言った後、私は自分の視点を投げかけます。ようこそ：
abstract classまたはinterfaceを抽出してくださいより一般的な例：実際のプロジェクトでは、 POJOまたはmodelを定義することがよくあります。これらのモデルには、次のような同じ名詞とタイプの属性があることがよくあります。
// db table primary keyprivate int id;それは非常に一般的ですが、私は実際の仕事で多くの同僚に会いました。システムは、 BaseModelまたはRootModelという名前のクラスを定義し、上記の属性idを入れ、プロジェクト全体のすべてのモデルをこのBaseModdelクラスを継承します。あなたがそのような同僚に会ったことがあるのだろうか？このような執筆の利点と欠点は何ですか？
最初にメリットについて話しましょう。それがもたらすことができる利点を言わなければならない場合、キーボードを数回入力してサブクラスにこれらの属性を欠いていることを除いて、大きな利点は見られません。しかし、それはプロジェクトのその後のメンテナンスに非常に厄介なことを引き起こしました。
次に、この執筆の潜在的な問題について話しましょう。
ある日、何らかの理由で、プロジェクトのサブクラスA（ベースメモデルを継承する）の属性
idを使用する場所を見つけたい
あなたは賢く使用されているIDEでfind usages 。その後、多くの使用場所が見つかったことがわかります。しかし、方法はありません。また、ベースモデルを継承する他のクラスのプロパティIDの使用場所を検索しました。プロジェクトが大きくない場合、習慣が少ない場合があります。プロジェクトが少し大きい場合はどうなりますか？検索に50以上の習熟度がある場合、次に何をしますか？
この状況を避ける方法は？つまり、このようなBaseModelを使用して属性継承を使用しないでください。もちろん、厳格な期間のために、私はまだこの意味を詳細に説明する必要があります。私は属性の継承に完全に反対していません。明確にしましょう：
私が反対するのは、プロジェクト全体のすべてのモデルがベースモデルを継承し、共通のプロパティをベースモデルに配置することです
このアイデアは、それがプロジェクト全体のためであることに注意することです
私は個人的に上記のネガティブな教科書の例に遭遇することが多いので、それらについて個別に話します。これがあなたのプロジェクトで起こったかどうかはわかりません。とにかく、私は何度も同僚にだまされてきました。
「組み合わせ」と「継承」に関連する他の一般的な間違いについては、私はまだ考えていません（少なくとも誰もそれを作らないと思います）。将来的にはっきりと考えている場合、または読者が他の提案を持っている場合は、メッセージを残してコミュニケーションを残すことができることを願っています。