Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community!
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.Start your free trial
Adiv Abramson6,919 Points
If a method signature in a superclass changes, does it automatically propagate through all child classes?
If in a parent class Shape there's a getType() method and some child classes are coded from Shape like Circle, Square, Trapezoid etc. and then the signature of the method changes to getType(boolean displayUpperCase), will that break the application where any child class uses or overrides that method OR if some part of the code calls getType() on an object instantiated from Shape or any of its child classes? Is there automatic refactoring in Java to propagate name changes etc?
When you override a superclass method in a subclass, can you change the method signature or must it be the same as in the superclass? Perhaps I am confusing overloading with overriding? Can you overload an inherited method?
If a subclass overrides a superclass method, can the subclass still invoke the superclass method with a statement like super.parentClassMethod();?
Kevin LozandierCourses Plus Student 53,747 Points
Hi, Adiv Abramson:
Method overloading is a valid thing you can do in Java; Java developers accordingly can be very specific the arity of their methods & the types of the argument each variation of a method name has.
Overriding is for you to change the behavior of an already existing method and a specific signature version of it, requiring you to specify what signature variation of the method you're overriding.
Classes are an important part of Java & super classes are true blueprints of descendent classes as compilers flattens the behavior of super classes to descendents of a class via cleverly created look-up tables for descendents to leverage the already defined methods of their super classes; Develops can alter what look-up tables are made by adding alternate handling of specific methods the super class already defined in their code for specific descendents.
If the method signature you attempt to Override doesn't exist in the first place, the compiler accordingly will throw exceptions because this is more probably than not an unexpected problem: The super class may not be in a state that's relevant for the current developer's needs.
Since Java allows developers to create interfaces, it makes further sense attempting to override a method signature that doesn't exist in the first place is a mistake worth throwing an exception at the very least.
Accordingly, it is possible for descendents of your class to begin breaking. This is alleviated somewhat by versioning your classes through things
serialver but your mileage may vary.