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 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 3

I side with "no" for exactly the refactoring reason you've cited.

A class should be named after what it logically represents, and nothing but the Object class is really really Base. Metaphysics ftw :)

---

re: Option B, there is nothing confusing about

namespace MySpecificNamespace
{
  MyClass: MyCommonNamespace.MyClass
  {
  }
}

Answer 4

I tend to add a Base suffix to the name of the base class only if it exists from technical perspective (to share some code), and doesn't really constitute any usable class on its own (so all of these classes are abstract). These are quite rare cases though, and should be avoided just as Helper classes.

Answer 5

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.

Answer 6

I too would suggest No, but not cast in stone...

Following OO mantra, your naming system should best represent the underlying objects that the code is supposed to be encapsulating. There should really be no 'meta language', related to the actual syntactical makeup of the programming language of choice in there.

That said, if your object is truly abstract and you really don't see it changing anytime soon, there is an argument that adding 'Base' helps with general readability.

As with most things, there's no blanket right and wrong answer - it depends on the overall layout of your codebase, what this specific code is supposed to be representing and the in-house style that you have. Just try to be consistent.

Is base used anywhere else?

Answer 7

"Abstract" prefix maybe?

Answer 8

In Java I tend to provide a base implementation of an interface Foo in an abstract class FooBase. I think that is perfectly ok, and makes the connection to the interface very clear and regular.

Without the interface I would call the abstract base class Foo.

Answer 9

I usually go with IFoo for the interface and AbstractFoo for the skeletal implementation, which is a mix of .NET and Java conventions.

Answer 10

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 11

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 12

"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.