Criteria for package

[Laojar Chuger]

I assume everyone who has done some serious programming in Java knows how to relate the classes into packages. However what exact criteria to use for grouping classes into a package is a tough question. One can say that the classes must be closely related, but what do you mean by related. Every classes in the system is related to each other in some way. So related is not really a good word to describe the relationship between two classes. Another opinion is that classes that are worked by the same group. How big the group is? How many subjects are the group working on?
I have been trying to get some official doc on the subject and no luck. What's your opinion?

[Avijeet Dash]

I wud like to think this way..
there would be maximum 10 major use cases in a big project.
each use case would lead to top level package.
and classes in that package would be very much to make that use case work.
dependecies across packages would be very less.
am i sounding logical or completely wrong???

[Desai Sandeep]

Hi,
Expressing my opinion on this.Probably it would not make any sense to you.In that case, you may ignore my reply
Taking the Java Servlet API Packages viz. javax.servlet and javax.servlet.http as an example.
I assume that the Java API developers would have developed a top level package which might be requirement specific.For example, they would have thought, let us have a top-level package, which is generic for all protocols - name it as javax.servlet!!Once this is done, they would have decided to put all the Generic classes in it.These Generic classes may have been derived out of the Use Cases.
Later they would have had one more requirement on supporting the HTTP protocol.So again, they decided to name a top-level package, this time - javax.servlet.http!!All the HTTP specific classes (which again would have been derived out of the Use Cases), would go in this package.
Keeping the above approach in view, I assume they would not have been bothered much with the dependencies across packages, as long as they could define the dependency using the package names.
Hence, instead of saying javax.servlet.http.HttpServletResponse is the Http-implementation of javax.servlet.ServletResponse, we can now say javax.servlet.http package is the Http-implementation of javax.servlet package.
Hope I have not confused you
Regards,
Sandeep Desai
[e-mail]

1. Sun Certified Java Programmer Scored 93 per cent
   
2. Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java Scored 56 out of 59
   
3. IBM Enterprise Connectivity with J2EE Scored 72 per cent
   
4. Enterprise Development on the Oracle Internet Platform Scored 44 out of 56
   

[This message has been edited by Desai Sandeep (edited April 23, 2001).]

[Laojar Chuger]

Use case can lead to package on condition when the use case has a distinct requrement that does not exist in the existing packages. Most likely adding a new use case just lead to the modification or subclasses on the existing classes. So the use case could not be an decisive factor for the package.
If you exame the JavaScript runtime engine of Netscape, you will find there is a strong connection between the servlet API with the server side javascript. The first release of servlet api could be well designed in view of package structure as it took the lesson from javascript already. However, the later releases of servlet api could not be based on a well designed package structure because it has to keep compatible with previous releases. That leads to new use case new package structure. This sure is not the best way of design.
The question is still on. What's the criteria?