Fri, May 31, 2019 4:50:29 PM
Introduction to Objects 21�<br/>
(This UML diagram indicates composition with the filled diamond, which states there is one <br/>
car. I will typically use a simpler form: just a line, without the diamond, to indicate an <br/>
association.5) <br/>
Composition comes with a great deal of flexibility. The member objects of your new class are <br/>
typically private, making them inaccessible to the client programmers who are using the <br/>
class. This allows you to change those members without disturbing existing client code. You <br/>
can also change the member objects at run time, to dynamically change the behavior of your <br/>
program. Inheritance, which is described next, does not have this flexibility since the <br/>
compiler must place compile-time restrictions on classes created with inheritance. <br/>
Because inheritance is so important in object-oriented programming, it is often highly <br/>
emphasized, and the new programmer can get the idea that inheritance should be used <br/>
everywhere. This can result in awkward and overly complicated designs. Instead, you should <br/>
first look to composition when creating new classes, since it is simpler and more flexible. If <br/>
you take this approach, your designs will be cleaner. Once you�ve had some experience, it will <br/>
be reasonably obvious when you need inheritance. <br/>
Inheritance <br/>
By itself, the idea of an object is a convenient tool. It allows you to package data and <br/>
functionality together by concept, so you can represent an appropriate problem-space idea <br/>
rather than being forced to use the idioms of the underlying machine. These concepts are <br/>
expressed as fundamental units in the programming language by using the class keyword. <br/>
It seems a pity, however, to go to all the trouble to create a class and then be forced to create <br/>
a brand new one that might have similar functionality. It�s nicer if we can take the existing <br/>
class, clone it, and then make additions and modifications to the clone. This is effectively <br/>
what you get with inheritance, with the exception that if the original class (called the base <br/>
class or superclass or parent class) is changed, the modified �clone� (called the derived class <br/>
or inherited class or subclass or child class) also reflects those changes. <br/>
<br/>
(The arrow in this UML diagram points from the derived class to the base class. As you will <br/>
see, there is commonly more than one derived class.) <br/>
A type does more than describe the constraints on a set of objects; it also has a relationship <br/>
with other types. Two types can have characteristics and behaviors in common, but one type <br/>
may contain more characteristics than another and may also handle more messages (or <br/>
handle them differently). Inheritance expresses this similarity between types by using the <br/>
concept of base types and derived types. A base type contains all of the characteristics and <br/>
behaviors that are shared among the types derived from it. You create a base type to <br/>
������������������������������������������������������������<br/>
5 This is usually enough detail for most diagrams, and you don�t need to get specific about whether you�re using <br/>
aggregation or composition. <br/>
represent the core of your ideas about some objects in your system. From the base type, you <br/>
derive other types to express the different ways that this core can be realized. <br/>
For example, a trash-recycling machine sorts pieces of trash. The base type is �trash�, and <br/>
each piece of trash has a weight, a value, and so on, and can be shredded, melted, or <br/>
decomposed. From this, more specific types of trash are derived that may have additional <br/>
characteristics (a bottle has a color) or behaviors (an aluminum can may be crushed, a steel <br/>
can is magnetic). In addition, some behaviors may be different (the value of paper depends <br/>
on its type and condition). Using inheritance, you can build a type hierarchy that expresses <br/>
the problem you�re trying to solve in terms of its types. <br/>
A second example is the classic �shape� example, perhaps used in a computer-aided design <br/>
system or game simulation. The base type is �shape,� and each shape has a size, a color, a <br/>
position, and so on. Each shape can be drawn, erased, moved, colored, etc. From this, specific <br/>
types of shapes are derived (inherited)�circle, square, triangle, and so on�each of which <br/>
may have additional characteristics and behaviors. Certain shapes can be flipped, for <br/>
example. Some behaviors may be different, such as when you want to calculate the area of a <br/>
shape. The type hierarchy embodies both the similarities and differences between the shapes. <br/>
<br/>
Casting the solution in the same terms as the problem is very useful because you don�t need a <br/>
lot of intermediate models to get from a description of the problem to a description of the <br/>
solution. With objects, the type hierarchy is the primary model, so you go directly from the <br/>
description of the system in the real world to the description of the system in code. Indeed, <br/>
one of the difficulties people have with object-oriented design is that it�s too simple to get <br/>
from the beginning to the end. A mind trained to look for complex solutions can initially be <br/>
stumped by this simplicity. <br/>
When you inherit from an existing type, you create a new type. This new type contains not <br/>
only all the members of the existing type (although the private ones are hidden away and <br/>
inaccessible), but more importantly it duplicates the interface of the base class. That is, all <br/>
the messages you can send to objects of the base class you can also send to objects of the <br/>
derived class. Since we know the type of a class by the messages we can send to it, this means <br/>
that the derived class is the same type as the base class. In the previous example, �A circle is <br/>
a shape.� This type equivalence via inheritance is one of the fundamental gateways in <br/>
understanding the meaning of object-oriented programming. <br/>
Since both the base class and derived class have the same fundamental interface, there must <br/>
be some implementation to go along with that interface. That is, there must be some code to <br/>
execute when an object receives a particular message. If you simply inherit a class and don�t <br/>
22 Venkata Pilaka Venkata Pilaka <br/>
(This UML diagram indicates composition with the filled diamond, which states there is one <br/>
car. I will typically use a simpler form: just a line, without the diamond, to indicate an <br/>
association.5) <br/>
Composition comes with a great deal of flexibility. The member objects of your new class are <br/>
typically private, making them inaccessible to the client programmers who are using the <br/>
class. This allows you to change those members without disturbing existing client code. You <br/>
can also change the member objects at run time, to dynamically change the behavior of your <br/>
program. Inheritance, which is described next, does not have this flexibility since the <br/>
compiler must place compile-time restrictions on classes created with inheritance. <br/>
Because inheritance is so important in object-oriented programming, it is often highly <br/>
emphasized, and the new programmer can get the idea that inheritance should be used <br/>
everywhere. This can result in awkward and overly complicated designs. Instead, you should <br/>
first look to composition when creating new classes, since it is simpler and more flexible. If <br/>
you take this approach, your designs will be cleaner. Once you�ve had some experience, it will <br/>
be reasonably obvious when you need inheritance. <br/>
Inheritance <br/>
By itself, the idea of an object is a convenient tool. It allows you to package data and <br/>
functionality together by concept, so you can represent an appropriate problem-space idea <br/>
rather than being forced to use the idioms of the underlying machine. These concepts are <br/>
expressed as fundamental units in the programming language by using the class keyword. <br/>
It seems a pity, however, to go to all the trouble to create a class and then be forced to create <br/>
a brand new one that might have similar functionality. It�s nicer if we can take the existing <br/>
class, clone it, and then make additions and modifications to the clone. This is effectively <br/>
what you get with inheritance, with the exception that if the original class (called the base <br/>
class or superclass or parent class) is changed, the modified �clone� (called the derived class <br/>
or inherited class or subclass or child class) also reflects those changes. <br/>
<br/>
(The arrow in this UML diagram points from the derived class to the base class. As you will <br/>
see, there is commonly more than one derived class.) <br/>
A type does more than describe the constraints on a set of objects; it also has a relationship <br/>
with other types. Two types can have characteristics and behaviors in common, but one type <br/>
may contain more characteristics than another and may also handle more messages (or <br/>
handle them differently). Inheritance expresses this similarity between types by using the <br/>
concept of base types and derived types. A base type contains all of the characteristics and <br/>
behaviors that are shared among the types derived from it. You create a base type to <br/>
������������������������������������������������������������<br/>
5 This is usually enough detail for most diagrams, and you don�t need to get specific about whether you�re using <br/>
aggregation or composition. <br/>
represent the core of your ideas about some objects in your system. From the base type, you <br/>
derive other types to express the different ways that this core can be realized. <br/>
For example, a trash-recycling machine sorts pieces of trash. The base type is �trash�, and <br/>
each piece of trash has a weight, a value, and so on, and can be shredded, melted, or <br/>
decomposed. From this, more specific types of trash are derived that may have additional <br/>
characteristics (a bottle has a color) or behaviors (an aluminum can may be crushed, a steel <br/>
can is magnetic). In addition, some behaviors may be different (the value of paper depends <br/>
on its type and condition). Using inheritance, you can build a type hierarchy that expresses <br/>
the problem you�re trying to solve in terms of its types. <br/>
A second example is the classic �shape� example, perhaps used in a computer-aided design <br/>
system or game simulation. The base type is �shape,� and each shape has a size, a color, a <br/>
position, and so on. Each shape can be drawn, erased, moved, colored, etc. From this, specific <br/>
types of shapes are derived (inherited)�circle, square, triangle, and so on�each of which <br/>
may have additional characteristics and behaviors. Certain shapes can be flipped, for <br/>
example. Some behaviors may be different, such as when you want to calculate the area of a <br/>
shape. The type hierarchy embodies both the similarities and differences between the shapes. <br/>
<br/>
Casting the solution in the same terms as the problem is very useful because you don�t need a <br/>
lot of intermediate models to get from a description of the problem to a description of the <br/>
solution. With objects, the type hierarchy is the primary model, so you go directly from the <br/>
description of the system in the real world to the description of the system in code. Indeed, <br/>
one of the difficulties people have with object-oriented design is that it�s too simple to get <br/>
from the beginning to the end. A mind trained to look for complex solutions can initially be <br/>
stumped by this simplicity. <br/>
When you inherit from an existing type, you create a new type. This new type contains not <br/>
only all the members of the existing type (although the private ones are hidden away and <br/>
inaccessible), but more importantly it duplicates the interface of the base class. That is, all <br/>
the messages you can send to objects of the base class you can also send to objects of the <br/>
derived class. Since we know the type of a class by the messages we can send to it, this means <br/>
that the derived class is the same type as the base class. In the previous example, �A circle is <br/>
a shape.� This type equivalence via inheritance is one of the fundamental gateways in <br/>
understanding the meaning of object-oriented programming. <br/>
Since both the base class and derived class have the same fundamental interface, there must <br/>
be some implementation to go along with that interface. That is, there must be some code to <br/>
execute when an object receives a particular message. If you simply inherit a class and don�t <br/>
22 Venkata Pilaka Venkata Pilaka <br/>
Comments
Post a Comment