Strategy Pattern - C# Naming convention on Interfaces and AbstractClasses

[Artie]

Our system uses a lot of C# Interfaces for which we'll have classes
named like:

IUser to specify the Interface
and
User to implement it.

I've identified certain cases where I think we should be using
abstract classes rather than interfaces (for cases where there is
functionality that can be implemented in the abstract class).

My question is simply: is there a commonly-used naming convention for
such abstract classes (which are still 'interfaces' from a Strategy
Pattern point of view).

Simply AUser?

Any help much appreciated

Artie

 

[Leon Lambert]

I usually only expose interfaces outside an assembly. These interfaces
typically form a hierarchy. For example a IUser might have two children
called IRemoteUser and ILocalUser. Now my internal implementation of
these interfaces may and probably do have User as a base abstract class
with RemoteUser and LocalUser as children. The main reason i only expose
interfaces is that it give me great flexibility to refactor and enhance
my implementation without breaking any contracts implied to my users by
the public items.

P.S. Only exposing interfaces also makes it very easy to expose your
stuff as a COM component to someone that can only use that technology.

Hope this helps.
Leon Lambert

 

[Artie]

I usually only expose interfaces outside an assembly. These interfaces
typically form a hierarchy. For example a IUser might have two children
called IRemoteUser and ILocalUser. Now my internal implementation of
these interfaces may and probably do have User as a base abstract class
with RemoteUser and LocalUser as children. The main reason i only expose
interfaces is that it give me great flexibility to refactor and enhance
my implementation without breaking any contracts implied to my users by
the public items.

P.S. Only exposing interfaces also makes it very easy to expose your
stuff as a COM component to someone that can only use that technology.

Hope this helps.
Leon Lambert










- Show quoted text -

Thanks for your reply Leon.

I understand well enough the rationale for using 'interfaces', as per
the Strategy Pattern.

It's just the naming I'm curious about.

So you're saying that you prefix abstract classes with an 'I' to
indicate that it's an 'interface' in a Strategy Pattern sense, but not
necessarily in a C# sense?

Artie

 

[Jon Skeet [C# MVP]]

Our system uses a lot of C# Interfaces for which we'll have classes
named like:

IUser to specify the Interface
and
User to implement it.

I've identified certain cases where I think we should be using
abstract classes rather than interfaces (for cases where there is
functionality that can be implemented in the abstract class).

In my experience, abstract base classes are usually suffixed with
"Base" - CollectionBase and DictionaryBase being obvious examples.

Jon

 

[Arne Vajhøj]

Our system uses a lot of C# Interfaces for which we'll have classes
named like:

IUser to specify the Interface
and
User to implement it.

I've identified certain cases where I think we should be using
abstract classes rather than interfaces (for cases where there is
functionality that can be implemented in the abstract class).

My question is simply: is there a commonly-used naming convention for
such abstract classes (which are still 'interfaces' from a Strategy
Pattern point of view).

Simply AUser?

The MS documentation does not prescribe any special naming
convention for this.

Meaning that you can decide your standard and if you document
it and follow it then you should be fine.

Arne

 

[Arne Vajhøj]

I usually only expose interfaces outside an assembly.

The main reason i only expose
interfaces is that it give me great flexibility to refactor and enhance
my implementation without breaking any contracts implied to my users by
the public items.

The benefits of interfaces are common knowledge.

But I am surprised that you do not even have a factory
class in your assemblies.

How do you get to the code ?

Arne

 

[Sergiu DUDNIC]

About "Base" suffix
If I am into a desktop application, and I need to create Custom Controls,
I use the "Base" suffix to identify the "basic" controls by eg. :
TextBoxBase:TextBox
and
TextBoxPIN:TextBoxBase
TextBoxCardNumber:TextBoxBase

in this case, I can't use the "Base" suffix for naming abstract base class,
even in other libraries, in order to respect the "Base" sense as the simple
base class, not a abstract particularry case.

From other hand, you prefix interfaces with "I", cause there are Interfaces
(not classes)
I think will not be correct to prefix te abstract classes with a "A", cause
they remains classes.
In the same manear, you can prefix the "protected"(or public) classes with
"P"

In a lot of cases, the basic abstract classes shoud not br made "public",
and in this case the namig standard may be more "liberal" than a public one.

/sergiu

 

[Jon Skeet [C# MVP]]

About "Base" suffix
If I am into a desktop application, and I need to create Custom Controls,
I use the "Base" suffix to identify the "basic" controls by eg. :
TextBoxBase:TextBox
and
TextBoxPIN:TextBoxBase
TextBoxCardNumber:TextBoxBase

in this case, I can't use the "Base" suffix for naming abstract base class,
even in other libraries, in order to respect the "Base" sense as the simple
base class, not a abstract particularry case.

Well, look at TextBoxBase in both WPF and Windows Forms - it's
abstract.

Ditto MethodBase, CollectionBase, DictionaryBase, ChannelBase etc.

Can you find any *Base classes in the normal framework which *aren't*
abstract? (There may be some - I haven't looked.)