Scrigroup - Documente si articole

Username / Parola inexistente      

Home Documente Upload Resurse Alte limbi doc  

AccessAdobe photoshopAlgoritmiAutocadBaze de dateCC sharp
CalculatoareCorel drawDot netExcelFox proFrontpageHardware
HtmlInternetJavaLinuxMatlabMs dosPascal
PhpPower pointRetele calculatoareSqlTutorialsWebdesignWindows

AspAutocadCDot netExcelFox proHtmlJava
LinuxMathcadPhotoshopPhpSqlVisual studioWindowsXml



+ Font mai mare | - Font mai mic


Trimite pe Messenger
Calculation details
Method overloading
Connecting to databases with JDBC
Common pitfalls when using operators
public: interface access
The Component Class
A custom tool library
Your first Java program
Alternatives to action
Collections - Disadvantage: unknown type


In Chapter 6 you saw how an object can be used as its own type or as an object of its base type. Taking an object handle and treating it as the handle of the base type is called upcasting because of the way inheritance trees are drawn with the base class at the top.

You also saw a problem arise, which is embodied in the following: (See page 97 if you have trouble executing this program.)


// Inheritance & upcasting

package c07;

class Note

public static final Note

middleC = new Note(0),

cSharp = new Note(1),

cFlat = new Note(2);

} // Etc.

class Instrument

// Wind objects are instruments

// because they have the same interface:

class Wind extends Instrument

public class Music

public static void main(String[] args)

The method Music.tune( ) accepts an Instrument handle, but also anything derived from Instrument. In main( ), you can see this happening as a Wind handle is passed to tune( ), with no cast necessary. This is acceptable; the interface in Instrument must exist in Wind, because Wind is inherited from Instrument. Upcasting from Wind to Instrument may “narrow” that interface, but it cannot make it anything less than the full interface to Instrument.

Why upcast?

This program might seem strange to you. Why should anyone intentionally forget the type of an object? This is what happens when you upcast, and it seems like it could be much more straightforward if tune( ) simply takes a Wind handle as its argument. This brings up an essential point: If you did that, you’d need to write a new tune( ) for every type of Instrument in your system. Suppose we follow this reasoning and add Stringed and Brass instruments:


// Overloading instead of upcasting

class Note2

public static final Note2

middleC = new Note2(0),

cSharp = new Note2(1),

cFlat = new Note2(2);

} // Etc.

class Instrument2

class Wind2 extends Instrument2

class Stringed2 extends Instrument2

class Brass2 extends Instrument2

public class Music2

public static void tune(Stringed2 i)

public static void tune(Brass2 i)

public static void main(String[] args)

This works, but there’s a major drawback: You must write type-specific methods for each new Instrument2 class you add. This means more programming in the first place, but it also means that if you want to add a new method like tune( ) or a new type of Instrument, you’ve got a lot of work to do. Add the fact that the compiler won’t give you any error messages if you forget to overload one of your methods and the whole process of working with types becomes unmanageable.

Wouldn’t it be much nicer if you could just write a single method that takes the base class as its argument, and not any of the specific derived classes? That is, wouldn’t it be nice if you could forget that there are derived classes, and write your code to talk only to the base class?

That’s exactly what polymorphism allows you to do. However, most programmers (who come from a procedural programming background) have a bit of trouble with the way polymorphism works.

Politica de confidentialitate



Vizualizari: 518
Importanta: rank

Comenteaza documentul:

Te rugam sa te autentifici sau sa iti faci cont pentru a putea comenta

Creaza cont nou

Termeni si conditii de utilizare | Contact
© SCRIGROUP 2021 . All rights reserved

Distribuie URL

Adauga cod HTML in site