Kaja Fumei

In order to not be abstract, a subclass must define its own version of Feed(). Suppose I made a Shark subclass (poor other fish trying to eat and they get eaten by a shark), and it didn't implement Feed(). This is valid class, but it would be abstract because it didn't implement Feed. And therefore, you could not declare a Shark object. But if you had several Shark subclasses (GreatWhite, HammerHead, etc), and they implemented Feed(), they would not be abstract.

jayme

In other words(easier to understand), an abstract class is used as an outline. You won't use an abstract class to create objects and such, the concrete(derived) classes of the fish(such as sunfish, shark, whale) will be the objects the programmer would create.

__________________
▄▄▄▄

Download Code::Blocks now!
▄▄▄▄

grumpy

Correct jayme, although in this Fish example, it might be more appropriate to say that concrete classes will be particular species of fish. Of course, that depends on what the application is trying to do ..... if there is a valid reason for having a concrete Shark class (as opposed to an abstract Shark and concrete WhitePointer and GreyNurse) then that's a design decision. Most real-world designs involve some form of trade-off like that. It might also be appropriate to have a concrete Shark class if data characterising each shark are being read from some form of database (we wouldn't want the program capability to be limited just because we forgot to create a class for a particular type of shark, even if it can be represented in the database).

And a whale is not a fish