What should I do when a class name is very common?

Question

I've just added yet another 3rd-party component to my .net project that contains a class called Client and it got me thinking about common class names.

Do you name your public classes something as common as Client, or do you try to make the name more specific?

In the past I would have said Client was fine, since it can always be accessed explicitly via its namespace (Company.Product.Client) but MS seem to stick to more descriptive class names in the .net framework, such as WebClient, TcpClient and SmtpClient.

I think names like MessagePub.Client look quite neat, and MessagePub.MessagePubClient much less so, but then having lots of Clients floating about also feels quite messy.

All of these 3rd-party components I'm using are actually open source, so is it recommended to refactor and change their class names to something more descriptive to make my code more readable or is accessing via their namespace a better idea? Or does it just not matter? :-)

Answer 1

If your identifiers are disambiguated by namespace, Then I can't imagine you should add more noise. As you said, it feels messy.

If its possible for you to have more than one kind of, say, MessagePub.Client, like one that only wants message digests, or one that is a message adapter for some other interface, then of course you would need to clarify that. Perhaps MessagePub.DefaultClient for the common case, MessagePub.DigestClient for the digest consumer, or MessagePub.LogAdaptorClient for the message adaptor

Answer 2

Well, the more specific the class is a more specifying name it should have - taking into account that it DoesNotGetUnnecessaryLongAndUnhandy.

Of course namespaces are a great method to distiguish namings and add explanatory power to your code. However I wouldn't refactor anything just to have a different naming.

Answer 3

I think a more descriptive name almost always is better. Its not just a technical issue, but certainly also a semantic one : for one thing it obliges you to think what kind of class you're dealing with exactly and helps you to set the boundaries.

Answer 4

The more descriptive name is a much better idea... because you are going to fund someone with using statements like:

using Company.Product;
using SomeOtherThing.Product;

... and if Client appears in both namespaces, you then have some unreadable code.

Common object names like Client, Product, User, Person, Message, etc... I would almost always prefix with some identifier that reflects their greater purpose.

Answer 5

Do you name your public classes something as common as Client, or do you try to make the name more specific?

I try to do two things:

1. No two of my classes have the same name (but I don't care whether any of my class names collide with a 3rd party's: that's what namespaces are for).

2. My classes almost never have the same name as any of the Microsoft System classes (I wouldn't create a class called Dictionary or Form, for example)

Answer 6

Don't forget about the namespace alias quantifier when you have to deal with third-party libraries using similar/identical names:

using Excel = Microsoft.Office.Interop.Excel;
using Word = Microsoft.Office.Interop.Word;

Like that you can distinguish easily between the different classes:

Excel.Application excelApp = new Excel.Application();
Word.Application wordApp = new Word.Application();

Answer 7

"Google is your friend". If the class name your are thinking about using has 361 million hits you can look forward to problems. Also, you may find your class has already been implemented.