Java Fundamentals

Overloading Methods

Angie Jones

Angie Jones

Java Champion
Java Fundamentals

Check out a free preview of the full Java Fundamentals course

The "Overloading Methods" Lesson is part of the full, Java Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Angie walks through overloading methods that were inherited from a superclass. Student questions regarding whether constructors need to be set to public and whether there are any differences between overloading inherited and non-inherited methods are also covered in this segment.


Transcript from the "Overloading Methods" Lesson

>> All right, great. Now I wanna talk about overloading methods that we've inherited. So we talked about overloading before. As a refresher, overloading is where you have multiple methods within the same class that have the same name, but different parameter lists, right? Okay, so now that we're talking about inhebitance, our scope has grown.

So you can have overloaded methods that are not in the same class, but are between a parent class and a superclass. So say, for example, if I'm a subclass, and I've inherited a method from my superclass, and I want to overload that method. Then that means my superclass has a method named x, and I, the subclass, have a method name x, right?

I can overload that, I would need to do a different signature. Otherwise, there would be a conflict, or I would be overriding the one that's from my parent, okay? So let's go ahead and update the Rectangle and Square classes to demonstrate how we might overload a method.
>> So it's an override if you're just changing the parameters or changing one specific thing?

It's an overload if you're changing the signature altogether?
>> No, override, if you keep the signature exactly the same, even the parameters, and you're only changing the body of the method. And then overload is when you change the signature, you have a totally new method. It has the same name, but the signature list is different, and hopefully the body is different as well.

Okay, so we're gonna create a print method in a superclass, we'll overload that in the subclass. So let's go to Square. And in Square, we will, Add a print method. So we have this override, but now we're gonna do an overload. So we'll say public void print, and, This one will take a string.

I'm sorry, I wanna start with the Rectangle, since that's the parent. All right, so let's go ahead and make a print in Rectangle first. This one won't take any arguments, and we'll just print out, I am a rectangle. And then in the subclass Square, we'll also have a print method.

So this one will take a string. So we have a method in the super called print, takes no arguments. We have a method in the subclass that's called print, it takes a string. So that's how you've overloaded those. And we'll go ahead and just print out, I am a, and then whatever it is that they passed in.

Okay, after you type this, we'll go ahead and look in inheritance tester and test it out. Ready, okay, in inheritance, we are going to create a Rectangle, let's say Rectangle, And we'll say rectangle.print. So notice I only have one print method available on the Rectangle object, because that is the superclass, yes?

And then if I were to say square.print, notice I have two print methods here. The one that I inherited from my parent that takes nothing, and the one that I've explicitly defined myself that takes a string. So we'll call this one, and we'll say square. Okay, and let's go ahead and print out, we'll print the Rectangle one first.

So yep, shows that I'm a rectangle, and then the square one, sorry, shows that I am a square.
>> So the constructor always needs to be public?
>> Good question, so the constructor needs to be accessible, so it doesn't have to be public per se. But if it's a class that's within the same package that's inherited from it, then it needs to have access, so it could be public or protected.

If it were private, then the inherited class would not be able to see it, and therefore wouldn't be able to call it. So if you think about the purpose of a constructor, again, it's to set up some initial state for an object. So there's only certain unique cases where it even makes sense to have a private constructor.

It's where you wanna maybe expose a different constructor to anyone who's using the class. And then you call into your private constructor yourself to do additional setup or something like that. Any other questions on overloading?
>> So we're overloading methods that happen to be on our parent class?

But there isn't anything inherently different about this overloading versus overloading methods that were on the same class.
>> Right, very good, it's just the scope is broader now, that's it. Whereas before we would have had the other print right here in the same class that you can see.

So it's kinda invisible, but it's still there in the scope.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now