views:

121

answers:

3

In my early coding days, I would tend to group classes that functioned in a similar way. For example:

  • Data transfer objects
    • Object A
    • Object B
  • Dialogs
    • Dialog A
    • Dialog B

After a while, it started to frustrate me that when I was working on a particular part of the application, I would have to jump all around to piece it together.

In the last few years, I tend to organize things by feature. Classes that are commonly shared, such as database objects, I still keep together. I think this even makes sense for things like websites:

  • Page A
    • images
    • Resource 1
    • Dialog 1
  • Page B
    • images
    • Resource 2
    • Dialog 2

Is this the best way to do it? Does anyone have a good rule of thumb to follow?

+4  A: 

The 'Package-by-Feature' approach seems sensible and works for me, certainly for Java... how often do you want to pack up your data access layer, vs. that nifty new feature?

I thought the analysis "Package by feature, not layer" at javapractises.com was pretty easy to read, and covered a couple of angles I'd not thought about, like how package by feature works in other domains than programming, too.

Brabster
Thank you! I found that link very helpful!
Jason Young
+8  A: 

For Java, packages are the unit of reuse.

For Python, modules (as well as packages) are the unit(s) of reuse.

The package should be a stand-alone thing.

If you put all data transfer objects into one big package, you don't have something terribly reusable. You might not want all those data transfer object definitions.

If you put things together by "entity" -- the model, the views, the controls, the data access, etc. -- then you have a reusable module that can be shared in other applications.

S.Lott
A: 

You should do it the way other code using your language/tools do it. This is not a language-agnostic question; some languages/tools expect a relationship between 'file organization' and 'what's in those files' and you should respect that.

Brian