doubt in abstract class and methods

[Sivaraman Lakshmanan]

Dear all,
I have a small doubt about abstract classes. anyone pl explain me.
All abstract classes cannot be instantiated. I have an abstract classes which has 2 abstract methods and 2 non-abstract methods. I need the 2 non abstract methods to be invoked. If I could not instantiated the class then how do I access the methods. I cannot even extend the class since I already extended some other class.
This situation I also encountered in most of the Java api's too. but we have a static methods which will give the object of the abstract classes. if this is the case then how can I find the static methods which will give me the object.
I am confused pl help me
thanks in advance,
Sivaraman.L

[intefaq khan]

I Think you got confused a bit,,
Please refet to some Good Java Book Like Java Complete Reference..
Generally Speaking ,,, Abstract classes are kept for the frame works where derived classes or the classes using the same functionality re uses it,..
So you need to see the Design part of it rather then mere implementation of it..
Secondly you do have the Options of Interfaces which you can put to better use,,,
Hope it does clear your some of the Doubts
Regards
INTEFAQ ([e-mail])

[Sadanand Murthy]

 

Originally posted by Sivaraman Lakshmanan:
Dear all,
I have a small doubt about abstract classes. anyone pl explain me.
All abstract classes cannot be instantiated. I have an abstract classes which has 2 abstract methods and 2 non-abstract methods. I need the 2 non abstract methods to be invoked. If I could not instantiated the class then how do I access the methods. I cannot even extend the class since I already extended some other class.
This situation I also encountered in most of the Java api's too. but we have a static methods which will give the object of the abstract classes. if this is the case then how can I find the static methods which will give me the object.
I am confused pl help me
thanks in advance,
Sivaraman.L

Sivaraman,
You need to revisit your design. If you have a situation where you require extending 2 base classes then you will need to convert the abstract class into an interface that contains the 2 methods that your implementing class will provide the implementation for. The 2 methods (those that your current abstract class provides the implementation) should be moved to the base class that you are already extending.

[Sivaraman Lakshmanan]

Dear all,
Thanks for your reply. I have another doubt in this absract methods.
For example if we take the interface java.sql.ResultSetMetaData, we are creating an instance by invoking getMetaData() method of java.sql.ResultSet.
This interface ResultSetMetaData contains all abstarct methods, since it is an interface. If this is the case, when we use this interface for getting the metadata for a particular resultset we don't give any implementaion for these methods but we r actually use it directly.

Resultset rs = stmt.executeQuery("select * from emp");
ResultSetMetaData rsmd = rs.getMetaData();
int colcount = rsmd.getColumnCount(); // we directly use it no method
implemntaion

How is this possible.
When we say abstract methods it means we need to give the implementaion for that method in our class(pl correct me if I am wrong). In the above situation we are not doing that. pl explain
Thanks in advance,
Sivaraman.L

[dennis zined]

Hi Sivaraman. I agree with interfaq and Sadanand. But just an fyi, it is possible to invoke the non-abstract method from an abstract class via an instance of an empty anonymous inner class. see code below.

public abstract class TempClass {
public static void main(String[] args) {
new TempClass(){}.test();
}
public void test(){
System.out.println("test");
}
}

[sever oon]

Hi,
I think you're misunderstanding the concept of abstract. Let's say that you are writing a system that represents shapes, and you want other programmers in the future to be able to add their own shapes for their own little plugins (say it's a drawing program, like Photoshop). So you'll have a rectangle class, a circle class, a trapezoid, etc. If you just implement these shapes as classes, you can't treat them all simply as shapes, and this is a problem because if someone adds a shape in the future your code won't be able to deal with it without you modifying your code.
So, the solution is you create an abstraction. You do this be writing an abstract class called Shape, and have all your shapes extend from it. What is an abstract class? That way, if someone adds an Octagon class in the future, your code won't know or care because it'll only be dealing with Shapes wherever it doesn't need to know about one of your specific shapes.
Ok, so what's this Shape class look like? Well, we COULD make it an interface, but there's lots of stuff we'd have to write over and over again in every class that implements it (this is not the deciding factor, by the way, concerning whether to make things abstract classes or interfaces). So let's start.
First, we need it to keep track of how many sides this shape has. A quick sanity check: a circle has 1 side, rectangles and trapezoids 4...even an irregular, crazy shape has some number of sides at instantiation time. So version one looks like this:

public abstract class Shape
{
private int numSides;
public Shape( int numSides ) {
setNumSides( numSides );
}
public int getNumSides() {
return numSides;
}
private void setNumSides( int ns ) {
numSides = ns;
}
}

Next, all shapes have area, and (say) we want to require that everyone who adds their own shape in the future supports this area functionality. And, just like numSides, why not write the code for them too? Here we go...

public double getArea() {
// ...what goes here? :confused:
}

When we try to write it, we discover that the method of calculating the area is dependent on each different kind of shape, and at the level of the Shape abstraction we don't know what kind of shape this method will be called on (heck, we don't even know what shapes a future programmer will add to the program). So what to do?
Simple, we make it abstract and defer the implementation of this particular method, which is different for each subclass, to those subclasses. But by putting it at this level we ensure that every shape (now and future) must expose its area as a property. So we write instead of the above method:

public abstract double getArea();

Now, think about whether it would ever make any sense to instantiate the Shape class directly? How can your program ever deal with an object of type Shape, but not a more specific *kind* of shape? And how could that thing ever live up to its stated contract by providing you with an area property? Fact is, it can't.
Now let's say that you come along as a programmer later on, and decide you want to provide some new shape to the system in a plugin. It turns out there's some class somewhere that you can extend for your plugin, but you have to hand back to the base system the new shape you're dealing with. Well, you know that the base system could never deal with your shape directly--it doesn't know about your new shape, that's why you have to write a new shape in the first place. Now, let's also say that your plugin itself only cares about one particular aspect of this new shape, let's say that it is a unit shape (of area one), and as far as your plugin is concerned, the user could create a 10-sided shape or a 2-sided shape, your plugin will restrict its area, though, to 1.
You could extend Shape with a UnitAreaShape class if you wanted to, but your plugin doesn't really deal with this thing anywhere as anything but Shape. And no one's ever going to write a plugin for your plugin, so you don't have to worry about extensibility. Instead of cluttering your software with another unnecessary class to maintain, you can create an anonymous class that extends Shape with the properties you want without specifying a class name.
So, let's say your at the point in the code where the user has just input the number of sides this unit area shape should have, and you're ready to have the plugin create it and hand it back to the base system. Here's how you'd do that:

int numSides = // get from user
return new Shape( numSides ) {
public double getArea() { return 1; }
};

Though you didn't say "extend" anywhere, you've now created an anonymous class that does extend Shape, implemented the one abstract method, created an instance of this new subclass (with numSides going up to the constructor of the parent class). You're done.
sev

[Sivaraman Lakshmanan]

dear Sever Oon,
Thanks, ur explaination really made me understand what abstarct classes for. u gave an excellent example to explain this. Thanks a lot again.
sivaraman.L