This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Folks, i've been trying :roll: to get to grips with the concept of overloaded methods, and have been following an example from a book (Sams Teach Yourself Java in 21 Days). Well, thing is, I think I've followed what's been going on, but I have a few queries regarding the code. The code is listed below.
This program starts with a simple class definition for a class called MyRect, which defines a rectangular shape with four instance variables to define the upper-left and lower-right corners of the rectangle x1, y1, x2 and y2. A buildRect() instance method sets the variables to their correct values.
First question:- Why do we need to use the "this" keyword? Afterall, the variables in the method signature take care of which values are to be used, surely?? Next thing - regarding the first overloaded method.
Basically, how does this work?? I mean, the signature bares very little correlation to the standard use of a signature. Is it something to do with the use of the Point object??
Last point - a very silly question really. Why bother having overloaded methods - I mean, couldn't we just change the name of the method we wanted to re-implement?? [ May 06, 2003: Message edited by: Steve Jensen ]
John Bonham was stronger, but Keith Moon was faster.
Why do we need to use the "this" keyword? Afterall, the variables in the method signature take care of which values are to be used, surely?? The buildRect method returns an instance of MyRect so you must either return this or construct a new instance to return. This method would be used from objects of other classes to get an instance of MyRect ordinarily. Basically, how does this work?? I mean, the signatire bares very little correlation to the standard use of a signature. Is it something to do with the use of the Point object?? Yep. Last point - a very silly question really. Why bother having overloaded methods - I mean, couldn't we just change the name of the method we wanted to re-implement?? You could, but method names (as well as variables) should have meaningful names. As a developer, I see a family of buildRect methods with different signatures and instinctively know what they do. This helps to maintain the code. What happens two years from now with your code after you've been promoted to Vice President of Software Development? Some junior programmer is going to have to take care of your legacy and it helps for the code to be readable and meaningful.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
1). We need to use this to indicate that we want to update the member variable, not the local variable. Since the method-local variables hide the member variables, the way to get to the member variables is to use "this." (BTW, I, personally, would not write code like this. My paramters tend to have the indifinate article, so my method would read:
I would still use this to make it explicit to readers. This carries over from my Objective-C days, where you had to use the self variable, and my C++ days where it differentiated between a call to a member method and a call to a C-style method. Some might say that I need to finish my conversion to Java, but I feel that it makes my code more readable. (And since I still code in C++, I prefer to keep my style the same across the two languages.) 2). (you mean "bears," not "bares", right? ) I don't know what you mean by the "standard use of a signature." This looks perfectly normal to me, but then again, I've been doing this for quite the while now. Perhaps you could explain your concept of the "standard use of a signature..." 3). Yes, you could use different names. Early on in my programming experience, I did just that. I soon found that it made refactoring my code a nightmare -- if I changed the variable type that I used in the method call I would have to change the method call. And then I would have to remember all the different method names. It became much simpler just to have one method name that can accept different parameters.
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.