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
WordXml

AspAutocadCDot netExcelFox proHtmlJava
LinuxMathcadPhotoshopPhpSqlVisual studioWindowsXml

Overriding vs

java

+ Font mai mare | - Font mai mic



DOCUMENTE SIMILARE

Trimite pe Messenger
You manipulate objects with handles
Network And Sockets
Blocking: Becoming blocked
Constructors and polymorphism - Order of constructor calls
Your first Java program
Introduction to Seam
Sorting
Common pitfalls when using operators
String operator +
Color, Font, Images, And Shapes


Overriding vs. overloading

Letís take a different look at the first example in this chapter. In the following program, the interface of the method play( ) is changed in the process of overriding it, which means that you havenít overridden the method, but instead overloaded it. The compiler allows you to overload methods so it gives no complaint. But the behavior is probably not what you want. Hereís the example:




//: WindError.java

// Accidentally changing the interface

class NoteX

class InstrumentX

}

class WindX extends InstrumentX

}

public class WindError

public static void main(String[] args)

} ///:~

Thereís another confusing aspect thrown in here. In InstrumentX, the play( ) method takes an int that has the identifier NoteX. That is, even though NoteX is a class name, it can also be used as an identifier without complaint. But in WindX, play( ) takes a NoteX handle that has an identifier n. (Although you could even say play(NoteX NoteX) without an error.) Thus it appears that the programmer intended to override play( ) but mistyped the method a bit. The compiler, however, assumed that an overload and not an override was intended. Note that if you follow the standard Java naming convention, the argument identifier would be noteX, which would distinguish it from the class name.



In tune, the InstrumentX i is sent the play( ) message, with one of NoteXís members (MIDDLE_C) as an argument. Since NoteX contains int definitions, this means that the int version of the now-overloaded play( ) method is called, and since that has not been overridden the base-class version is used.

The output is:

InstrumentX.play()

This certainly doesnít appear to be a polymorphic method call. Once you understand whatís happening, you can fix the problem fairly easily, but imagine how difficult it might be to find the bug if itís buried in a program of significant size.






Politica de confidentialitate



DISTRIBUIE DOCUMENTUL

Comentarii


Vizualizari: 459
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 2022 . All rights reserved

Distribuie URL

Adauga cod HTML in site