5

Because any class that implements an interface is of the same type as said interface, would any relationships with the interface also apply to whatever implements it?

For example, say we have an interface called Product which has a method signature that returns an instance of class Colour. We then have 2 classes which implement this interface, called Shelf and Desk. These two classes contain an attribute of the class Colour.

UML example of relationships 1

or

UML example of relationships 2

Would the relationship only need to be shown between Product and Colour or would Product, Shelf and Desk all need to show their relationships with class Colour?

Christophe
  • 68,716
  • 7
  • 72
  • 138
jakesters42
  • 51
  • 1
  • 3
  • What is the relationship between Product and Colour ? In your diagrams the two other classes have a dependency to Product so they do not realize the interface nor inherit it. Anyway supposing the two other classes realize or inherit the interface the association between Product and Color is inherited so almost pict 1, *almost* because if the classes realize the interface they have to implement the method and that is missing in your diagrams – bruno Nov 16 '20 at 22:52
  • I believe that the relationship would be an association because Product is only returning the Colour, so it does not care for its implementation. Also when you say realize, do you mean show copies of the interface's method signatures inside of Shelf and Desk? – jakesters42 Nov 16 '20 at 23:01
  • an association you mean an attribute ? in an interface ? Your diagrams do not follow UML notation or your textual description does not correspond to your diagrams, that is a big problem to answer because impossible to know the real statement – bruno Nov 16 '20 at 23:03
  • The UML roughly follows valid notation, of which I assumed this simple example would be rather self-explanatory in understanding the relationships between every class and interface. I mean that the return type of the method getColour() is of type Colour, which would refer to the attributes stored in Shelf and Desk. – jakesters42 Nov 16 '20 at 23:08
  • I disagree, reread my first comment please. *which would refer* : the fact the method returns a Colour does not implies the (may be) implementing classes must have attributes of type Colour – bruno Nov 16 '20 at 23:10
  • I think I see your point, the notation is not correct. It should show the class Shelf and Desk implementing the Product interface, whereby the method signature getColour() returns an instance of type Colour (which would be an attribute stored within the Shelf and Desk classes). I apologise for this misunderstanding, ultimately I'm looking to learn how this would be represented correctly in a UML – jakesters42 Nov 16 '20 at 23:16

1 Answers1

6

Do associations of an interface apply to their implementation?

An interface defines a contract, stating the features that implementing class must provide and constraints that they must fulfil. If an interface has an association with a class T, then all its implementations must behave exactly as if they'd also have an association with a class T.

Here is what the UML specs tell us:

Properties owned by Interfaces (including Association ends) imply that the realizing BehavioredClassifier should maintain information corresponding to the type and multiplicity of the Property and facilitate retrieval and modification of that information. A Property declared on an Interface does not necessarily imply that there will be such a Property on a realizing BehavioredClassifier (e.g., it may be realized by equivalent get and set Operations).

So the answer to your question is ambiguous:

  • if you are using the implementing classes, you can assume that it has such an association even if it's not shown in the diagram.
  • if you're designing such an implementing class, you cannot assume that the association is automatically there: implementing is not inheriting. If you do not show anything in your model, it's unspecified how the class will fulfil its contract. If you want to be complete, you have to define the necessary associations in the implementing classes: the second diagram would therefore be more accurate and comprehensive.

You could also have, for one of the implementation, a different situation, where the association is derived from other associations and not maintained explicitly.

Does you narrative really requires an association at all?

In your narrative, you justify the need for an association because of a method that returns a type T. But having parameters or a return type is not sufficient to require an association as explained in this other SO answer. An association requires a semantic relationship.

So, your interface has more probably a dependency to Color.

Miscellaneous remarks

In both diagrams, you should show the realization dependency with a plain blank arrow-head (white triangle at the end) and not an open arrow end.

In older UML versions 1.xx, the interface had a semantic that was equivalent to an abstract class and was not allowed to have its own properties. While things are more relaxed now, I'd advise to stick with this approach because:

  • an interface is meant provide a set of behaviors
  • behaviors are implemented in operations
  • private properties are not visible to the outside world, so have nothing to do in an interface. public properties should be avoided because of the risk for encapsulation and decoupling.
  • if you really need a property, it could be the symptom of a need for a class.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • The book Head first Design Patterns actually uses this notation for it's observer implementation. Take a look at my related question; https://stackoverflow.com/questions/71095703/interface-to-interface-association-in-the-book-head-first-design-patterns – user32882 Feb 12 '22 at 21:32
  • @user32882 Thanks for the opportunity to clarify. I don't claim that interfaces can't be associated with other interfaces. On contrary. What I want to clarify here is that class inheritance is clearly defined: if a general class is associated with something, its specializations will automatically inherit the association. But when an interface is realized, its realization doesn't inherit the associations. You may assume so and not draw the association, but it's ambiguous. The UML specs (see quote) are a more reliable source about this UML semantics than head first (even if it's a good book) – Christophe Feb 12 '22 at 22:00