I just ran into an "interesting problem", which I would like your opinion about:

I am developing a system and for many reasons (meaning: abstraction, technology independence, etc) we create our own types for exchanging information.

For instance: if there is a method which is called SendEmail and is invoked by the business logic, it way have a parameter of type OurCompany.EMailMessage, which is an object which is completely technology independent and contains only "business relevant data" (for instance, no information abut head encoding).

Inside the SendEmail function, we get this information from our EMailMEssage object and create a MailMessage (this one is technolgy specific) object so it can be sent over the network.

As you can already notice, our class has a very similar name to the "native" language class. The problem is: this is exactly what they are, email messages, so it is hard to find another meaningful name for them.

Do you have this problem often? How do you manage it?

Edit: @mgkrebbs just commented about using fully qualified names. This is our current approach, but a little bit too verbose, IMHO. I would like something cleaner, if possible.

  • 2
    Always using qualification seems a workable solution, if a bit verbose. Use OurCompany.EMailMessage for one type and SendEmailClass.EMailMessage (or whatever) for the other. Is there some problem with taking this approach? – mgkrebbs Nov 24 '11 at 19:37
  • Yes, I thought about it, but it gets verbose. I would like something "cleaner", but the solution you proposed is my current one. I will add this to the explanation – JSBach Nov 24 '11 at 19:38
  • 3
    Names come in a context. Usually a namespace or something like that. So it shouldn't be a problem. – deadalnix Nov 24 '11 at 19:57
  • +1, I like this question. I once asked this question to an instructor about 7 years ago, and he thought I am a complete "...." :) – NoChance Nov 24 '11 at 20:51
  • What language are you using? The answer is language-specific. In general the answer is 'use a namespace'. In a single Java application it is quite common to have the same class name used by half a dozen libraries. – kevin cline Nov 24 '11 at 22:40

This is a problem about the namespace you are going to use for your project.

Basically a namespace is the collection of the keywords provided by all your classes and/or all the classes you want to use in your project ( including the standard classes usually provided with the language/compiler/IDE ).

Since a namespace is a collection, some basically rules are applied to prevent the making of a mess of terms without any related behaviour, and some languages like the C# also allows you to define your own namespace as usually and also use it in other classes.

Do not confuse the namespace with the basic keyword of the language, they are both a collection of keywords but with a big difference between the two: you can modify a namespace but you usally can't modify the basic keywords of a language. The sum between the namespace you have used in your project and the basic keywords of the language you use gives you the total amount of keywords.

The topic is heavily discussed on the net, i can suggest a basic search with the terms "namespace [your language]" o something like that. I'm not directly answering your question simply because you can have different approach for different languages.

| improve this answer | |

Well my old development team use to append the acronym of the application in each customized class. We had for example ABCEmail class.

I think it is more straightforward than relying on namespace but can be also a complementary solution to the usage of the namespace.

Last but not least, since you are creating a new object, it means that the native object does not answer your needs so your name of your Email File could be CustomizedEmail, AdvancedEmail ...etc

| improve this answer | |
  • 1
    Agreed to your final point, but why would OAEmail be better than OurApplication.Email? OAEMail has impact on every part of the software, while the namespace notation only has an impact there where the conversion occurs and both classes are used in the same source file. – Steven Jeuris Nov 24 '11 at 23:29
  • 1
    I think the prefix is a good idea when your language does not support namespaces. But if the language supports some form on namespacing then use it (this is the problem namespaces were designed to solve!).` – Martin York Nov 25 '11 at 0:52
  • @Steven Jeuris: The name of the class should be selected once it is created. Afterwards, I find it as a bad practice to change it ... because of all the unnecessary impacts. – Amine Nov 25 '11 at 12:23
  • @Loki Astari: i do not know which IDE you are using but I find that a different class name is easier to handle when searching or opening a given class. I saw projects having a customized version of "email" and each time I wanted to open the file I had to browse across several namespace. Your point is still valid I guess it is subjective to the package organization how many customized classes are going to be created. – Amine Nov 25 '11 at 12:27
  • 1
    @Amine: I didn't realize you are actually arguing against namespaces. I suggest you read about namespaces some more to see all the advantages of using them: encapsulation, eliminating ambiguity, less redundancy, ... P.s.: Most modern IDEs have search features which allow you to quickly find a source file without having to browse through the hierarchy. As to your comment to me: constant refactoring is part of software development. When you can come up with a more suitable name, big impact or not, you should consider renaming it. It's best however to discuss this with colleagues first. – Steven Jeuris Nov 25 '11 at 12:33

What language are you using? The answer is language-specific. In general the answer is 'use namespaces'. I would almost never mangle the type name to avoid a conflict with some external namespace.

In a single Java application it is quite common to have the same class name (e.g. "Date") defined in half a dozen namespaces. If one class needs to use two separate Date classes, then one of the Date classes has to be fully qualified everywhere it appears, as Java does not support type aliases. In C++ life is easier; you can just rename one of them with a typedef.

| improve this answer | |
  • I was about to post a similar answer, but instead of the C++ alias example wanted to mention C#'s using alias directive. – Steven Jeuris Nov 24 '11 at 23:08
  • @Steven: I was going to mention C# instead of C++, but it's been a few years since I have programmed in C#, and wasn't sure. – kevin cline Nov 25 '11 at 4:30

Do you have this problem often? How do you manage it?

It really depends on the language you use. In c++ and java, this problem is solved by using namespaces. I am using c++, and it happens that I got different classes with the same name. It's not a problem, since they are in different namespaces.

In other languages, there are no ways around but providing different names.

| improve this answer | |
  • For the computer it is not a problem, but for the developer it might be, since you've got EmailMessage and MailMessage, for instance. – JSBach Nov 24 '11 at 19:49
  • @Oscar Obviously. For computer it can be xyz123 and it still work the same. I do not see other way then going verbose (you said in the comments that you are trying to avoid it). – BЈовић Nov 24 '11 at 19:56

Your question is very good. How about if you prefix your method with a prefix such as U (or u) or cls (short for class)? For examples:

clsEMailMEssage or uEMailMEssage

This does not require a lot of typing and you could immediately tell that the type is 'yours'.

Edit - In response of the first 2 comments:

I would like to point the reader's attention to the fact that: Not all Hungarian notations are created equal. We should distinguish between System Hungarian and Apps Hungarian, I assume that the suggestion above follows the Apps Hungarian type, which is not harmful.

The harm associated with System Hungarian notation such as in naming an ID an intID is not present in the above suggestion.

For more on this, have a look at: Making Wrong Code Look Wrong - Joel On Software

| improve this answer | |
  • 3
    Every time someone recommends hungarian notation, God kills a kitten. – Konamiman Nov 24 '11 at 21:43
  • 2
    The BIgHUmpCAmelCAsing doesn't help either. – Steven Jeuris Nov 24 '11 at 23:10
  • Comments above are appreciated. Pls see my edits, although I know some of us won't change their mind, after all who wants a kitten to be killed? :) – NoChance Nov 25 '11 at 5:59
  • I removed the down vote now that you added some valid reasoning. However, I do not agree that Apps Hungarian is more appropriate than namepaces in this scenario. When the language supports aliases, that's a far more suitable solution. See kevin cline's answer. – Steven Jeuris Nov 25 '11 at 8:24
  • @Steven Jeuris, thanks for your comment. Namespaces are perfect except that they are kind of long to keep typing, I will check the link you have provided. – NoChance Nov 25 '11 at 15:55

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