2

プログラム用の抽象的な「モジュール」があります。それがGUIモジュールだとしましょう。モジュールとそのタイプのインターフェースのみが含まれています-他のモジュールとの互換性のためです（他のモジュールでは、GUIモジュールとそのタイプを使用でき、実装について気にする必要はありません）。

だから私はそのようなsthを持っています:

GUI::Component //represent the abstract component (button, label etc.)
//so it's only the base class for components

GUI::Clickable //if any component is clickable, it must inherit from it

GUI::Button : public Component, public Clickable
GUI::Label : public Component

しかし、LabelまたはButton仮想メソッドしか持っていません（モジュールのインターフェースだと思います）。GUI モジュール実装の例では、 andSomeGUIImpを宣言する必要があります (オブジェクト ファクトリにより、and はユーザーに対して透過的になります)。SomeButton : public GUI::ButtonSomeLabel : public GUI::Label

コードを変更したくはありません。適切な UML ダイアグラムを作成したいだけです。

そのすべての要素 ( Component, Clickable, Button) はインターフェースですか? それとも抽象クラス？

LabelとButtonが よりも「抽象度が低い」(ユーザーがより直接的に使用でき、より詳細に指定されている) ことを何らかの形で示したいと思いますComponent。

Clickableまた、 (機能性) とComponent(すべてのコンポーネントの抽象ベース) の違いを示すとよいでしょう。

現在の解決策（確信が持てない）

理由は 100% とは言えませんが、私の意見では、これはおそらくClickableインターフェイスでComponentあり、抽象クラスであり、Button単なる通常のクラスです。

しかし、それはモジュール内の関係を示しており、それを無視してButton(純粋な仮想メソッドしか持たない) も、一部のモジュールの実装の宣言にすぎませんか?

4

2 に答える 2

2

ルールは非常に単純です。純粋仮想メソッドのみを持つクラスはインターフェースであり、純粋仮想メソッドの一部を持つクラスは抽象クラスであり、仮想メソッドを持たないクラスは実装クラスです。それが設計に合わない場合は、おそらくいくつかのことを再考する必要があります。たとえば、Buttonインターフェイスと通常のクラスの両方を考える場合、おそらくインターフェイス用と実装用の 2 つの異なるクラスに分割する必要があります。

于 2012-11-18T07:08:13.490 に答える
1

C++ にはインターフェイスの概念がないため、クラスが 100% 抽象 (仮想) の場合、インターフェイスまたは抽象クラスの両方としてモデル化できます。あなたの説明では、これらのクラスは意味的にインターフェースに近いので、そのようにモデル化するのが良いでしょう。あなたが取っている方向は非常に良いようです。

于 2012-11-18T06:53:17.833 に答える