8

Say I am developing a Calculator application. It has one class called: Calculator. Therefore my namespace structure would look like this:

MyCompany.Calculator.Core.Calculator

Unfortunately, this is not right because the same name should not be used for a namespace and a type in it. This is thoroughly explained in this other SO question. One of the answer to that question suggests to solve the ambiguity by using an Util suffix for the namespace, which would then look like this:

MyCompany.CalculatorUtil.Core.Calculator

This solves the naming ambiguity in the programming language. However, this kind of naming is in contradiction with good DDD naming practices: because Util seems to be a "weasel word" according to this article on naming in the ubiquitous language and these should be avoided.

What is the best way to avoid a conflict here in the case of a Calculator?

The application I am developing is much more complex than a simple calculator, however the principle still stands.

Improve this question
16
  • "I am developing a Calculator application" "The application I am developing is much more complex than a simple calculator." I think you've answered it on your own. Give your namespace a proper name to represent "much more complex than a simple calculator".
    – Neil
    Commented Dec 1, 2017 at 11:16
  • @Neil, the principle still stands to the application I am developing.
    – w0051977
    Commented Dec 1, 2017 at 11:18
  • If you choose some appropriate name, all conflicts can be avoided by the client of your classes, by simply using the full qualified name if necessary.
    – Emerson Cardoso
    Commented Dec 1, 2017 at 11:19
  • 2
    Tell us what other leaf classes there are besides Calculator, and we'll tell you what to call the higher-level package.
    – Kilian Foth
    Commented Dec 1, 2017 at 11:22
  • 1
    You can resolve the namespace problem both in this case and in principle by providing a more comprehensive name to the namespace. No set can contain itself, and the relationship of a class to a namespace should be considered a component of a whole module. Therefore the names shouldn't clash if named properly.
    – Neil
    Commented Dec 1, 2017 at 11:27

2 Answers 2

Reset to default
2

Is the name of your application 'Calculator'? if it is you may find that that name has already been used.

I would also advise you NOT to use myCompany as part of the namespace. I know its a standard way but company names change.

Just have:

MyApplicationsRealName.App
MyApplicationsRealName.LibraryName.ClassName
Improve this answer
6
  • 2
    What if the application's name changes?
    – doubleYou
    Commented Dec 1, 2017 at 16:44
  • of course this can happen, but in my experience it is less likely. Companies get bought, sold and rebranded much more often than they change the name of the products and sometimes a new product name means new code anyway
    – Ewan
    Commented Dec 1, 2017 at 16:47
  • also, its just the one application that you need to deal with. not every bit of code the company has ever written
    – Ewan
    Commented Dec 1, 2017 at 16:50
  • I guess we could argue whether you actually need to change the namespace when the company's name changes, but my question wasn't really serious. I think your suggestion should work fine. Unless, of course, you have an App class - then you're in trouble...
    – doubleYou
    Commented Dec 1, 2017 at 17:01
  • 1
    My bad! I assumed this was the project that produces the executable. Okay, I'm out of objections, fake or otherwise.
    – doubleYou
    Commented Dec 1, 2017 at 17:14
3

Say I am developing a Calculator application. It has one class called: Calculator

What do you think will the class name Calculator stand for? What do expect to find there, just by reading that name? The UI, the domain logic, data, application start code? You cannot tell, this class name is way too ambigous to make sense.

So if I were going to design a Calculator application, there could be an CalculatorDialog class for the UI, a CalculatorController or CalculatorLogic for the domain logic, a CalculatorPresenter or CalculatorViewModel when making an MVP or MVVM architecture, and a CalculatorState if you decide to put the state explictly in some object for persistence. There may be further infrastructure classes like a Program class for the application's entry point. But not a class called Calculator, this name makes only sense at the namespace level, but not at the class level.

This is not restricted to this specific example. A program or library consists always of different parts - so give those parts a name which distinguish them clearly from the program name and makes them distinguishable from other parts, then the problem won't occur.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.