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 ]