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.
Not an Advanced question. It's about the basic language.
Originally posted by Akhilesh Trivedi: 1. Is constructor for an abstract class really necessary?
Assuming the abstract class is going to be subclassed by a concrete subclass, then the abstract class constructor is called when the concrete subclass is instantiated. The subclass cannot know how to initialise its superclass, so this makes sense.
For "utility classes", which are declared abstract because they contain only static methods and are not expected to be instantiated, Java's insistence on having a constructor (default or explicit) is a bit annoying. It might have been nice if the language allowed classes to be declared "abstract final" and such classes were excused from having a constructor. Perhaps Java's designers were trying to discourage "utility classes", which aren't good OO design.
Originally posted by Akhilesh Trivedi: 2. Why do we have a via-object-access to invoke methods when we can, and are preferred to do it by class name?
You mean for static methods? As far as I can see, it's just a stupid feature of the language. No good reason. [ October 04, 2006: Message edited by: Peter Chase ]
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Joined: Jun 22, 2005
Thanks peter. I guess you are right, the constructor call on hierarchy would need to go up and up, roots of parent(abstract class) further may be too complex up ahead. Abstract class may itself inherit some members and do its own work out. For the second one, yes i did mean static method. Thanks again.
2. Why do we have a via-object-access to invoke methods when we can, and are preferred to do it by class name?
I am sure you are aware of the fact that there exist two kind of members in a java class 1) Static Members 2) Instance Members
Instance members are associated with an instance/object and hence must always be invoked w.r.t object they are attached to. Static Members however are not associated to any object, they can be thought as Global var/methods. Thus a facility to invoke them with Class name is provided. You can however always invoke a static method/variable w.r.t an instance/object. You will not get an error, though the best way to invoke a static member is former one.
hopefully below link should clarify some of your doubts-
~ Pratibha Malhotra<br /> <br />Sun Certified Java Programmer<br />SCEA 1.4 (In Progress)<br />~~~~~~~~~~~~~~~~~~~~~~~~~~~<br />"Many of life's failures are people who did not realize how close they were to success when they gave up!!"
Joined: Oct 30, 2001
Originally posted by Pratibha Malhotra: You can however always invoke a static method/variable w.r.t an instance/object. You will not get an error
You won't get a compile-time error, but you may not get the run-time behaviour you expected. The method that gets called is chosen based on the compile-time type of the object instance, not its run-time type (which could be a subclass).
Joined: Dec 21, 2003
Couldn't agree more on this with you Peter. The onus of using correct class in hierarchy however lies on the coder. What say
Joined: Jun 22, 2005
Static methods are meant to be invoked by Class name, why not restrict their access by class name alone. I agree with peter for this being an unnecessary feature. Provision of invoking them by instance method would actually not be a facility rather a not-so-necessary thing. And this extra-feature may make things flexible for code-writers, but there are times like static methods can not be overridden (only be hidden) and this feature there does nothing less than consuming code-readers time.