I earlier learned that abstract class can extend concrete class. Though I don\'t see the reason for it from JAVA designers, but it is ok. I also learned that abstract class
This flexibility is especially useful when a system evolves and we don't want to disturb the existing code.
A simple example I could think of is consider a MSDocReader class. This class is part of the legacy system and many other applications depend on this.
Now the requirements change. We have to write classes for reading docx files, ppt and even xsl files.
The MSDocReader class contains methods which can be reused such as getting the size of the file in KBs, onnecting to the .Net framework (If I'm not wrong :-))
Now using this provision, we can write an absract class AbstractMSFileReader which will contain all the methods that are used in the MSDocReader. But this class will have the read method as abstract.
The reason being we want to force the developers to use their own version of read method. (We should not use inheritance as the inheritance clearly states that the subclass method will extend the functionality of the parent method. Reading a doc file and reading a excel file are 2 different things and they do not fall under the same hierarchy. )
And you may argue that the we can make an abstract class and make the MSDocReader class extend that abstract class. But it can happen that the MSDocReader class may be extending some other class and since java does not support multiple inheritance., it can create problems
This becomes useful if I have a set of classes that I want a default implementation of test()
for (so they can extend from Foo
), and a subset of those classes that I want to force to provide their own implementation (in which case making it abstract in the subclass would enforce this.)
Of course, the alternative way in this example would be to declare test()
abstract in the top level class rather than in the subclass, and that's what you'd usually do - but there are cases where satisfying the is-a relationship of inheritance means that it occasionally makes more sense from a design perspective doing it this way around. It's rare, but you do sometimes see it.
As an aside, though a special case, remember that all classes implicitly extend Object
unless otherwise specified. So if you include this case, abstract classes extending concrete classes isn't so unusual after all!
If you make the test
method abstract it forces anyone deriving from the Bar
class provide an implementation of the method.
If you remove the abstract method from the Bar
class then anyone deriving from Bar
would not have to implement the test
method as Foo
already provides an (empty) implementation.
To make the class that extended your class (made abstract) to provide specific type of implementation.
For example:
It is basically to selectively reuse some existing (legacy?) code.
For example: Suppose someone has already created a concrete-class-C (of course the complete implementation).
Now, since you are designing a new system (which has an abstract class-A) and you analyzed the existing system and found that you are going to have some methods that are almost similar to the methods of concrete-class-C. But you also found that some methods of the concrete class-C are too specific and you want to enforce implementation of those methods in the concrete-subclasses of the abstract class-A.
Thus, it enables you selectively choose what methods to re-use and what not to reuse.