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

(B&S) The given SUN Interface

 
Saheed Adepoju
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all
I am confused about some thing as regards changing the given interface, does this mean that when we implement DB in Data.java we cannot add methods to Data.java or does it mean that we cant add methods to DB interface only? I have declared List<Contractor> getAllContractors() within my Data.java which returns the present contractor objects within the Cache, i do hope this is a right approach? Thanks
 
Bob Nedwor
hangman
Ranch Hand
Posts: 215
Eclipse IDE Oracle Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Saheed:
I believe we can add more methods to Data.java (I also use an ArrayList of subcontractors)-- as long as we also implement all the the required methods from the interface and conform to all the other requirements. I did not change anything on the interface (DBAccess.java). I think that it should only contain the stuff in the "Server - Required Interface" section of your instructions.html.

I hope this helps.
--Bob
 
Saheed Adepoju
Ranch Hand
Posts: 267
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
Wonderful, clears loads of doubt. Thanks for your input.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't change the interface and the class has to implement the interface.
There's nothing saying the class cannot do anything else, nor does it say the class has to implement the interface directly or that you can't extend the interface.
 
Bob Nedwor
hangman
Ranch Hand
Posts: 215
Eclipse IDE Oracle Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

nor does it say the class has to implement the interface directly or that you can't extend the interface.


So I guess here you are talking about a case where one of the required methods would also be abstract in Data.java as well, then some other class would eventually implement it, later down the inheritance tree. Yes, then that would makes sense too. ...and probably a good suggestion from the standpoint of not clogging up your Data.java with too many methods.
[ June 05, 2006: Message edited by: Bob Nedwor ]
 
Joseph Schulz
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey guys...
I would really appreciate if you could clarify your design decisions to me.

Originally I was going to go down the road of creating Contractor class but then scrapped it when I took some time to think about the actual implementation and how it would interact with the database (via the given interface).

Were you planning on using the given interface as the way of communication with the file but the GUI/client will actually be using/accessing the Contractor objects? And therefore the Sun given interface will act as a link between the record in the DB and the Contractor object?

Thanks in advancE!
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my implementation the server knows nothing about contractors. All it knows about is records of a given format.
These are passed (as arrays of strings) to the client which does know about contractors and uses that data to create contractor objects.
When it's time to store a contractor, it then turns that contractor back into an array of strings and sends it to the server which knows how to store such an array.
 
Joseph Schulz
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen T Wenting:
In my implementation the server knows nothing about contractors. All it knows about is records of a given format.
These are passed (as arrays of strings) to the client which does know about contractors and uses that data to create contractor objects.
When it's time to store a contractor, it then turns that contractor back into an array of strings and sends it to the server which knows how to store such an array.

Jeroen,
Thanks for the clarification!
Very interesting... Did you create another facade for the conversion (from array of Strings to Contractor and vice versa) purposes or did you ended up doing it in the presentation layer?
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's part of the contractor class (where IMO it belongs) which thus becomes an intermediary between the data abstraction layer and the user interface layer.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic