UML Inheritance
No edit summary
No edit summary
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
With the ambition to make it easy for people to benefit from object-oriented approaches using MDriven and MDriven Designer, I will give a quick introduction to UML inheritance.
With the ambition to make it easy for people to benefit from object-oriented approaches using MDriven and MDriven Designer, I will give a quick introduction to UML inheritance.
* UML inheritance differs from “I get you stuff when you die.” It is also different from “Oh, look, that kid really looks like her Mother.”
* UML inheritance is this: “A child class has all attributes and associations that a parent class has, and the child also has attributes and/or associations of its own that the parent does not have.” In other words, UML inheritance is “specialization” and “generalization”; a child class is a “specialized” version of the parent, and a parent is a more “generalized” definition of the child class.
* UML inheritance is the same as OO inheritance (Object-oriented inheritance).
* UML inheritance will allow you to inherit the properties of multiple parents – but very few OO languages allow for so-called multiple inheritances (c++ does, c# & VB.NET does not, and since ECO focuses on the latter languages, ECO does not support it either), so I will not mention multiple inheritances again in this post. This means a class can have only one parent class (or no parent class, but never many parents).


UML inheritance differs from “I get you stuff when you die.” It is also different from “Oh, look, that kid really looks like her Mother.”
=== An Example ===
 
Fruit. Fruit is a pretty generic class. If we think of specializations of fruit, we will find Apple, Orange, Pear, Banana, Pineapple, etc.
UML inheritance is this: “A child class has all attributes and associations that a parent class has, and the child also has attributes and/or associations of its own that the parent does not have.” In other words, UML inheritance is “specialization” and “generalization”; a child class is a “specialized” version of the parent, and a parent is a more “generalized” definition of the child class.
 
UML inheritance is the same as OO inheritance (Object-oriented inheritance).
 
UML inheritance will allow you to inherit the properties of multiple parents – but very few OO languages allow for so-called multiple inheritance (c++ does, c# & VB.NET does not, and since ECO focuses on the latter languages, ECO does not support it either), so I will not mention multiple inheritances again in this post. This means a class can only have one parent class (or no parent class, but never many parents).
 
==== An Example ====
Fruit. Fruit is a pretty generic class. If we think of specializations of fruit, we will find apple, orange, pear, banana, pineapple, etc.


[[File:FRUIT MODELS.png|frameless|278x278px]]
[[File:FRUIT MODELS.png|frameless|278x278px]]
Line 20: Line 16:
Superclass is a more correct UML term than “Parent class.” Instead of “Child class,” the correct UML terminology is Subclass. So I will use Super- and Subclass from now on.
Superclass is a more correct UML term than “Parent class.” Instead of “Child class,” the correct UML terminology is Subclass. So I will use Super- and Subclass from now on.


==== Why is Inheritance So Useful? ====
=== Why is Inheritance So Useful? ===
The obvious benefit of inheritance is the ability to introduce common properties that all fruit has in one place. If there are properties that all fruits have, they will go into the Fruit class rather than defining them over and over in the subclasses.
The obvious benefit of inheritance is the ability to introduce common properties that all fruit has in one place. If there are properties that all fruits have, they will go into the Fruit class rather than defining them over and over in the subclasses.


Line 47: Line 43:
  18:    }
  18:    }
  19: }
  19: }
The MDriven Book - See: [[Training:Polymorphism|Polymorphism]]


== Polymorphism ==
  [[Category:UML]]
Polymorphism is a fancy word for an important concept: poly==many, morph==shape => many shapes. In our example, we use polymorphism in the association from country to fruit - namely, a resulting list that can contain different subclasses of fruit – apples, oranges, etc.
 
Polymorphism allows us to operate on stuff we do not know much about. 
 
Check this out:
 
[[File:Fruit model 2.png|frameless|328x328px]]
 
I add a method on Fruit that I make virtual:
 
[[File:Properties 2.png|frameless|349x349px]]
 
I can implement this to return a default value on Fruit and override it on the subclasses that should return a different value:
 
[[File:Overrided subclasses fruits.png|frameless|355x355px]]
  1: public partial class Fruit {
2:    public virtual bool HasSeedsYouNoticeWhenYouEat()
3:    {
4:        return true;
5:    }
6: }
 
