Java architecture coding conventions

Question

I have been working at a few different companies now and every one has different rules about how to name classes and packages. They each have different package layouts and workflow between classes. Through these experiences I have picked up an understanding of how to layout out a project; however, I would like a more concrete definition of how to layout a project. This question is more about uml than about naming conventions.

What I am curious is what are the official architecture definitions regarding the following (I have seen helpers used as utilities and managers used as helpers etc).

• "class" helper
• "class" utility
• "class" factory
• "class" manager
• simple "class"
• default "class"
• my "class"

Answer 1

To me:

• A Helper is a facade, or it codes/decodes a particular data format and does not have state between calls.

• A Utility is for coding/decoding a format or doing IO, and if it creates connections often does not maintain connections or keep files open between calls.

• A Manager is like a Helper but does have state between calls.

• A Factory is a class that gets or creates and then returns an object (either a custom one or an API one).

• Simple and Default often simply mean base class.

• A My "class" tends to be for pre-flighting ideas and code examples, though it is sometimes used in production code eg for MyApplication and MyView (essentially to name singletons).

These class names are de facto. These are meanings I create and see most often, but contradictory naming schemes and inconsistencies are often seen. They are not formal design pattern names and in practice the choice of any of these names seems to be almost arbitrary. Some people brand all their classes that are thread-safe with one of these names and those that are not with another of them.

Often too I see a "Manager" name is given to a class that does an ORM like function with objects or keys, or to an object that arbitrates connections.

EDIT

I see an app that's built on a framework as usually having these main objects:

• Official process entry/exit/events handling stub
• A (singleton) application object (references a hierarchical data model and perhaps task objects)
• A database manager
• A network manager
• A UI (that references or doesn't reference a view model depending on your religious persuasion)
• Helper/Utility/Factory classes
• Miscellaneous glue code
• Ancillary files

I see focussing on maximising the testability and minimising the surface area of these interfaces as more important than package naming and file naming; I think you should follow your own nose for the detailed breakdowns and naming for your project. The splitting of code into different files for SCM purposes is specially important for shared files depended on by more than one bullet above.

EDIT

I use singleton, flyweight, composite, iterator, memento, observer, state, strategy as a matter of routine. I use facade, proxy, chain of responsibility between modules and in UI code. I occasionally use factory, prototype and builder in complex data systems, and template and visitor when a system is particularly complex conceptually. I occasionally use adapter, bridge, factory, abstract factory, decorator when behaviour is complex. I rarely use Interpreter and I use mediator to help me write more general code in certain cases. I don't personally like to name my classes after GoF but lots of people are very happy to, it can be a good idea and I am not against the practice. It can be very useful and if it makes people happy and it does help make clear to everyone what is going on in a particular instance then that's great.

I just feel that calling my app object a Singleton, Composite or ChainOfResponsibilityLink (?) does not feel good, and that calling my network and database code Adapters does not feel good so I call them Managers. And I call a lot of things that ought to perhaps be called Facades under GoF, Helpers or Utilities because I think it is clearer what is meant.