Servlets-4a Question - default class visibility

[Richard Broersma]

Several source files are provided for this assignment. One such file is VideoData.java, which has the following class definition:

/VideoData.java
package com.javaranch.drive.videos ;

class VideoData
{
//... Constructors, Setters, Getters
}

Was it an intentional part of this assignment to *not* declare this class as public? The usefulness of this class certainly diminishes since JSPs - which are outside of the com.javaranch.drive.videos package - cannot reference this class directly.

[Katrina Owen]

Hi there, Richard -- I can't speak to the intentionality, so I've given a hollar to folks that know more about it. I'll let you know what I find out.

[Ernest Friedman-Hill]

In this application, the JSP talks to the servlet via HTTP, and the servlet uses the VideoData class since they're together in the same package. The JSP has no reason to touch the VideoData class, and so it's not marked public. There's a real nice separation of concerns -- this makes it real easy to understand the code.

The more widely used a class is, the harder it is to modify that class without breaking one of its clients. "Modify" includes "delete", meaning that any class you expose publicly, you may be required to maintain forever, even when you no longer need it yourself! Hiding is good; use the minimum necessary visibility for everything, and you'll make your life a lot easier.

[Seetharaman Venkatasamy]

Ernest Friedman-Hill wrote:he JSP has no reason to touch the VideoData class, and so it's not marked public. There's a real nice separation of concerns -- this makes it real easy to understand the code.

but if you keep your bean class[POJO] in the same pakage with servlet, dont you feel it complexity/mess? because typically developer keep group of servlets in a package and POJO classes in other packages to grouping the components separate. it makes easy to understand the directory structure!
Am I missing something here?

[Ernest Friedman-Hill]

Seetharaman Venkatasamy wrote:
Am I missing something here?

Not really -- I think we're just overanalyzing a very simple example with one servlet, one JSP, and one Bean. My explanation is just a rationalization of why the Bean isn't public. If you put it in its own package, it'd have to be public, so that would go against what I said above.

Oftentimes the decisions you have to make while developing software aren't perfectly clear. Sometimes no matter what you decide, there are both good and bad points about your choice. What's most important is that you weigh all the concerns, and make the best choice for your particular situation.

[Seetharaman Venkatasamy]

Thank you for your valuable response Ernest

[Richard Broersma]

Ernest Friedman-Hill wrote:In this application, the JSP talks to the servlet via HTTP, and the servlet uses the VideoData class since they're together in the same package. The JSP has no reason to touch the VideoData class, and so it's not marked public. There's a real nice separation of concerns -- this makes it real easy to understand the code.

Does this imply that it is a recommended practice to translate all bean data into key/value pairs in a hash before passing the data to JSPs via the response object?

[Ernest Friedman-Hill]

No, not necessarily, not at all. There are a number of different ways to architect things, and there's nothing wrong with using beans to send data to JSPS. what's bad are classes that couple different layers of the app and prevent them from varying independently. If you use the same beans for persistence and UI, then if need a new field in the gui, you suddenly find yoursélf modifying database code.

[Richard Broersma]

Ernest Friedman-Hill wrote:what's bad are classes that couple different layers of the app and prevent them from varying independently. If you use the same beans for persistence and UI, then if need a new field in the gui, you suddenly find yoursélf modifying database code.

This makes sense. Thank you for the clarification.