Good example of abstract class situation

[Justin Dutoit]

Hi folks. To aid in learning, could someone give a practical, reasonably
advanced, example of when an abstract class with a few 'empty' and a few
implemented (some virtual) methods, might be used. I'd like to learn by
creating one and a class that inherits from it, but I'd need a case where an
abstract class fits the situation.

Tks
Justin Dutoit

 

[Angelo[B]]

A very common use of abstract case is the following:

Think about a class that manage a data access to several database. The
classes constructor accept a DNS to connect to the DB. The class
return an object from a set, with the capability to select, insert,
delete and update data on a database (SQL, MySQL, Oracle, ecc..)

Ok, this class will be abstract and the object returned implements
obviously all the methods and property of this class.

The class has a static method that take the DSN parameter and return
an object for the database management.

So you implement an abstract class that according to a specific DSN
string, return a suitable object to manage database interaction. The
programmer do not have to care about what database hosts the data
application.

This is a simple example of the use of abstract classes: define a
model, a template for child classes with the possibility of write down
code inside the classes. This is the difference between interface and
abstract classes, the interface do not allow code writing inside it
own.

In my example the abstract classes contain the definition of all the
method for insert, select, update end delete data + the static method
(with code)that return an object that implements the method suitable
with the database currently in use.

 

[Pavel Minaev]

Hi folks. To aid in learning, could someone give a practical, reasonably
advanced, example of when an abstract class with a few 'empty' and a few
implemented (some virtual) methods, might be used. I'd like to learn by
creating one and a class that inherits from it, but I'd need a case wherean
abstract class fits the situation.

A fairly typical example of that is System.IO.Stream. It doesn't have
Read & Write methods as abstract, but they could be that (the default
implementations just throw NotSupportedException to simplify
implementing read-only or write-only stream). Then some other methods
of the class, such as ReadByte and WriteByte, actually have default
implementations in terms of Read & Write. You could imagine a more
comprehensive Stream class, with functionality of, say, TextReader and
BinaryReader conflated into it - so you'd have stuff like ReadLine/
WriteLine, ReadInt32/WriteInt32 etc, all non-abstract, all implemented
in terms of abstract Read/Write.

 

[Jeff Louie]

Justin... One example that I like to use is a complex sort algorithm,
say a
generic quicksort, where you know how to sort but you don't know enough
about the final class to complete the class. In other words, you must
defer
the final implementation to a more knowledgeable class. So you write an
abstract quicksort class with an abstract Compare(obj1, obj2) method.
The
user of the class simply extends the Sorting class and provides a
concrete
implementation of the Compare method appropriate for the class. The key
here is that methods in the abstract class can call the abstract Compare
method that still needs to be implemented! Multiple concrete classes can
then reuse your quicksort algorithm.

Of course this can also be done with interfaces. So the question becomes
when to use inheritance vs when to use an interface. If you have a well
defined contract that will be implemented by many classes consider using
an
interface. If the contract is evolving, consider using a base class.
Consider
using a base class if you need to include implementation details.

The idea for an abstract class may not come immediately from design, but
something that you recognize when you decide to refactor some code. If
you
see common code being copied and pasted and the classes represent an
IS_A
relationship, it may be time to rewrite the code using an abstract base
class.

Regards,
Jeff

 

[Justin Dutoit]

OK thanks for that gents. How about a good example in an e-commerce
application?

Justin

 

[Peter Morris]

OK thanks for that gents. How about a good example in an e-commerce

application?

A lot of the time you can get classes to implement an interface rather than
having to create an abstract class and override abstract methods in
descendant classes. When it comes to mapping objects to a database, as long
as your persistence framework supports inheritance you are much more likely
to use an abstract class in this area.

Imagine an app that schedules jobs to be run on machines.

Key: [ClassName] (RoleName)

[Machine] -----> 0..* (Jobs) [Job]

The Job class might have something like
01: A description
02: When it was last run
03: How often to run it
04: An abstract "Execute" method

You might then have concrete descendants such as

BackupDatabaseJob
RestoreDatabaseJob
CopyFilesJob
DeleteFilesJob
SendEmailJob

and so on. You could even have a descendant of "Job" named "CompositeJob"
which has a reference back to Job

[CompositeJob] -----> 0..* (ChildJobs) [Job]
public class CompositeJob : Job
{
public override void Execute(Machine machine)
{
foreach(Job currentJob in ChildJobs)
currentJob.Execute(machine);
}
}


For in-memory only objects you could do all of this with interfaces, but
when you introduce object persistence you need to use abstract classes
because (as far as I know) there are no OPF's yet which persist associations
to interfaces.