1: public partial class Banana {
2:    public override bool HasSeedsYouNoticeWhenYouEat()
3:    {
4:        return false;
5:    }
6: }
Having this, I can write code that goes over a list of Fruit and ask if the fruit <code>HasSeedsThatYouNoticeWhenYouEat</code> like this:
1: List<Fruit> crapfruit = new List<Fruit>();
2: List<Fruit> okfruit = new List<Fruit>();
3: foreach (Fruit fruit in malaysia.ExportsTheseFruits)
4: {
5:    if (fruit.HasSeedsYouNoticeWhenYouEat())
6:        crapfruit.Add(fruit);
7:    else
8:        okfruit.Add(fruit);
9: }
If you are still with me, I also want to mention the concept of “Abstract”. When we have a model like the one above, you should think of the Fruit class as being abstract – meaning that having an instance of a fruit (a real fruit) that is of type Fruit should not be legal. A fruit-instance must be one of the subclasses; it can be an Apple, Pear, Orange, Banana, or Pineapple (in our model) but never just “Fruit.”
 
In Object orientation terms, Abstract means that the compiler will treat any attempt to create an instance as an error. It is an error because the developer that defined the class never intended it for direct use - it was designed as an abstraction or generalization of a set of subclasses.
 
My recommendation is to always treat classes that have subclasses (aka superclasses) as being abstract. In the Fruit sample above, this might be obvious, but remember this when you classify your domain where it might not be so obvious.
[[Category:UML]]
[[Category:The MDriven Book]]
[[Category:The MDriven Book]]
{{Edited|July|12|2024}}

Latest revision as of 05:34, 2 April 2024

With the ambition to make it easy for people to benefit from object-oriented approaches using MDriven and MDriven Designer, I will give a quick introduction to UML inheritance.

  • UML inheritance differs from “I get you stuff when you die.” It is also different from “Oh, look, that kid really looks like her Mother.”
  • UML inheritance is this: “A child class has all attributes and associations that a parent class has, and the child also has attributes and/or associations of its own that the parent does not have.” In other words, UML inheritance is “specialization” and “generalization”; a child class is a “specialized” version of the parent, and a parent is a more “generalized” definition of the child class.
  • UML inheritance is the same as OO inheritance (Object-oriented inheritance).
  • UML inheritance will allow you to inherit the properties of multiple parents – but very few OO languages allow for so-called multiple inheritances (c++ does, c# & VB.NET does not, and since ECO focuses on the latter languages, ECO does not support it either), so I will not mention multiple inheritances again in this post. This means a class can have only one parent class (or no parent class, but never many parents).

An Example

Fruit. Fruit is a pretty generic class. If we think of specializations of fruit, we will find Apple, Orange, Pear, Banana, Pineapple, etc.

FRUIT MODELS.png

The lines ending with the big arrow are called a Generalization-association, meaning that if you follow it, you get something more generalized of the class that you leave. If you follow it in the other direction, you get the opposite of generalization – specialization. You will notice that in MDriven when you add generalization associations, the class’s superclass is updated in the object inspector.

Properties fruits.png

Superclass is a more correct UML term than “Parent class.” Instead of “Child class,” the correct UML terminology is Subclass. So I will use Super- and Subclass from now on.

Why is Inheritance So Useful?

The obvious benefit of inheritance is the ability to introduce common properties that all fruit has in one place. If there are properties that all fruits have, they will go into the Fruit class rather than defining them over and over in the subclasses.

Model fruits + subclasses.png

The true power of inheritance is that it resembles how people reason and think. As humans, we always generalize. Our language and communication depend on it. This fact is the reason for some bad things in society – prejudice where we jump to conclusions based on earlier experience or hearsay – and some good things, like instantly knowing how to use a door knob even if we have never seen that particular type of door knob before.

With the model we now have, we can see the benefit that strong types give. Our code will now look like this:

1: Country malaysia=new Country(this.ServiceProvider());
2:
3: Apple apple = new Apple(this.ServiceProvider());
4: Orange orange = new Orange(this.ServiceProvider());
5:
6: apple.GrowsInTheseCountries.Add(malaysia);
7: orange.GrowsInTheseCountries.Add(malaysia);
8:
9: foreach (Fruit fruit in malaysia.ExportsTheseFruits)
10: {
11:     if (fruit is Apple)
12:     {
13:       // Do apple specific operations
14:     }
15:     else if (fruit is Orange)
16:     {
17:         // Do orange specific operations
18:     }
19: }

The MDriven Book - See: Polymorphism

This page was edited 50 days ago on 04/02/2024. What links here