Package in object name, why should you do it?
I know this may not be universally agreed upon, but I think it’s something worthy of being discussed and so I decided to explain my reasoning behind it.
Although I started my programming career in ABAP over the years I’ve programmed in Java, C#, Objective-C,etc. In these languages an object has a name, and a fully qualified name:
- Name: Delivery
- Fully Qualified Name: com.sd.litigations.delivery
The benefit of this structure is that the “litigations” team doesn’t have ownership on the usage of the “delivery” word, like a trademark. There can be another object called delivery in another package like “com.sd.whatever”.
In ABAP you have something similar, the custom namespaces, which you may have seen in SAP developments /<application>/ but are rarely used outside SAP (I’ve used this once in a project). Most of the times we all share the Z or Y namespace.
So In my arrogance I create a package called ZLITIGATIONS, go into SE24, and claim the name ZCL_DELIVERY for myself (like I’ve seen people do so many times….). Why should I be encouraged to do this? Is my litigations application more important that some other package? No.
That’s why in my projects we use some sort of package symbol in the class name, like ZLT_DELIVERY. This way someone else can create a DELIVERY object without it feeling like a “second best”, besides making it easier to search for the class with intelisense (in ABAP for Eclipse).
PS: I know some will question why there would be two delivery classes in the first place, but let’s keep that for another discussion. Think of another less widely used object, the same reasoning applies.