Diamond Problem

Wikipedia on the diamond problem:

"... the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?"

So the diamond looks like this:

  A
 / \
B   C
 \ /
  D

My question is, 开发者_如何学Cwhat happens if there is no such class A, but again B and C declare the same method, say foo(). Isn't this the same problem? Why is it then called diamond problem?

Example:

class B {
    public void foo() {...}
}

class C {
    public void foo() {...}
}

class D extends B, C {
}

new D().foo();

---

Its not the same problem.

In the original problem, the overriden method can be called from A. In your problem this can't be the case because it does not exist.

In the diamond problem, the clash happens if class A calls the method Foo. Normally this is no problem. But in class D you can never know which instance of Foo needs to be called:

         +--------+
         |   A    |
         | Foo    |
         | Bar    |
         +--------+
            /  \
           /    \
          /      \
+--------+        +--------+
|   B    |        |   C    |
| Foo    |        | Foo    |
+--------+        +--------+
          \      /
           \    /
            \  /
         +--------+
         |   D    |
         |        |
         +--------+

In your problem, there is no common ancestor that can call the method. On class D there are two flavors of Foo you can chose from, but at least you know that there are two. And you can make a choice between the two.

+--------+        +--------+
|   B    |        |   C    |
| Foo    |        | Foo    |
+--------+        +--------+
          \      /
           \    /
            \  /
         +--------+
         |   D    |
         |        |
         +--------+

But, as always, you do not need multiple inheritance. You can use aggegration and interfaces to solve all these problems.

---

In the diamond problem, class D implicitly inherits the virtual method from class A. To call it, class D would call:

A::foo()

If both classes B and C override this method, then the problem comes of which actually gets called.

In your second example however, this isn't the case as class D would need to explicitly state which was being called:

B::foo()
C::foo()

So the problems are not actually the same. In the diamond problem you aren't referencing the derived classes, but their base class, hence the ambiguity.

That's how I understand it, anyway.

Note that I'm coming from a C++ background.

---

Your second example is nowhere near the diamond problem because compiler has the ability to detect the available functions one level up of inheritance.

Once the compiler gets to know that you are using same-named functions in two base classes, it will throw error: member 'foo' found in multiple base classes of different types.

---

The diamond problem only arises from incorrect type/ontology modeling. It doesn't exist in properly-modeled systems.

The problem arises usually because developers define classes for entities based on their roles not their types. They elevate what it can do above what it actually is. The entity object carries the role not the type.

A person is a person, for example, from birth to death regardless of whether he gets married (Husband), visits mom (Son), or lands a great job (Employee). The roles for Person can be implemented with interfaces or components or mixins—fuel in the argument to prefer composition to inhertiance.

It would be reasonable to allow an entity's type to be replaced via some state machine transition. Thus, a Person could be replaced with Werewolf (full moon) or Vampire (neck bite) as the result of a state transition. The entity (some fixed GUID) remains regardless of the transition. But even this can be modeled differently—a Person with Lycanthropy and/or Vampirism. Of course, modeling to accommodate many facets can be a challenge, but it it has nothing to do with the typical limitation that classes may participate in a single inheritance chain.

An UnverifiedEmailAddress could transition to a VerifiedEmailAddress, but this is not a great example because it probably ought use a value object rather than a reference object. A better example could involve a WorkingPurchaseOrder transitioning to a SubmittedPurchaseOrder via a submit function. The function would likely return an immutable replacement (such as a Persistent Object) and be swapped into some observable state container.