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.

Answer 2

You generally see a lot of these terms thrown around, but there aren't any official standards on that. I would actually say that some of these are bad practices. A lot of times "helper" and "manager" classes are classes that do too much and are a catch all for behavior that should be elsewhere.

Answer 3

To be honest, I am not sure what you mean by most of these terms. If you are talking about design patterns then I believe the Gang of Four book ( Design Patterns ) has diagrams of each of the patterns that they use. If you are talking about something else, you might be overcomplicating things.

Also, where would you expect to get an "official" definition on terms that are not themselves official?

Answer 4

I don't think you'll find "official" definitions of these terms because they mean different things to different people. Names can be hard because while they are ultimately arbitrary, having a name that precisely and succinctly describe a class' role is a good goal to have. The GoF Design Patterns book is a good suggestion. You might also want to check out Core J2EE Patterns if you want something more Java-centric.

Answer 5

从我所看到的，项目的包布局更加依赖于代码的功能，而不是它的类型（即java.awt.image，java.awt.font而不是java.awt.utils， java.awt.singletons）。

Answer 6

There really isn't a standard for naming packages and deciding what types of classes live in those packages. It's all based on your preferences and what makes sense to you. Although in a group environment package naming and what types of classes belong in each package would typically be decided during design meetings where the group can reach a decision pretty much by consensuses. Or you could just work for a control freak that what things done their way or no way and they decide for you.

Answer 7

I think any class called a FooManager is at best questionable design in an OO system. They tend to be places were tons of state and lots of global variables are kept.