CODEWITHSUNDEEP
interfaceumlvirtualabstractclass-diagram
PolGraphic
PolGraphic

Reputation: 3364

UML - interfaces, abstract classes or...?

I have some abstract "module" for my program. Let's say it's a GUI module. It contains only the interface for the module and its types - for compatibility with other modules (in the other module I can use GUI module and its types, not bothering about it's implementation).

So I have sth like that:

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

But even a Label or Button have only virtual methods (I guess they are interfaces of the module). The GUI module impementation's e.g. SomeGUIImp has to declare SomeButton : public GUI::Button and SomeLabel : public GUI::Label (and they will be transparent for user, because of the object factory).

I don't want to change anything in the code, I just want to make a proper UML diagram for it.

Are all that elements (Component, Clickable, Button) interfaces? Or abstract classes?

I would like to show somehow , that the Label and Button are "less abstract" (can be used by user more directly, are more specified) than Component.

Also, it would be nice to show the difference between Clickable (it's functionality) and Component (it's an abstract base for all components).

Current solution (not sure of it)

I can't say 100% why, but in my opinion, maybe the Clickable is an interface, Component is an abstract class and Button is just the regular class.

But that shows the relations inside the module, ignoring that Button (which have only pure virtual methods) also is just the declaration for some module's implementation?

Upvotes: 2

Views: 1960

Answers (2)

SomeWittyUsername
SomeWittyUsername

Reputation: 18338

The rule is very simple - classes with only pure virtual methods are interfaces, classes with part of the methods pure virtual are abstract classes, class with no virtual methods are implementation classes. If that doesn't fit into your design, you probably should rethink some things. For example, if you think of Button both as interface and as regular class, you should probably split it into 2 distinct classes - one for interface and one for implementation.

Upvotes: 2

vainolo
vainolo

Reputation: 6987

Since C++ doesn't have the notion of an interface, when a class is 100% abstract (virtual) you can model it both as an interface or as an abstract class. In your description these classes are closer semantically to interfaces, so modeling them that way would be good. The direction you are taking seems very good IMHO.

Upvotes: 1

Related Questions