aspose file tools*
The moose likes Cattle Drive and the fly likes Servlets-4a Question - default class visibility Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » This Site » Cattle Drive
Bookmark "Servlets-4a Question - default class visibility" Watch "Servlets-4a Question - default class visibility" New topic
Author

Servlets-4a Question - default class visibility

Richard Broersma
Ranch Hand

Joined: Apr 28, 2009
Posts: 63

Several source files are provided for this assignment. One such file is VideoData.java, which has the following class definition: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
Sheriff

Joined: Nov 03, 2006
Posts: 1344
    
  12
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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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.


[Jess in Action][AskingGoodQuestions]
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

Thank you for your valuable response Ernest
Richard Broersma
Ranch Hand

Joined: Apr 28, 2009
Posts: 63

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
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24166
    
  30

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
Ranch Hand

Joined: Apr 28, 2009
Posts: 63

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Servlets-4a Question - default class visibility
 
Similar Threads
Breaking the path roadblock....
Why I cannot extend a class from java.lang.Package
see my jsp error dscon$jsp.java [67:1] cannot resolve symbol
relative URL in jar files
class file has wrong version 50.0, should be 49.0