• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thinking in Java, Exercise solving  RSS feed

 
Pedro Fernandes
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys, this is my first topic here, i've been silently enjoying the forum. Great community here!
So, im making my way through Thinking in Java (Bruce Eckel), and i'm kinda stuck in Exercise 8 on page 161 from the Access Control chapter:

Following the form of the example Lunch.java, create a class called ConnectionManager that manages a fixed array of Connection objects. The client programmer must not be able to explicitly create Connection objects, but can only get them via a static method in ConnectionManager. When the ConnectionManager runs out of objects, it returns a null reference. Test the classes in main( ).

Here's what i came up with:


It worked fine (although i think the code could be better written (tips are welcome) ), but here is the problem: Is the programming client really kept away from the Connection constructor? Could he create a class inside the package and directly use something like



?

Sorry for the long post and thank you guys for the attention!
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pedro Fernandes wrote:It worked fine (although i think the code could be better written (tips are welcome) ), but here is the problem: Is the programming client really kept away from the Connection constructor? Could he create a class inside the package and directly use something like

Well, somebody could; but not a client - at least not without adding a class to your package.

You might make it a bit safer (and possibly more flexible) by making Connection an interface and then implementing it with a private nested class.

Also: It seems a bit odd to only allow x total Connections. Why not implement it as a pool, so someone can return() a Connection when they're done with it? You might find a BitSet useful for controlling access.

Winston
 
Pedro Fernandes
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Pedro Fernandes wrote:It worked fine (although i think the code could be better written (tips are welcome) ), but here is the problem: Is the programming client really kept away from the Connection constructor? Could he create a class inside the package and directly use something like

Well, somebody could; but not a client - at least not without adding a class to your package.

You might make it a bit safer (and possibly more flexible) by making Connection an interface and then implementing it with a private nested class.

Also: It seems a bit odd to only allow x total Connections. Why not implement it as a pool, so someone can return() a Connection when they're done with it? You might find a BitSet useful for controlling access.

Winston


Thanks for the feedback Winston. I'll look into the tips you gave me and rewrite the code. I think my doubt is really about the programmer/client programmer dynamic. He would use my classes through a jar file right? And is it safe to assume that default modifier (no modifier) is enough to protect the class Connection in this case?
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!