Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

shall DataInterFace be general or specfic to FBN project?

 
calvin zhu
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Posts: 54
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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".
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic