Duncan
Duncan

Reputation: 10291

Using "Base" in a Class Name

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
{
}

Upvotes: 32

Views: 14845

Answers (13)

Nathan Chappell
Nathan Chappell

Reputation: 2436

It seems like any principled answer will end up being no... However, comma, when I'm looking at code I'm not particularly familiar with, which happens a lot in python (where the source code is sometimes the only dependable documentation), I find it really helpful when a class has Base in it. Python is different from other OO languages where the class is defined with an "abstract" or "interface" specifier though. For naming, I like to ask myself "if I have never seen this code before, which way would make it easier for me to understand this code?" (Then, depending on how lazy I'm feeling, I name it accordingly).

Upvotes: 0

JohnFx
JohnFx

Reputation: 34909

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

Upvotes: 13

Mr. Shiny and New 安宇
Mr. Shiny and New 安宇

Reputation: 13908

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.

Upvotes: 6

Matthew Olenik
Matthew Olenik

Reputation: 3577

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.

Upvotes: 0

cdmckay
cdmckay

Reputation: 32240

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

Upvotes: 1

starblue
starblue

Reputation: 56772

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.

Upvotes: 2

Anton Gogolev
Anton Gogolev

Reputation: 115751

"Abstract" prefix maybe?

Upvotes: 2

Ali Parr
Ali Parr

Reputation: 4787

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?

Upvotes: 3

annakata
annakata

Reputation: 75824

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
  {
  }
}

Upvotes: 7

Michael Prewecki
Michael Prewecki

Reputation: 2102

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.

Upvotes: 1

Grzenio
Grzenio

Reputation: 36649

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.

Upvotes: 14

Matt Hamilton
Matt Hamilton

Reputation: 204169

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

Upvotes: 4

David Grant
David Grant

Reputation: 14223

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

Upvotes: 0

Related Questions