• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • salvin francis
  • fred rosenberger

Visibility of the Data class

 
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"?
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • 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: 2292
3
Eclipse IDE Spring Java
  • 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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • 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
 
That is a really big piece of pie for such a tiny ad:
Devious Experiments for a Truly Passive Greenhouse!
https://www.kickstarter.com/projects/paulwheaton/greenhouse-1
    Bookmark Topic Watch Topic
  • New Topic