1

分析ファイルのインポートとエクスポートを可能にする分析アプリケーション (AppX) があるとします。これらのファイルをエンタープライズ コラボレーション プラットフォームで共有できるように、いくつかの機能を組み込みたいと考えていますが、Jive と Workplace などの 2 つの異なるプラットフォームを使用しています。

これはやや主観的なものですが、このモデルが OO の概念の慣例と一致するかどうかを確認したいと考えています。

1 -interface CollaborationService完全な機能を実現するために実装する必要があるメソッドを定義しています。

2 - abstract class DefaultCollaborationService implements CollaborationService一部の操作のデフォルト実装を持つ があります。

3 - aclass WorkplaceCollaborationService extends DefaultCollaborationServiceと aclass JiveCollaborationService extends DefaultCollaborationServiceがあり、それぞれに独自のメソッドがあり、Default 抽象クラスのメソッドをオーバーライドします。

または..

これは良いですか:

2 - abstract class DefaultCollaborationService- インターフェイスへのリンクがないため、すべてを実装する必要はありません。

3 -class WorkplaceCollaborationService implements CollaborationService extends DefaultCollaborationServiceそしてclass JiveCollaborationService implements CollaborationService extends DefaultCollaborationService

または..

それはすべて正しくありません。より良い方法をアドバイスできますか?

4

3 に答える 3

0

オブジェクト指向のソリューションを探している場合、それは通常、ビジネス ドメインに関する「もの」に関心があります。提案された両方のソリューションで私が抱えている主な問題は、最初の段落で説明した問題についてほとんど何も反映していないことです。

それでは、問題のドメインが何で構成されているかを見てみましょう: Analytic filesJiveWorkplace 、および後者の 2 つの抽象化として「 Platform 」に言及しています。それらは、最初の段落で述べた「もの」です。

では、対処する必要がある「責任」(ビジネス機能) とは何でしょうか? あなたは「共有」について言及しているので、それで行きましょう。

これらをすべてまとめてみましょう。

public interface AnalyticFile {
    void shareTo(Platform platform);
}

public interface Platform {
    void share(byte[] data); // Whatever data is necessary
}

public final class Jive implements Platform {
    ...
}

public final class Workplace implements Platform {
    ...
}

そして、あなたが尋ねた実際の質問について:

  • 共通の機能を定義したい場合は、常にインターフェースを選択してください
  • インターフェイスを使用する場合でも、「デフォルト」または「ベース」の実装を避けるようにしてください。それは継承の目的ではありません。つまり、コードを共有するためではなく、クラス間の関係を表現するためです。
于 2017-08-24T08:07:02.630 に答える