File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S wiring classes over constructors including dblocation param

 
Thomas Heiss
Greenhorn
Posts: 9
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello ranchers,

From my last post about ConfigurationGUI I got to the point of class instantiations which I currently only do in constructors.
There I thought it is a good way to extract this from my 2nd post to the old thread.

1. Is there any way for me to get around the multiple dbLocation constructor passing from the left to the right class?

E.g 1 Application (main) - 2 ServerImpl - 3 RemoteDatabaseImpl - 4 BusinessImpl - 5 Data (implements DBMain) - 6 RandomAccessFile

How could ServerImpl.init() create 3, 4, 5 and 6 without having to pass around the database location path from constructor to constructor?

e.g ServerImpl.init(): new RemoteDatabaseImpl(dbLocation).
in RemoteDatabaseImpl(String) constructor: new BusinessImpl(String).
and then over to Data to RandomAccessFile.

There seems to be much coupling.

BusinessImpl does this:
DBMain data = new Data(dbLocation) (isn't that good interface hiding implementation practice?)

1.1 So BusinessImpl CAN ONLY use use the DBMain interface provided by SUN, which does not provide openDatabase(String) or initDatabase(String).

1.2 Maybe I have to to create my own database interface which I should also use in BusinessImpl?

2. How may SUN even auto test (JUnit test or concurrency test) the Data class when they do not know how to open the database with it (which may be different implemented per assignment)?

So leaving out the String argument in the Data constructor gives me no more any possibility to pass over the location information.

3.1 Another one solution I was thinking about:


But again, BusinessImpl can not use anymore the interface DBMain as there is no DbMain.setDbLocation() method.

3.2 OR (maybe like the Spring container does as central configuration point):



Reading my own posting over again get's me the feeling that I should opt out for solution 3.2 which does not have tight class coupling (and in the setXXX() methods I would use the interfaces.

4. Had a talk on telephone with my colleague who suggested to move the 3.2 object construction/wiring code into a strategy to cut down init() (whatever that may look like).

Regards

Thomas

[ February 22, 2008: Message edited by: Thomas Heiss ]
[ February 22, 2008: Message edited by: Thomas Heiss ]
 
Alex Belisle Turcot
Ranch Hand
Posts: 516
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

since no one answer for while, I'll give it shot..

Originally posted by Thomas Heiss:

1. Is there any way for me to get around the multiple dbLocation constructor passing from the left to the right class?

E.g 1 Application (main) - 2 ServerImpl - 3 RemoteDatabaseImpl - 4 BusinessImpl - 5 Data (implements DBMain) - 6 RandomAccessFile

How could ServerImpl.init() create 3, 4, 5 and 6 without having to pass around the database location path from constructor to constructor?

e.g ServerImpl.init(): new RemoteDatabaseImpl(dbLocation).
in RemoteDatabaseImpl(String) constructor: new BusinessImpl(String).
and then over to Data to RandomAccessFile.

There seems to be much coupling.


What is the purpose of RemoteDatabaseImpl ? and BusinessImpl ? From their name, I would have assumed the other way around.
Is RemoteDatabaseImpl the object accessed by the Client later on ? Could it be called RemoteBusinessImpl rather ?

==> Do you see opening a database very different than other "operations" such as "booking"
The way I saw it, opening a database was an operation just like booking, retrieving records...

The Business class would then offer methods such as "openDB, book, getContractors..".


1.1 So BusinessImpl CAN ONLY use use the DBMain interface provided by SUN, which does not provide openDatabase(String) or initDatabase(String).

This does not mean it is bad to add other methods. I myself implemented Data as a Singleton, so I had to add getInstance(String dbFile) and changed the constructor to private
In the end, my Data can still be handled as a DBMain. If I were to pass its reference to another object, it could use it as a DBMain..


2. How may SUN even auto test (JUnit test or concurrency test) the Data class when they do not know how to open the database with it (which may be different implemented per assignment)?

I'm assuming that they still need a minimal effort to setup a correct instance of your Data, then they can run it through their unit test.
DBMain is an Interface, so in the end, you need to instantiante an class implementing it..

Basically, if you implement DBMain and your code compile, your respecting the contract.. The java compiler will make sure of that, If you see what I mean.


3.2 OR (maybe like the Spring container does as central configuration point):





I'm not see a major different with this piece of code, you still set the database file in the Data constructor. The only difference is your BusinessImpl is coupled with Data instead of a String/dbFile. Please correct me if I'm wrong.

Please comments and we can discuss more

Regards,
Alex
[ March 04, 2008: Message edited by: Alex Belisle Turcot ]
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic