• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why abstract classes? why not extend base class and override those methods in subclas

 
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Can someone CLEARLY EXPLAIN why abstract classes?
wy not just override the methods of base class?
why interfaces?
Why do we need to make methods abstract, is it because we don't know the implememntation details till the last minute? or is it because of anything else?
I have been in thisfield for 3 years. But now i'm stuck with some basics.
Thanks,
sri
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I know all the differences between abstract classes, interfaces and extending base classes.
i think i know what i'm supposed to be knowing at the developer level. But can someone please explain me this in terms of design perspective??
thanks,
sri
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Abstract classes implement conceptual entities. The canonical example is the 'shape' class. A shape might have some (protected) data members like the location of a shape on a grid. It might even have (public) methods like 'getLocation' and the like. But 'shapes' don't exist by themselves; squares and rectangles and circles do though, and they all satisfy the 'isA' relation, e.g. a circle 'isA' shape and hence are implemented as concrete subclasses of the abstract shape class.
Simply because a shape by itself can't exist, this notion is reflected by the *abstract* base class. For every class you design, ask yourself the question 'can such a thing exist or is it allowed that such a thing may exist?' If the answer is no, you're designing an abstract class.
kind regards
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jos,
Thanks for the reply.
I have a few questions.
1. Not only an abstract class, but also in a true concrete class you find the same question. "Can this class exists all by itself? "-definitely not.
Because a class is not a real world object, meaning ANY CLASS can't exist on its own.
Hence the real world objects are got only when you instantiate these classes.
2. Also, my next question is, why do we need to make a method abstract? Is it because we don't know any details of the behaviour till the last minute?
3. Also why can't we then just write any plain concrete class and over-ride those methods in the subclasses?
4. I see abstract class stands in between a pure concrete class and an interface, can someone elaborate on this?
Thanks,
Sri
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sri Addanki:
1. Not only an abstract class, but also in a true concrete class you find the same question. "Can this class exists all by itself? "-definitely not.
Because a class is not a real world object, meaning ANY CLASS can't exist on its own.


It would probably be appropriate to rephrase the orgiginal question to: "Does it make sense to have a direct instance of this class?"
The main purpose of the abstract keyword for a class is to communicate "if you want to have an instance of this class, use one of the concrete subclasses, please."


2. Also, my next question is, why do we need to make a method abstract? Is it because we don't know any details of the behaviour till the last minute?


I am not entirely sure what you mean by "till the last minute". Making a method abstract is simply saying "this needs to be defined in subclasses."
http://www.xp123.com/wwake/patterns/pat9907.shtml gives a very good example.


3. Also why can't we then just write any plain concrete class and over-ride those methods in the subclasses?


You could, but sometimes you really want *every* subclass to override those methods. Declaring them abstract is a good way communicating (and even enforcing) this.


4. I see abstract class stands in between a pure concrete class and an interface, can someone elaborate on this?


You are right, a purely abstract class is nearly the same as an interface. The only feature interfaces add is multiple inheritance, which isn't available for classes in Java. The designers decided this way because multiple inheritance for non-purely abstract classes would have been much more complicated.
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ilja,
Thanks alot, for elaborating.
I'll look into the url you posted here. In the mean time, my question again is:
Why abstract, and why not just concrete classes?
You can override the concrete parent class methods in derived classes too...
The question you asked:
"Does it make sense to have a direct instance of this class?"...... applies not only for abstract class but also applies for any concrete base class that needs to be subclassed.
What makes a method abstract?
Does using abstract,is to say that definitely these are the methods you should override in the derived classes? and what else makes a method abstract?
thanks,
sri
 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well I'll add my perspective, but it is really just reiterating what the others have said. Consider the Shape class, with Rectangle, and Circle being its sublasses.
We need a member method called getArea(). All Shapes need a getArea() method. All Shapes have an area. So let's define it in the Shape class.
However, a Shape is too abstract. We can't find an area of a Shape. What would we use? (Length x Width)??? (radius squared x 2)??? We don't know how to find the area of a Shape.
But we know that all Shapes DESERVE a method called getArea(). In fact, we want to FORCE all subclasses of Shape to define a getArea() method. We declare a getArea() method in the Shape class and call it abstract. If a class has at least one abstract method then the whole class must be abstract. We must declare the Shape class as an abtract class.
Down in the Rectangle class, which is a subclass of Shape, we MUST supply an implementation for getArea(). Otherwise, having at least one abstract method, makes Rectangle abstract. But we want to instantiate Rectangles. So we implement a getArea() method which returns (length * width).
Same with the Circle class, EXCEPT we implement a getArea() method which returns 2 * Math.PI * radius.
 
Mark Mokris
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I forgot one more point.
Why not just make getArea() a concrete method up in the Shape class?
Then we or somebody else out there, maybe unknown to us, reusing our Shape class, will try to instantiate a Shape. Then they try to call getArea() against a Shape object. Except the getArea() method is empty. It is concrete, and they can call it against a Shape object, but there is no implementation. After all we cannot find the area of a Shape, only a Rectangle or Circle.
This is not what we intended, and only by using abstract classes and abstract methods can we disallow this from happening.
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark,
Thanks for your explanation.
1. You said:
"In fact, we want to FORCE all subclasses of Shape to define a getArea() method."
By this do you mean to say that, to force something happen , we make a method abstract?
This is exactly what i'm asking for?
What do you mean by abstract? Is it just forcing something to happen...that's it? or does it have any other significance??
2. you also said:
" Why not just make getArea() a concrete method up in the Shape class? Then they try to call getArea() against a Shape object. Except the getArea() method is empty...but there is no implementation"
Fine...this could happen in any other concrete base class too, which needs to be subclassed. I can give examples for this.
Please see the same example referred to by ILJA, at this url:
http://www.xp123.com/wwake/patterns/pat9907.shtml
Thanks,
sri
 
Ranch Hand
Posts: 331
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll add my 2 cents as well...

The question you asked:
"Does it make sense to have a direct instance of this class?"...... applies not only for abstract class but also applies for any concrete base class that needs to be subclassed.


A base class that "needs" to be subclassed should be defined as abstract.
Although it is true that you could just override a base class method, there are times when that is not appropriate. If the base class has absolutely no idea of how the method will be implemented in its subclasses, then it doesn't make sense for the base class to provide some kind of "generic" implementation of that method. Or worse yet, declare the method in the base class and then just do nothing, like:

Remember that marking a method as abstract (and therefore the class as abstract), creates a strict contract that all concrete subclasses must abide by or the subclass will not compile. On the other hand, if you do not mark the method/class as abstract, then the compiler will not enforce that the subclass provides an implementation of the method. You as the programmer may "know" that "oh, I need to override this base class method in my subclass", but noone is enforcing that you do, except yourself... I don't recommend that

What makes a method abstract?
Does using abstract,is to say that definitely these are the methods you should override in the derived classes? and what else makes a method abstract?


Syntactically, what makes a method abstract is just using the keyword "abstract" and providing no implementation. And yes, it is just a good way to say that "all concrete subclasses must provide an implementation for this method". Again, if you don't flag it as abstract, then you are not enforcing that the subclasses implement the method.
Here is an example of a use of abstract classes that may help clarify.

In that example, the toString() method uses the getFields() method to get a list of the objects fields so they can be formatted. So if you call MySubclass.toString() it will return a formatted string containing all of its fields/values. That way, you don't have to override the toString() method in each subclass. Instead, each subclass provides access to it's fields via the getFields() method that they must implement. Although not shown here, the getFields() method can also be used in other parts of the code other than in the toString() method.
In recap, I think the important thing to remember is: if you have a class that provides some level of implementation BUT contains some methods (1 or more) that MUST be implemented by a subclass, then declare it as abstract. Whew, I'm done.
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
Thanks alot!!!
I think i got u now.
"if you have a class that provides some level of implementation BUT contains some methods (1 or more) that MUST be implemented by a subclass, then declare it as abstract. "
Yes, thats right, indeed.
Just as a recap, i want to give an anology here.
Say if you have no clue as to who's going to implement your methods, then you write an interface. EX: A VCR, A computer, A DVD, a DECK all can have something in commom and that is they all implement play method. When you say play they can play a cassette, cd or dvd etc. But don't have any common set of things, hence you can't shallow them, but go for interfaces.
And you make a class abstract, when you know that
the implementation classes have some default behaviour, and you know what methods exactly are to be implemented, but you don't know how they are implemented till the run time.
To exemplify this....
Say we need to make a student-courses information system. Say you have ClassRoom class in that.
ClassRoom class has attributes like course id, course name, tutor-in-charge, roomdetails, roomnumber.
In this case we don't know which roomnumber a course can be assigned to till the last minute.
And say there's a method called printCourseDetails, where u need to access this roomnumber field, through getFields() method. Then u make this method abstract and class abstract.right?
Did i get this right here? Is this a good example?or can i think of a better example?
Thanks,
sri
 
Sri Addanki
Ranch Hand
Posts: 195
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is this a good example?
thanks,
sri
 
reply
    Bookmark Topic Watch Topic
  • New Topic