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.
Howdy, you might find it easier to remember all the ins and outs of overload vs. override if you think of an overloaded method as just a *completely* different method that just *happens* to have the same name as another one. So overloaded methods don't have to follow ANY of the overriding rules -- overloaded methods can throw new checked exceptions, they can have more restrictive access, and they can go crazy when it comes to return types. As long as that argument list is different, you're free to do whatever else you want because it is a totally new and different method. Be watching for overloaded versions of methods from Object -- try to picture the ways in which you could *think* you are overriding, say, equals() or hashcode(), but in fact you are only overloading it. Keep a sharp eye out for things like that on the exam. Cheers, Kathy author, "Shroedinger's Object" (not in bookstores, however, because we opened the box and, well, it didn't go as we'd hoped)