8

I've been programming in Java, C#, Python and AS3 most of the time and in all of these languages there are packages (or something like that). The problem I found is with the naming convention, or even with the organization of the packages. I need someone to tell me WHY is this:

com.company.app.type.Object or org.authorname.project.type.Object

better than this:

app.feature.Object or app.module.Object

Another example:

Why this:

com
 +--company
     +--app
         +--events
         |   |--FeatureOneEventA
         |   |--FeatureOneEventB
         |   |--FeatureOneEventC
         |   |--FeatureTwoEventA
         |   |--FeatureTwoEventB
         |   
         +--models
         |   |--FeatureOne
         |   |--FeatureTwo
         |   
         +--services
             |--FeatureOneServiceA
             |--FeatureTwoServiceA
             |--FeatureTwoServiceB

Is "better" than this:

 company
  +--app
      +--feature
          +--one
          |   |--Model
          |   |
          |   +--events
          |   |   |--EventA
          |   |   |--EventB
          |   |   |--EventC
          |   |
          |   +--services
          |       |--ServiceA
          |  
          +--two
              |--Model
              |
              +--events
              |   |--EventA
              |   |--EventB
              |
              +--services
                  |--ServiceA
                  |--ServiceB

In the first one you have all organized by "types of objects", but the "features" are all mixed, but in the second one, the organization is by "feature" and each one has their own objects; so, you can see one feature well separated from another.

So, can anyone tell me why a lot of companies and programmers prefer the first?

Improve this question
1
  • There is a doubt that it may not be good to duplicate word event in package name and in class name.
    – Zon
    Apr 9, 2019 at 7:34

4 Answers 4

Reset to default
8

The reason to have your reverse domain name as the beginning of a package name is to reduce the possibility of naming conflicts. This is especially important if you are writing a library or a framework. So that explains why "com" and "org" are in there.

Other then that, everyone is different and chooses their package structure differently. One reason option 1 might be better is if there is no real destinction between features or they have a lot of code that crosses over. With that, option 2 might make more sense if features really are mutually exclusive in some manner.

Also, I bet option 1 is generally the way most projects start, and then nobody ever changes it (or cares to) after. I wouldn't be surprised if a lot of companys don't put a lot of thought into their package structure anyway.

Improve this answer
3

From what I've seen, the first is common in Java and its kin (ActionScript, for example). I don't quite know the reason why but I assume it's something to do with avoiding any possible naming clashes.

C# and .NET in general, as well as I believe Python, prefer the second style. In fact, .NET guidelines expressly discourage the Java style and recommend: CompanyName.ApplicationName.ModuleName.LogicalGroup for example Cyberdyne.Skynet.SelfDefense.CyborgActivation

Improve this answer
2

Agree with the others on the package prefix being the company domain.

On the second point, I usually choose package names like you suggest, by feature before by file type (as you wrote, the other policy is often chosen).

Note that technical code (like StringHelper or MenuInterceptor) is not directly a feature, so it doesn't follow the same conventions.

I prefer it because :

  • when working on a feature, you find easily the corresponding code
  • you can make use of the package visibility (intermediate between a private inner class and a really public class).
  • you can launch automatic tests to fully verify a feature (it is what matters to your client ; and it is also what could break when you modify old code)
  • if a project typically have small features with few classes, or many optional classes that are not always needed, subdirectories might not be needed, all classes can be contained in the same package (and let the suffix indicated what role that class plays in the feature).

By the way, I think that several features don't usually share a lot of code. If a code is reusable, it is either:

  • in a different layer (like technical code), so completely elsewhere (maybe not in the same Java project)
  • in a superclass (common code may use packages as features do)
Improve this answer
0

Well the first is by pure convention. In the Java spec, packages are recommended to be named as the reverse of your company's domain name since that would ensure uniqueness. That's the reason Java packages are named that way. C++ and C#, and therefore .NET, follow the namespace convention which has been around for years. I don't think any of these ways are inherently better than any other way, that is just the way the languages evolved.

Improve this answer
1

Your Answer

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

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