permaculture playing cards*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes shall DataInterFace be general or specfic to FBN project? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "shall DataInterFace be general or specfic to FBN project?" Watch "shall DataInterFace be general or specfic to FBN project?" New topic
Author

shall DataInterFace be general or specfic to FBN project?

calvin zhu
Ranch Hand

Joined: Mar 18, 2002
Posts: 54
please comment.
In my approach, first I was thinking let Data class implements DataInterface.
Then I want to add book() in the DataInterface, so the client can call it,which will work as a facade,( I don't need to call read, lock, modify, unlock one by one in my client, just calling one method: book().) But that means general Data class will need to add an business related method book in it. I don't think it's a good idea.
Now my design is like this:
DataInterface has all the public method in Data class and also Book() method.(maybe in the future other FBN related method)
LocalData extends Data implements DataInterface.
But there is no relation between Data class and DataInterface.
In this approach, I think Data class will be general enough and DataInterface will be specfic for FBN project, maybe I should even change the name to FBNDataInterface.
Now bring up the question:
is it appropriate to put business related method in the interface making this interface only relate to FBN project?
Also I still put critericaFind() in the Data class since I believe this is a general method just like find().Then I both modified the Data class and extended the Data class. Will this break the specification requirement? which says "You may do this by modification or subclassing".
please comment, and thank you for your time.


SCEA, SCJD, SCWCD, SCBCD, SCJP<br />IBM WebSphere Portal certification
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Don't. Very bad idea.
  • You're seriously impeding reusability of your application. If your networked layer on top of Data has any business methods, it's not reusable in other projects (except in the cut and paste sense). If it just a networked, multi-user version of Data, it is completely generic and reusable.
  • You're mixing abstraction levels. Your business interface is an abstract, high level, application-specific interface. It deals with flight objects. It deals with composite operations such as booking a seat. The Data interface is a concrete, low level, completely generic interface. It deals with records and elementary read and write operations. Such different abstraction levels should never be combined in one API.
  • To elaborate a bit (some would say hammer the point home), here's my instant boilerplate 3-tier application architecture diagram.
    UI layer <==> business layer <==> database layer
    I draw this diagram for all my systems There are three layers, and between these layers there are two interfaces. The UI <==> business interface is abstract, high level, domain-specific, probably dealing with Flight objects and what have you. The business <==> database interface is (usually) low level and generic. In the real world it's often an SQL/JDBC interface.
    One of the design decisions you have to take is whether the business layer should reside in the client part of your application, or in the server part. The requirement that you should have a client-side object implementing all the public methods in Data nudges you -- well, bullies you really -- into putting the business layer into the client. If your business layer were to live on the server, it makes no sense whatsoever to have a Data-like object in the client. Worse, it would be extremely bad OO design.
    So the cut between client and server is in the business <==> database interface. Data dictates the API of the database layer. What you are to write is a networked, multi-user wrapper around Data.
    - Peter
    [ November 21, 2002: Message edited by: Peter den Haan ]
    calvin zhu
    Ranch Hand

    Joined: Mar 18, 2002
    Posts: 54
    Peter, while I looking through the topics (some as old as all most 2 years ago), I can't help notice your continued contribution to this forum, your generous help to people like me.
    First, allow me to say "Thank you very much".
    Second, after carefully thought, I decided take your advice, keep the DataInterFace consistent with Data class. Instead I will put the book() into another Class DataConnection which reside on the clien side. So basiclly the DataConnection class will work as an adaptor for RemoteDataImpl on the client side, except it has more bussiness related methods like book(). When it's in local mode, the DataConnection will just call Data's correspond method. So this should fullfill the request of "The cut between client and server is in the business <==> database interface".
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: shall DataInterFace be general or specfic to FBN project?
     
    Similar Threads
    Local & Remote Data Intefaces
    Initial design review
    FBN Design
    Design questions (with RMI)
    Making Data "remotable"