The two previous answers were technically correct, but they don't explain why. Abstract classes allow you to 1) define the interface or "plan", 2) develop your code without having an explicit implementation of the general plan.
So, using the above "Document" example:
public abstract class Document{
protected File fFile;
public Document(File file){
fFile = file;
}
public abstract String getMimeType();
public String getName() {
return fFile.getName();
}
public abstract void open() throws IOException;
public abstract String read() throws IOException;
public abstract String read(int offset, int length) throws IOException;
public abstract void write(String text, int offset, int length) throws IOException;
public abstract void close() throws IOException;
}
Then you write your code only referring to the abstract Document class, never to any of the subclasses:
File file = //get File selection from GUI, config file, whatever...
Document doc = DocumentManager.getDocument(file);
try{
String mimetype = doc.getMimeType();
statusDisplay.setType(mimeType);
doc.open();
docViewer.setText(doc.read());
doc.close();
}catch(IOException ioe){
ioHandler.handle(ioe);
}
Notice that the code makes no reference to any subclasses (e.g. PDFDocument, WordDocument, PlainTextDocument, etc.). Indeed, the code doesn't need to even be aware of any implementations. The DocumentManager would need to decide what subclass to instantiate and then returns it, but the code assigns it to the "higher level" abstraction variable "doc". New implementations can be introduced and only the configuration of DocumentManager need change. Your code doesn't even need recompiling.
Also note that using an Abstract class allows for part of the plan to be implemented, in this case the plan implies that a document exists as a file, and provides the implementation to get the file name. This part is not possible when using interfaces versus abstract classes.
2007-03-05 07:21:40
·
answer #1
·
answered by vincentgl 5
·
0⤊
0⤋
Abstract classes are useful for defining a high level blue print for how a group of classes work and classes that inherit from these abstract classes are left to define how they do their job.
Let's use file types types as an example...
Say we had a class Document. We all know what a Document is, a Document is a file that can be read from, written to, opened, closed, etc. But Document really doesn't mean anything. We don't deal with Documents, we deal with special types of Documents. We need to know specific types of documents. So we could inherit from the Document class with a class like WordDocument or PDFDocument. These are more tangible classes which would inherit from the Document class. We know that WordDocuments can be opened, closed, etc. but they do it their own way. Just like PDFDocuments can be opened, closed, etc, but do it differently than WordDocuments. If we take it a step further, we could really say that an MP3 is a type of document, more or less, since it can be opened, closed, read and written to. But it has special features also, since it can be played on a media player, so we might extend the MP3 class to include methods to playMusic() or something.
Abstract classes make it easier to change things later.
I really hope this helps.
2007-03-05 01:32:49
·
answer #2
·
answered by rowancompsciguy 3
·
0⤊
0⤋
abstract class is one which cannot be instantiated,and used to define interface
e.g. Shape , you can inherit circle and triangle from shape
2007-03-05 01:26:20
·
answer #3
·
answered by Anonymous
·
0⤊
0⤋