Abstract/Base Class Best Practices - Help

[D Witherspoon]

Coming up with a scenario here. For example there is the standard .NET
MailMessage class.

I am creating a project (let's call it CommonBase) that has the following 2
classes

EmailMessage_Base ([Public MustInherit] inherits System.Net.Mail.MailMessage
and provides additional methods and properties)
EmailMessage_Abstract ([Public MustInherit] inherits EmailMessage_Base and
adds some business logic including what default return addresses are and
default SMTP server name is)

We are divided in the organization as to where this "business logic" should
be. I say it makes sense to have it in the abstract class. If it is in the
base class then the abstract class really has no purpose.


This project will be compiled and sent out to all of our offices so the
developers in each office can develop their applications using our
CommonBase. However there will be a second project that references
CommonBase. This project will be modifiable (source code will be available)
and have the following class:

EmailMessage ([Public] inherits CommonBase.EmailMessage_Abstract).

The other offices will have control over the source code in this second
project (called Common) so they can chose to override any of the methods in
CommonBase.EmailMessage_Abstract if they need to do so to suit their
business needs. For example they might want to get the SMTP server name
from a different place in the registry or perhaps pull it from a web service
or resource file.

Is this the best approach? Would an Implemented Interface work better? If
we were to use an implementation we would not be able to inherit
System.Net.Mail.MailMessage as far as I know. Also... I'd like to know if
it is possible to prevent users from Inheriting EmailMessage_Base and only
allow them to Inherit EmailMessage_Abstract. I don't think this is possible
but welcome any suggestions.

Any other comments are welcome, if you wish to comment on naming
conventions, structure, or provide web resources, or anything at all.

Thanks..

D

 

[Kevin Spencer]

First, don't cross-post. It makes people cross, and cross people don't help
as often as happy people. Since you need help, cross-posting is
cross-purpose.

There are a couple of basic difference between abstract classes and
interfaces, and understanding them is the key to using them effectively.

An interface is used to define a common programming interface which client
applications can use without knowing the specific type of a class. The
interface defines the types and signatures of members, which are known to
any client that wants to use that interface. It contains no code; the code
and logic are determined by the implementation in a class.

An abstract class is similar in that it contains members which are abstract.
These members do not have any code in them, only type and signature. The
business logic for these members must be defined by the derived classes.
However, in addition, an abstract class may have members which are not
abstract, which are defined. These members are common to all derived
classes, and may be treated just like any other members of a base class.

So, you use an abstract base class whenever you will have code that is
intended to be used commonly among the descendants of a class, along with
members that each derived class must provide an implementation for. If there
is no common code, and each descendant must implement the methods and
properties for itself, you use an interface. And if there are no members
that must be defined by derived classes, you use a "regular" class.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

Coming up with a scenario here. For example there is the standard .NET
MailMessage class.

I am creating a project (let's call it CommonBase) that has the following
2 classes

EmailMessage_Base ([Public MustInherit] inherits
System.Net.Mail.MailMessage and provides additional methods and
properties)
EmailMessage_Abstract ([Public MustInherit] inherits EmailMessage_Base and
adds some business logic including what default return addresses are and
default SMTP server name is)

We are divided in the organization as to where this "business logic"
should be. I say it makes sense to have it in the abstract class. If it
is in the base class then the abstract class really has no purpose.


This project will be compiled and sent out to all of our offices so the
developers in each office can develop their applications using our
CommonBase. However there will be a second project that references
CommonBase. This project will be modifiable (source code will be
available) and have the following class:

EmailMessage ([Public] inherits CommonBase.EmailMessage_Abstract).

The other offices will have control over the source code in this second
project (called Common) so they can chose to override any of the methods
in CommonBase.EmailMessage_Abstract if they need to do so to suit their
business needs. For example they might want to get the SMTP server name
from a different place in the registry or perhaps pull it from a web
service or resource file.

Is this the best approach? Would an Implemented Interface work better?
If we were to use an implementation we would not be able to inherit
System.Net.Mail.MailMessage as far as I know. Also... I'd like to know if
it is possible to prevent users from Inheriting EmailMessage_Base and only
allow them to Inherit EmailMessage_Abstract. I don't think this is
possible but welcome any suggestions.

Any other comments are welcome, if you wish to comment on naming
conventions, structure, or provide web resources, or anything at all.

Thanks..

D