File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Should be data class public? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Should be data class public?" Watch "Should be data class public?" New topic
Author

Should be data class public?

John Stone
Ranch Hand

Joined: May 04, 2007
Posts: 332
My assignment says:


But I'm wondering, why is there no requirement, that Data class should be public. I can imagine, that if I don't make it public I'll get automatic failure..

What do you think?
[ August 09, 2007: Message edited by: John Stone ]
Gunnar Bastkowski
Greenhorn

Joined: Jul 22, 2007
Posts: 10
I think you don't have to declare it public.

In fact I implement an additional business interface which uses the DB-Interface/Data-Class and put it into the same package,
so that there is no need to make the data class public.

Even if you put your business logic into a separate package,
you can create a factory method like

public static DB createDB() {
return new Data();
}

and your clients never need to know the Data class.
John Stone
Ranch Hand

Joined: May 04, 2007
Posts: 332
I was thinking, that automatic test utility SUN is using may somehow depend on this fact.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Hi John,

Why you don't want to declare Data public?


Gabriel Vargas
SCJP, SCJD, now studying for SCWCD and working to be a better person
John Stone
Ranch Hand

Joined: May 04, 2007
Posts: 332
I'm just thinking about all things, that can cause automatic failure and are not described or let's say they are 'hidden' in assignment text.
Gunnar Bastkowski
Greenhorn

Joined: Jul 22, 2007
Posts: 10
Why you don't want to declare Data public?


why do you want to do it when it's never used outside the package?
any classes which don't belong to the public api should not be declared public.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Hi ranchers,


I'm just thinking about all things, that can cause automatic failure and are not described or let's say they are 'hidden' in assignment text.


Things than cause automatic failure are described explicitily in assigment:


As noted at the beginning of this document, where this document uses the word "must" an absolute requirement is being described. If you fail to adhere to such a requirement, your assignment will be failed automatically, and without further evaluation. It is therefore imperative that you pay close attention to any statement using the word "must" in this document.


I think there isn't hidden failures, they are explicity to says "any statement using the word "must" in this document".


why do you want to do it when it's never used outside the package?
any classes which don't belong to the public api should not be declared public.


It depends where you want use your classes and interfaces, the two or three tier problem, for three tier it can works, but for two tier these classes can be used outside of the package (as i understand, i implement a three tier architecture). I didn't see a good reason to make it protected or default access in my project but classes hidden (databasemanager and lockmanager have default access modifier).

Regards.
rinke hoekstra
Ranch Hand

Joined: Apr 06, 2007
Posts: 152
Hi all,

the interface is declared public. To my feeling, this suggests a bit that the implementing class should also be public.

For the rest, Grabriel is right: there is no must. So if you would fail automatically because of this, at least you would have a strong point to protest against it :-)


_ _ ________________________ _ _ <br /> <br />Just SCJP (but 93%)
Gunnar Bastkowski
Greenhorn

Joined: Jul 22, 2007
Posts: 10

It depends where you want use your classes and interfaces, the two or three tier problem, for three tier it can works, but for two tier these classes can be used outside of the package (as i understand, i implement a three tier architecture). I didn't see a good reason to make it protected or default access in my project but classes hidden (databasemanager and lockmanager have default access modifier).


Sorry, but I don't agree with that. There is an Interface, called DB in my submission, which exposes the functionaliy to other packages (or tiers).
If you really want to separate the implementation from the interface, you even should not use a constructor of the Data class. Instead a factory method - or in real projects maybe an IoC-Container - should be used.

There is also no need to make the implementation public only because of a public interface. However, if you want to use the implementation in other packages, e.g. by subclassing Data, than you probably will have to make it public.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Should be data class public?