I'm wondering about what is considered good practice in the following scenario.
Given two interfaces I1 and I2. Logically, if the language permitted it, I would structure these as I2 inheriting from I1, but the language in question does not currently support interface inheritance.
There are one or more concrete classes C1, C2, etc. Each is an implementation variant with different performance and other distinguishing features, but with the same signature. This signature is defined by I1 and I2. If I had interface inheritance, I would say that C1 implements I2, but without that language feature, I have a choice of either saying the C1 implements I1 *and* I2 or doing what I describe next.
Since C1, C2, etc. can be substituted for each other, we want a common reference to use in places where any of them can be used. With interface inheritance, that would be I2 since it would imply all of the methods of both. Without interface inheritance, what we are doing is to define an abstract class A which implements I1 and I2 and then C1, C2, etc inherit from A. Thus, A can be used as the type of a parameter and any of C1, C2, etc. can be used.
My question is this. Normally, if a class inherits from another class or implements an interface, I would not show the properties and methods from the parent class or interface in the class unless they overrode the implementation in the parent. Here, however, the situation is a bit different since the method definitions in A are abstract, not actual implementations of the methods in I1 and I2. Similarly, the methods in C1, and C2 are where the actual implementation is provided. All that is being inherited from the abstract class is the signature of the method. So, there is a change in type in both cases which doesn't exist in the simpler cases.
In such a situation, where should the methods appear in a class diagram?
