Abstract classes area like interfaces. You can provide the definition of a funtion/method/property and OBLIGATE to implement this in a derived class..

For example, if you want create a backup solution, but need backup not only normal files, but also Sql Server databases, Outlook configurations, etc.. you can:

TAbstractBackup
Name:String
Directory:String
Date:DateTime
Prepare() Abstract
CanBackup:Boolean Abstract
DoBackup Abstract
CreateFileName
oZip.FileName=Directory+"\"+Name+" "+TRANSFORM(Date)+".zip"
oZip.Create
End

TFileBackup
File:String
CanBackup
RETURN Directory(JustPath(this.File)) //check if the dir exist...
Prepare
'Nothing
DoBackup
CreateFileName
oZip.AddFile(this.File)
End

TDBSqlBackup
Server:String
DBName:String
UserName:String
Password:String
FFileBak:String
CanBacup
return oCon.Open("here the connection string")
Prepare
'Run the backup in Sql Server a store the .BAK File path
FFileBack=...
'Optional Shinrk the database
DoBackup
CreateFileName
oZip.AddFile(this.FFileBak)
DELETE FILE (this.FFileBak) //not bloat the harddisk!
oCon.Close()
End
NOTE: Not real code here!

So, you can see that backup a file is a diferent thing that backup a database. So, is impractical provide a base code for example to DoBackup because you need perform a complete diferent process for a file and to a database, BUT you need force that DoBackup have implementation code, and in this way, you know that TAbstractBackup NEVER must be instantiate (i think that VFP not enforce this, but Delphi & others yes). This is also the idea with a interface, but a Abstract Class can provide base code if need them (but a interface not have never implementation code). In this way, with a factory pattern and maybe a interface you not need worry if a object to backup is a file or something like, your simply do:

For i=1 To oBackupsItem.Count
oBackupsItem(i).DoBackup