I am curious what standards people have established for packaging their applications. My understanding is that in the Java world, every thing starts with the TLD within which is the domain, e.g., com.cintegrity for anything I produce. But, that in the .NET world, the TLD is usually omitted, i.e., just cintegrity. While I started with the Java style, I am coming around to the .NET style since the TLD seems to create a meaningless grouping.
Below that level, historically I used a two level system of a module code and then a group of functions. E.g., in non-OO procedure structure, one might have a module code ar with a function group cust which included there standard functions for maintenance, inquiry, and reporting on customers. Short names were used since references were thus something like ar/cust/custmn.p. With the USING keyword, this shortness may be less important.
Applying this to an OO structure, then, we might end up with cintegrity.ar.customer.customer.cls as the name of the core class about customers. UI would be somewhere else, but this same directory might have other classes which were either inherited from this base or which are support classes to which some responsibility has been delegated, e.g., InternalCust.cls and ExternalCust.cls.
When starting to work on some new area, this two level structure might seem too much, but it seems that things often grow and it is better to start with the two level structure than to have to refactor to it when things start getting more complex.
I'm curious what other people's thoughts are in this area.
Guess TLD was the easiest way to get a unique package name, there is no other authority to keep order there so it looks like a good choice for me... while there might not be a 'ro.cintegrity' to colide with but better to be safe.
Can't comment on what 'AR' might be in your case, if it's account receivable I don't see why Customer fals under it but I might be missing the point. Customer.Customer just doesn't look right for me, it has to be some extra packages on top of functional top level... maybe something like, business logic, data access, orm, whatever. And, I also preffer using lower case for packages but camel case for classes/interfaces... you also seems to use that, only not for customer.customer.cls
The risk of ro.cintegrity seems neglible. In practice, I guess I have the same instincts about casing. Yes, AR = accounts receivable ... and what else would the customer belong to?
tamhas wrote:
The risk of ro.cintegrity seems neglible.
LOL, I would say that's probably a safe bet but guess you got the point...
tamhas wrote:
Yes, AR = accounts receivable ... and what else would the customer belong to?
As much as we'll all love to have only clients that feed us in real life we do have to do the same for others, I guess you don't have another 'customer' in AP do you? And don't tell me those a different kind of animals as sometimes the same customer can be found in AR as well as AP.
I am coming around to the .NET style since the TLD seems to create a meaningless grouping.
But as long as you're not camelcasing starting with a capital letter it's your own variation of ".NET style".
Re TLD, for their to be a conflict one has to suppose both that the same domain name is used in two different TLDs, that they are not the same company, and that they are both publishing code for the use of others. Frankly, if I am going to be publishing code and want people to identify me with it, I'm not going to pick a domain name which is already in use in another TLD ... lots of place that is going to be confusing without ever getting to publishing code.
Not sure what your question is... AP has vendors, not customers. Yes, the same company might be both a customer and a vendor ... but if that matters, one going to define companies in some other module and still have customers in AR and vendors in AP which are both parented to a company.
.NET style is my way of referring to with or without the TLD ... not slavish copying of .NET standards.
Do you have an argument in favor of camelcasing package names?
tamhas wrote:
Not sure what your question is... AP has vendors, not customers. Yes, the same company might be both a customer and a vendor ... but if that matters, one going to define companies in some other module and still have customers in AR and vendors in AP which are both parented to a company.
true, but both share more or less the same DNA and you get to use them almost everywhere... almost all ERP starts to add a small CRM module at some point, the idea was that maybe we should not stick to the AR/AP grouping, never was a fun of those two letter anachronisms anyway
Do you have an argument in favor of camelcasing package names?
TheAbilityToReadDescriptiveNames vs. themissingabilitytoreaddescriptivenames
mikefechneresd wrote:
Do you have an argument in favor of camelcasing package names?
TheAbilityToReadDescriptiveNames vs. Themissingabilitytoreaddescriptivenames
hehehe, touchee... however unlike file names one can split packages in sub-packages, didn't had the need to usepackagenamesthatothercanread, so no reason to go and camelcase them (at least not yet)
Err, AR has a very distinct subject matter which is very distinct from the subject matter of AP. The shared information of a potentially common company is very limited compared to the information specific to the application. This is getting off topic, but higher level packages should correspond to subsystems and these seem to me to be quite valid subsystems.
I am a fan of camelcasing myself ... for class names. But, your comparision is not about package names. That is the contrast between
cintegrity.ar.cust.Customer.cls
and
CIntegrity.AR.Cust.Customer.cls
And, of course, with USING, one is rarely going to see the first three pieces.