views:

259

answers:

7

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"
+2  A: 

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?

danben
Thank you I will take a look at it. I think you are right and that I should find a better understanding of design patterns before considering anything else.
Steve
Another resource, as I commented on another answer, is PEAA (Patterns of Enterprise Architecture). Also Domain Driven Design by Eric Evans. These resources explain proven architectural approaches, and class naming is usually based on the names of the patterns being employed.
gWiz
+4  A: 

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.

Jeff Storey
I am really agree with that. It does seem like most people use helper because they don't know where the correct functionality should be placed.
Steve
It's not necessarily wrong to write procedural code. It's just that it has well known issues when scaled.
Tom Hawtin - tackline
I love when you see things like "ApplicationManager" and a class description of "Manages the application."
Jeff Storey
Hahaha, it is good to see that I am not the only one who keeps seeing ridiculous classes
Steve
The best recurring names are the ones based on shared knowledge. To me, this would be names based on design patterns. See GoF and PEAA. Also different frameworks have different naming conventions. For .NET, these are well documented in Framework Design Guidelines by Cwalina and Abrams. Not sure about Java.
gWiz
A common vocabulary and terminology is essential for programmers.
Jeff Storey
There is a common sentiment that using Helpers/Utilities helps in generating reusable code but often I think the real point is to reduce repeated code at the same time as separating more complex (and delicate - easy to break with an extra keypress here or there) *data preparation sequences before API calls* out to infrequently changing files where they can be frozen, tested, versioned and made into known quantities more easily.
martinr
A: 

From what I have seen, the package layout of the project is more goverened by the functionality of the code, not which type of class it is (i.e java.awt.image, java.awt.font instead of java.awt.utils, java.awt.singletons).

disown
That isn't what he asked about, though.
danben
I believe he did. I might have interpreted it wrong, but the OP asked 'how to name classes and packages' and 'how to layout a project'
disown
Sorry if I was vague, I only brought up packaging and layout to give context to my question. I wasn't really curious about overall layout (such as MVC or other patterns)
Steve
+1  A: 

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.

Erich Douglass
+3  A: 

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.

martinr
+1 because GoF gives us a decent vocabulary, although IMHO manager and helper are vice versa which may be a problem of vocabulary ;-)
stacker
A: 

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.

jonsinfinity
A: 

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.

fishtoprecords