Using “Base” in a Class Name

Question

Is it acceptable to use the word 'Base' in a class name which is a the bottom of the inheritance tree?

I have always found this a bit of a cop-out, just wondering if anyone agrees with me.

For example, if I am refactoring certain elements from MyClassA and MyClassB into a common base class, I'd be tempted to create a MyBaseClass from which the two inherit.

But what happens if I ever need to refactor MyBaseClass? MyBaseBaseClass? Now that's just silly.

I know that Rocky Lhotka doesn't mind with his CSLA framework, but I'm always uneasy about 'definites' in programming.

Thoughts?

Let me clarify why I'm even worrying about this.

I have two namespaces - MySpecificNamespace and MyCommonNamespace. MyNamespace uses MyCommonNamespace, as you might expect.

Now, I like to make maximum use of Namespaces wherever possible to describe the context of the problem, and avoid adding the context to the class name. So, for example, consider that I have a class in MyNamespace which descends from one in MyCommonNamespace.

Option A

I could call this

MySpecificClass: MyClass
{
}

But then I'm adding 'Specific' (the context) to the name - which is redundant as it's already in MySpecificNamespace.

Option B

MyClass: MyCommonNamespace.MyClass
{
}

You can see how we could get confused here, right?

Option C

The one I think is fishy:

MyClass: MyBaseClass
{
}

Answer 1

I think it should probably be avoided where possible in favour of an identifier that actually describes what it is!

This question is difficult to answer because it's abstract. I might, for example, consider calling the base of MyClassA and MyClassB, "MyClass".

Answer 2

I agree, AbstractFoo is a decent solution. I try to pick names that don't need additional adjectives. I would shy away from using Base.

Answer 3

Classes that have the same name as their parent classes bug me to no end. In Java java.sql.Date extends java.util.Date. This is very annoying because you have to specify the exact class you want to import or else specify the classname fully (including package/namespace).

Personally I prefer to name things as they are; if a Base or Abstract class exists only to provide a partial implementation of something, and doesn't represent the interface for that thing, it is often acceptable to put the word Abstract or Base in its name. However, if that class represents the interface as well, then you should just name it after what it does.

For example, in Java, we have the Connection interface (for DB connections). It's just called Connection, not IConnection. You use it like this:

Connection con = getConnectionFromSomewhere();

If you are making a JDBC driver and need to implement connection, you could have a ConnectionBase or AbstractConnection which is the lower layer of the implementation detail of your particular Connection. You might have

abstract class AbstractConnection implements Connection

class OracleConnection extends AbstractConnection

or something like that. The clients of your code, however, never see AbstractConnection nor do they see OracleConnection, they only see Connection.

So, in general, classes that are meant to be generally useful should be named after what they represent/do, whereas classes that are helpers for code maintenance/organization can be named after what they are.

*ps I hate naming Interfaces with I. Do people name all their classes with C? It's 2009! your IDE can tell you what type of object that is, in the odd case when it even matters if it's an interface or a class.

Answer 4

I think it's worth wiki-fying this question.

FWIW, I agree. I usually try to find a more "generic" term for my base classes. So if I have a "Customer" class and need to introduce a new base class for it, I'd go with "Contact" or something rather than "CustomerBase".

Answer 5

"All your BaseClass are belong to us."

I side with a definitive no, with a single exception. If you are writing an app to manage military installations or baseball stadiums, go for it.

Answer 6

I also side with the no camp...place a Base in there today and in 6 months someone will whack a MyDerivedClass class in you code base while you're not looking.