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"?
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.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
posted 10 years ago
I understand, but isn't composition better than extension? That's what I understand from reading the book "Effective Java" written by Bloch.
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.
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.