Packaging Conventions for App. Developers

Question

Looking for approaches to package organization for application developers. Everything I have read about this topic targets tool/framework developers. Grouping classes into packages seems intuitive in that case. But what about applications? Apps are not designed for reuse, so I don't have any intuition about how classes should be grouped. Whole application in one package? Separate package for each class? Does it matter? Thx.
Steve

Answer 1

Let me try to clarify what I was getting at. Package organization is determined at two levels: whether or not class are "related", and whether they might actually need to share data. For a library or framework, the first level is usually fairly intuitive because the code is meant to be reused; invoked or subclassed by other programmers. The package is imported to provide some particular functionality. Applications, by definition are an endpoint. In a layered design in a large environment, you'd get some reuse at the business logic level, but in general nobody is reusing this code. It's meant to be run only. So, the organizing principle of "related" tasks breaks down, at least for me. From semantic point of view, I could see architectural layers being a basis for organization, but other than that, I'm out of ideas. My inclination would be to lean toward encapsulation and put every class in its own package, unless there was an explicit need to share data. Hopefully I'm getting more and not less clear. Thanks.
Steve