aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Interface or Object? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Interface or Object?" Watch "Interface or Object?" New topic
Author

Interface or Object?

Evgeniy Sedyshev
Greenhorn

Joined: Sep 15, 2004
Posts: 4
Hi, everyone!

Sorry for my bad English, but I have a pair questions on which answers are very necessary for me )

I think, that many of you address to data through some intermediate object, which, in turn, causes methods of class Data. But how you store the reference to Data instance: as on object (i.e. Data db=new Data ()) or on the interface (i.e. DBAccess db=new Data ())?

If as on the interface, how then, for example, to be in a case if, the db scheme not coresponds to scheme specified?

Formally, the server should work (exceptions should't be) - a file correct. But the client can't work, as he will has't an information about other scheme. How the server can inform the client about this situation?
[ September 15, 2004: Message edited by: Evgeniy Sedyshev ]
Joakim Eriksson
Greenhorn

Joined: Sep 13, 2004
Posts: 25
Short answer:

It can't.


Long answer:

or rather either you provide extra public methods like getDBSchema() that is not included in the interface to accesses the database in the Data class or in a subclass to Data, or you assume that the schema is hardcoded in the GUI and logic code.

The middle path:

Considering all validation logic and business logic is specific for each database ie if you add a new field to your database, you would have to know how to validate this data. This would have to be hardcoded into your app for a new database as it cannot be read from the schema.
Ie suppose you add another date field, and someone tries to insert an ip number into that field, how would your app know that it is a faulty entry? You would have to code new validation into your app first.

Realizing that you have to code new logic if the database is extended or changed, makes it easier to accept that you also hardcode field names and field lengths in your app.
The best place to write this code is in the Value Object (aka Business Object because of validation) which in this case is an object representation of one row of your app. The Value Object is a single point (file) of variation when you change the database later. The gui should read metadata (column names for instance) from this object as well. Thus changing your database and your Value Object gives a new functionality for your app.

The only way you can make a application using the given schema specs that dynamically adapts to every new database is if it does no data validation beyond field length and US-ASCII for new fields and you have a way to retrieve the schema (as described above). (Or you store metadata for the db concerning field validation in a settings file that you can alter through some dialog ... nah to complex)

/J
Evgeniy Sedyshev
Greenhorn

Joined: Sep 15, 2004
Posts: 4
But i still can't decide: to call Data's methods directly, or to call them through interface?

I think, to call through interface - is better idea, but directly call is more convenient.
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Evgeniy Sedyshev:
But i still can't decide: to call Data's methods directly, or to call them through interface?

I think, to call through interface - is better idea, but directly call is more convenient.


The solution is described in the Data Access Object pattern. A DAO is a stateless adapter that does the simple CRUD operations (Create,Read,Update, and Delete). I've built one of these that supports 3 different Data Sources, the server, the flat file and Oracle. The Oracle part isn't needed for the cert, but it proves the correctness of the DAO, and I happen to run Oracle.

The DAO accesses whatever the database provides and gives its client an interface that uses objects, often called either Data Transfer Objects or Value Objects, although the current Java-correct term is Transfer Object. This way the client doesn't need to know about things such as that the cert database has a lock method but Oracle has a ReadForUpdate method, or what is metadata looks like.

See Core J2EE Patterns (Alur, Crupi and Malks) for details on DAO and TO patterns.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Interface or Object?