People claim Java knows no diamond problem. I can only have multiple inheritance with interfaces and since they have no implementation, I have no diamond problem. Is this really true?
yes, because you control the implementation of the interface in D. The method signature is the same between both interfaces (B/C), and seeing as interfaces have no implementation - no problems.
I don't know Java, but if Interfaces B and C inherit from Interface A, and class D implements Interfaces B and C, then class D just implements the move method once, and it is A.Move that it should implement. As you say, the compiler has no problem with this.
From the example you give regarding the AmphibianVehicle implementing GroundVehicle and WaterVehicle, this could easily be solved by storing a reference to Environment, for example, and exposing a Surface Property on Environment that the Move method of AmphibianVehicle would inspect. No need for this to be passed as a parameter.
You are right in the sense that it is something for the programmer to solve, but at least it compiles and should not be a 'problem'.
I realize that this is a specific instance, not a general solution, but it sounds like you need an additional system to determine state and decide on which kind of move() the vehicle would perform.
It seems that in the case of an amphibious vehicle, the caller (let's say "throttle") would have no idea of the state of the water/ground, but an intermediate determining object like "transmission" in conjunction with "traction control" might figure it out, then call move() with the proper parameter move(wheels) or move(prop).
C# has explicit interface implementation to partially deal with this. At least in the case where you've got one of the intermediate interfaces (an object thereof..)
However what probably happens is that the AmphibianVehicle object knows whether it is currently on water or land, and does the right thing.
There is no Diamond Problem with Interface-based inheritance.
With Class-based inheritance, the multiple extended classes can have different implementation of a method, so there's ambiguity as to which method is actually used at runtime.
With Interface-based inheritance there's only one implemenation of the method, so there's no ambiguity.
EDIT: Actually, the same would apply to Class-based inheritance for methods declared as Abstract in the superclass.
The problem really exists. In the sample the AmphibianVehicle-Class need another information - the surface. My prefered solution is to add a getter/setter method on the AmpibianVehicle class to change the surface member (enumeration). The implementation could now do the right thing and the class stay encapsulated.
I don't think that preventing concrete multiple inheritance is moving the problem from the compiler to the programmer. In the example you gave it would still be necessary for the programmer to specify to the compiler which implementation to use. There is no way the compiler could guess which is correct.
For your amphibian class, you could add a method to determine if the vehicle is on water or land and use this decide on the move method to use. This will preserve the parameterless interface.
move()
{
if (this.isOnLand())
{
this.moveLikeLandVehicle();
}
else
{
this.moveLikeWaterVehicle();
}
}
If I know have an AmphibianVehicle interface, that inherits of GroundVehicle and WaterVehicle, how would I implement it's move() method?
You would provide the implementation suitable for AmphibianVehicles.
If a GroundVehicle moves "differently" (i.e. takes different parameters than a WaterVehicle), then AmphibianVehicle inherits two different methods, one for on water, one for on the ground. If this is not possible, then AmphibianVehicle shouldn't inherit from GroundVehicle and WaterVehicle.
Is a diamond problem always the cause of bad class design and something neither programmer nor compiler needs to solve, because it shouldn't exist in the first place?
If it's due to bad class design, it is the programmer that needs to solve it, since the compiler wouldn't know how.
You can have the diamond problem in C++ (that allows multiple inheritance), but not in Java or in C#. There is no way for inheriting from two classes. Implement two interfaces with the same method declaration doesn't implies in this situation, since the concrete method implementation can only be made at the class.
In this case, it would probably be most advantageous to have AmphibiousVehicle be a subclass of Vehicle (sibling of WaterVehicle and LandVehicle), so as to completely avoid the problem in the first place. It would probably be more correct anyway, since an amphibious vehicle isn't a water vehicle or a land vehicle, it's a different thing altogether.
In your example, move() belongs to the Vehicle interface and defines the contract "going from point A to point B".
When GroundVehicle and WaterVehicle extend Vehicle, they implicitly inherit this contract (analogy: List.contains inherits its contract from Collection.contains -- imagine if it specified something different!).
So when the concrete AmphibianVehicle implements move(), the contract it really needs to respect is Vehicle's. There is a diamond, but the contract doesn't change whether you consider one side of the diamond or the other (or I would call that a design problem).
If you need the contract of "moving" to embody the notion of surface, don't define it in a type that doesn't model this notion:
public interface GroundVehicle extends Vehicle {
void ride();
}
public interface WaterVehicle extends Vehicle {
void sail();
}
(analogy: get(int)'s contract is defined by the List interface. It couldn't possibly be defined by Collection, as collections are not necessarily ordered)
Or refactor your generic interface to add the notion:
public interface Vehicle {
void move(Surface s) throws UnsupportedSurfaceException;
}
The only problem I see when implementing multiple interfaces is when two methods from totally unrelated interfaces happen to collide:
public interface Vehicle {
void move();
}
public interface GraphicalComponent {
void move(); // move the graphical component on a screen
}
// Used in a graphical program to manage a fleet of vehicles:
public class Car implements Vehicle, GraphicalComponent {
void move() {
// ???
}
}
But then that wouldn't be a diamond. More like an upside-down triangle.
If move() has semantic differences based on it being Ground or Water (rather than GroundVehicle and WaterVehicle interfaces both themselves extending GeneralVehicle interface that has the move() signature) but it is expected that you will mix and match ground and water implementers then your example one is really one of a poorly designed api.
The real issue is when the name collision is, effectively, accidental. for example (very synthetic):
interface Destructible
{
void Wear();
void Rip();
}
interface Garment
{
void Wear();
void Disrobe();
}
If you have a Jacket which you wish to be both a garment, and destructible you will have a name collision on the (legitimately named) wear method.
Java has no solution for this (the same is true for several other statically typed languages). Dynamic programming languages will have a similar issue, even without the diamond or inheritance, it's just a name collision (an inherent potential issue with Duck Typing).
.Net has the concept of explicit interface implementations whereby a class can define two methods of the same name and signature so long as both are marked to two different interfaces. The determination of the relevant method to call is based on compile time known interface of the variable (or if by reflection by the explicit choice of the callee)
That reasonable, likely name collisions are so hard to come by and that java has not been pilloried as unusable for not providing the explicit interface implementations would suggest that the problem is not a significant one for real world use.
The diamond problem in C++ is already solved: use virtual inheritance. Or better yet, don't be lazy and inherit when it's not necessary (or unavoidable). As for the example you gave, this could be solved by redefining what it means to be capable of driving on the ground or in the water. Does the ability to move through water really define a water-based vehicle or is just something the vehicle is able to do? I'd rather think that the move() function you described has some sort of logic behind it that asks "where am I and can I actually move here?" The equivalent of a bool canMove() function that depends on the current state and the inherent abilities of the vehicle. And you don't need multiple inheritance to solve that problem. Just use a mixin that answers the question in different ways depending on what's possible and takes the superclass as a template parameter so the virtual canMove function will be visible through the inheritance chain.
Actually, if Student and Teacher are both interfaces, it does in fact solve your problem. If they are interfaces, then getDepartment is simply a method that must appear in your GradTeachingFellow class. The fact that both the Student and Teacher interfaces enforce that interface isn't a conflict at all. Implementing getDepartment in your GradTeachingFellow class would satify both interfaces without any diamond problem.
BUT, as pointed out in a comment, this doesn't solve the problem of a GradStudent teaching/being a TA in one department, and being a student in another. Encapsulation is probably what you want here:
public class Student {
String getDepartment() {
return "Economics";
}
}
public class Teacher {
String getDepartment() {
return "Computer Engineering";
}
}
public class GradStudent {
Student learning;
Teacher teaching;
public String getDepartment() {
return leraning.getDepartment()+" and "+teaching.getDepartment(); // or some such
}
public String getLearningDepartment() {
return leraning.getDepartment();
}
public String getTeachingDepartment() {
return teaching.getDepartment();
}
}
It doesn't matter than a GradStudent doesn't conceptually "have" a teacher and student - encapsulation is still the way to go.
The problem that you're seeing in the Student / Teacher example is simply that your data model is wrong, or at least insufficient.
The Student and Teacher classes are conflating two different concepts of "department" by using the same name for each of them. If you want to use this kind of inheritance, you should instead define something like "getTeachingDepartment" in Teacher and "getResearchDepartment" in Student. Your GradStudent, which is both a Teacher and a Student, implements both.
Of course, given the realities of graduate school, even this model is probably insufficient.