Organizing Apex Classes under Namespace

Question

Is there any way in Salesforce to group apex classes under a package or namespace? Can we use managed package for internal organization purpose?

Havana

My main piece of advice about Salesforce development is DON'T. See #1665003 – Scotsman

Answer 1

This is a limitation in the force.com stack that makes medium-large size projects painful, if not impractical. Using managed packages in order to get a package prefix doesn't really solve any problems, so it's not really worth the trouble.

I usually try to organize a project into one flat level of namespaces. In lieu of actual namespaces, I'll give each would-be-namespace a 3-5 character name, to be used as a prefix. Any class that belongs in the "namespace" gets prefixed. E.g., if I need a payroll namespace, I'd use a PYRL prefix. A class called PaycheckCalculator becomes PYRL_PaycheckCalculator.

The practical advantage of this type of convention is it helps prevent name clashes and classes are grouped by their "namespace" when viewed in a sorted list, such as in an IDE, or Setup > Develop > Apex Classes

Unfortunately, several basic OO principles are still fundamentally broken. Probably the most important one is every class forms an implicit dependency on every other class it has visibility to, which is all of them.

I'd love to hear how others have worked around this limitation.

Kwangju

Same work around... prefixing convention, and I hate it. According to this year's "Meet the Developers" session at Dreamforce, we can soon expect to see a release with features to address this need. – Sinking

Last summer I spoke directly with a high ranking person in the engineering organization about this. There were no plans to add any kind of package/namespace feature. Reason is that very few customers ask for it. – Kwangju

Excellent answer, wish this was on salesforce.stackexchange.com – Herophilus

Answer 2

Well, you can use managed packages, but as Jeremy mentioned it doesn't really buy you much. Of course managed packages are essential for developing publicly listed apps to sell on the AppExchange. But internally it's really an org-wide problem since once you create a managed package with a prefix, everything that touches any other part of it gets stamped with the same namespace prefix, including all custom objects. And worse, you can't access code in a managed package from outside the managed package (which is actually the whole point of them in the first place).

Although it's not the prettiest solution, what I personally do is maintain numerous named orgs with different purposes, applications and utility classes. When I need a utility class in one org, say I'm building a new app destined for the AppExchange, I'll do an Eclipse Export/Import from the utility org in question. It definitely seems strange but having a library of orgs is the best way I've managed to keep track of everything and to manage "internal" organization. But the end result is really just a glorified copy-paste operation between arbitrary code stores.

Britska

"you can't access code in a managed package from outside the managed package". Wouldn't a reference to the installed managed package on the version settings tab for the apex page get round this? Or am I misinterpreting? – Kassi

@DanielBallinger I believe you have to set your code to "Global" in the managed package in order to be visible and referenced outside the package – Crus

Answer 3

I faced similar challenges while working on big projects, wrote this blog post sometime back to share the approach I am following now : http://www.tgerm.com/2011/11/apex-class-naming-convention-suggestion.html

Brianbriana

We like to have information on SO instead of external links that can be broken. – Duffel