How to indicate that a class might implement an interface?

Question

Say I have a class User and an interface Administrator. Some users are administrator and can thus implement the interface. Most aren't, however, so it's false to say that "User implements Administrator".

How can I represent that in a class diagram? Should I use the classic implementation arrow, or is there an existing stereotype for a class that can implement an interface?

• superM: Why not have a subclass of User called Administrator? It seems more logical to me than implementing an interface for a class and then restricting the usage for most of the class instances.
• Timothy Daniel: True, but I already have an inheritance tree for User (a user can be a student, a teacher etc., any of which can be a group administrator). How can I represent this?
• Bobson: Is there a reason you can't just have an IsAdmin flag on the User? It sounds like being an admin is a property of a user, not an extension to it.
• Timothy Daniel: My idea would then to have other classes that require an Administrator specifically. Like for instance a "Group" class that would have a field "Administrator owner". Of course I could use a flag, turn the "owner" field into an User and add some code to its setter method to check if the flag is true, but it doesn't sounds so right...
• itsbruce: @Bobson that's an ugly solution. Apart from anything else, it means you can only extend the class in ways envisaged when the User type was first designed. Not very OO. Use types for differentiation, not lumps of imperative code.

Answer 1

What you want is a Decorator.

An Administrator would be a subclass of User, and its primary member attribute would be a User object.

Thus a Student Adminstrator would be an Administrator containing a Student (which is a subclass of User, right? The Administrator-specific attributes are set in the Adminstrator class, with the User methods passed through from the User object.

• Bobson: Oooh, really good idea. Why make Administrator a subclass of User, though?
• Timothy Daniel: Ah yeah, I've heard a similar idea with having an Administrator class containing a User attribute. Then I can use the Administrator everywhere I need it.
• itsbruce: @Bobson the Decorator pattern allows individual instances of a class to be enhanced without requiring any modification to the design of the original type.. The enhanced object has to be usable wherever the original type can be used. Otherwise, you have to litter the user object with isaWhatever flags, and you can only enhance the object in ways specifically designed in.
• Marjan Venema: @itsbruce that still doesn't mean that an administrator needs to be a subclass of a user, just that the administrator interface needs to be an extension of the user interface. And even when you don't do that and both interfaces are unrelated (except for the language's root interface interface), you wouldn't need to litter your code with isaWhatever flags. Just request the administrator interface from the user interface reference and have "normal" user interface implementers support a null-pattern for the administrator interface.
• Matthew Flynn: @MarjanVenema Indeed, the idea behind the decorator pattern would be that the User interface is a generalization (super-type) of the Administrator interface. The concrete realizations of those interfaces are a separate matter.

Answer 2

It makes no sense to say that a class can implement an interface. Either it does or it doesn't, and that's determined as the code is written. Specific instances (users) can't make that decision for themselves, although they can set an IsAdministrator flag instead.

If the IsAdministrator flag is insufficient, then (as @superM said) the design you want is subclassing. A User has some properties. Some User are actually Administrator, which has additional properties. Therefore Administrator inherits from User, and should be represented as such.