EXPANDING JAVA CONCEPTS, Part 2- Packages Strategy

In EXPANDING JAVA CONCEPTS series PART1 i have explained some basic and advantages of using packages in Java.

In this post i will explain what packaging strategy you should choose because when you start building your application first question that will come in mind is how you should divide into packages?

While working in real world two strategy has been adopted:

Package By Layer and Package By Feature

Package By Layer: 

This strategy reflects various application layers that has been used in building application.Example :

• in.technoscience.action
• in.technoscience.model
• in.technoscience.dao
• in .technoscience.model

Each directory contains items that usually aren't closely related to each other. This results in packages with low cohesion and low modularity, with high coupling between packages. As a result, editing a feature involves editing files across different directories.

Package By Feature:

This strategy uses packages to reflect the feature set. It tries to place all items related to a single feature into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application.

Example: if you are building an application for education domain like for any college or any university, you will have following package structure

• in.india.university
• in.india.colleges
• in.india.students
• in.india.reports
• in.india.util and so on....

Each package usually contains only the items related to that particular feature, and no other feature. For example, the in.india.university package might contain these items :

• University.java
• UniversityAction.java
• UniversityDao.java
• Db items and user interface file(like jsp,html)

It's important to note that a package can contain not just Java code, but other files as well. Indeed, in order for package-by-feature to really work as desired, all items related to a given feature - from user interface, to Java code, to database items - must be placed in a single directory dedicated to that feature (and only that feature)

Out of two strategy, for business application Package By Feature is recommended.

• Package-by-feature has packages with high cohesion, high modularity, and low coupling between packages.
• Package-by-feature provides easier code navigation and that becomes easy during maintenance.
• Package-by-feature provides high level of abstraction and benefit of being at a high level of abstraction, the application becomes more self-documenting: the overall size of the application is communicated by the number of packages, and the basic features are communicated by the package names. The fundamental flaw with package-by-layer style, on the other hand, is that it puts implementation details ahead of high level abstractions - which is drawback.
• Package-by-feature separates both features and layers.The package-by-feature style honors the idea of separating layers, but that separation is implemented using separate classes. The package-by-layer style, on the other hand, implements that separation using both separate classes and separate packages, which doesn't seem necessary or desirable.
• In the package-by-feature style, the number of classes within each package remains limited according to the items related to a specific feature. If a package becomes too large, it may be refactored into two or more packages. In package-by-layer style,an application grows in size, the number of packages remains roughly the same, while the number of classes in each package will increase without bound.