Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Visibility of the Data class

 
Olivier Gregoire
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,


After well-reading my assignment, I see nowhere on it that my suncertify.db.Data class must be public. So I decided to make it package-private to have more control on the public interfaces I give outside the package (the only thing I can't reduce is the DB interface since its visibility is explicitly mentioned).

That means that all I allow outside of the package suncertify.db is the access to one interface (the DB interface), the exceptions and one factory. I also have a dao interface in some other package, but its suncertify.db implementation is not visible from outside the package. That dao is also built from the factory.

By looking at the code, it is 100% sure that the Data class fulfills all requirements. Additionally to all these requirements, I just made it package-private.

So, my only question now is: "am I really allowed to do that"?
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well champion, as you said, it is never said that the Data class should be public, so I'd say yes, you are allowed to make it package private.

However, I think that, from a framework point of view, it would be better to make it public. If, in the future, someone wants to extend it, it would be possible without any problem.

But, in the end of the day, I think this is also a matter of decision. You may make it package private and then say that you want to keep it as restricted as possible in order to avoid problems... in my opinion, it is better to make it public.
 
Olivier Gregoire
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand, but isn't composition better than extension? That's what I understand from reading the book "Effective Java" written by Bloch.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Olivier Gregoire wrote:I understand, but isn't composition better than extension?


Well, most of the time, yes. However, sometimes people ask "oh, what is better, X or Y?", and other people say "oh, X is much better!". One thing I learned after I started learning and working with software development is, there is no "best" option, but an option that may be more adequate in one situation and at the same time may not be the most adequate in another situation.

Extension makes sense when the IS-A relationship is true. For instance, a LinkedHashMap IS-A HashMap. It is generally better to compose objects, but when the IS-A relationship is true, it is totally ok to extend another class or interface.

If you make your Data class public, you let the developer that is using your framework free to decide whether it is better to extend or to use composition.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My Data class is package private, because it is not supposed to be used outside the db-package. Similar all my gui classes are package private, because they are not intended to be used outside the gui-package. My interface (and Sun's interface) is public, because these interfaces should be referenced from other packages, not the implementations (Data class).
So Olivier I completely agree with you and it is not a problem, because you don't violate any requirement.

Kind regards,
Roel
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic