Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Should be data class public?

 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking, that automatic test utility SUN is using may somehow depend on this fact.
 
Gabriel Vargas
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,

Why you don't want to declare Data public?
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 152
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 :-)
 
Gunnar Bastkowski
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic