[URLyBirdHotel 1.3.3] Can I add more interfaces on Data.java?

My Data.java Interface must be implemented following statements.


#########################################################################
package suncertify.db;
public interface DBMain {
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] read(int recNo) throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n
// appears in data[n].
public void update(int recNo, String [] data)
throws RecordNotFoundException;
// Deletes a record, making the record number and associated disk
// storage available for reuse.
public void delete(int recNo) throws RecordNotFoundException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public int [] find(String [] criteria)
throws RecordNotFoundException;
// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create(String [] data) throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;
// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;
// Determines if a record is currenly locked. Returns true if the
// record is locked, false otherwise.
public boolean isLocked(int recNo)
throws RecordNotFoundException;
}
##########################################################################

Is it possible that I add more interface functions on Data.java which
is given to my assignment for data access class.

something like,
public String[] toString(URLyBirdHotelClass ubhc) throws Exception;

After, The something-class which implements the Data interface class should
be implemented.


Is it OK?

Your Data class can implement other interfaces, but I'd seriously question whether or not you need to. The example method which you provided could be contained within your 'URLyBirdHotelClass' since it is a method specific to its implementation where as the DBMain interface is pretty generic.

Is it possible that I add more interface functions on Data.java which
is given to my assignment for data access class

why not?
Your Data class must implement the specified interface. This does not mean that your Data class interface must be the specified interface
Regards
[ August 21, 2006: Message edited by: Oricio Ocle ]

Thanks for your all reply. It's very helpful for me.

I'm seriously concerned about how to implement the Data class.

I decided to program using DAO which is better for me. ^^:


By the way, I appreciate all of you guys.

Blss you ^^:

I would suggest that you Data.java class should provide the ENTIRE required functionality through the interface DBMain. That is not to say that you couldn't implement another interface (say Serializabe, or Cloneable, or Remote, etc), but Data.java should be functional enough that ANY other developer could write a simple application using the DBMain interface to get complete access to the entire functionality specified by DBMain, through the use of the DBMain interface.

Think of it this way: you can create an instance of Data in each of the following ways:

1. public DBMain database = new Data();

2. public Data database = new Data();

If you're code will not work correctly using the first, but rather requires the second to work correctly, then you have not correctly implemented the contract specified by the assignment.

- Adam

Correct. What I've done is extend the DB interface with some utility methods and writing some proxies around it.

Originally posted by Jeroen T Wenting:
Correct. What I've done is extend the DB interface with some utility methods and writing some proxies around it.

The proxy idea is a good one, I think. I'm not wild about the utility methods though, unless they are used for initialization and/or finalization.

I would say that if you're proxy method relies on those utilities to perform the basic operations specified by the provided interface, then you aren't complying with the contract of the interface. You should be able to create the database, initialize it, and then cast it to the interface type, and do all of the specified operations using only the methods provided by the interface. At least, that's my take on it.

Consider what would happed if your data object was returned from a factory method of type of the interface. You woudln't know it had those utility methods, but since it implements the DBMain interface, you do know that it should correctly perform all of the methods required. Would it?

- Adam

then you aren't complying with the contract of the interface

There is no requirement stating the interface must be used by the client.
Only subjetive minds.

A recommended lecture:
3 vs 2 tier

Regards

Originally posted by Oricio Ocle:

There is no requirement stating the interface must be used by the client.
Only subjetive minds.

A recommended lecture:
3 vs 2 tier

Regards

you're right. there is no explicit requirement that you cannot add and use extra methods to your Data object. However, this a requirement that you implement the interface provided.

and by definition, a well designed class that implements an interface SHOULD be able to perform all of the tasks required by the interface using the methods supplied by the interface.

if I say that an object implements DBMain, then I should be able to hold a reference to that object in a variable of type DBMain, and it should be fully functional in this manner. Otherwise, it hasn't correctly implemented DBMain. It has not complied with the contract of the interface DBMain.

The very first paragraph of Interfaces from the Java Tutorial (java.sun.com):

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts

An interface specifies a contract for how objects interact. I should be able to write a totally new client to interact directly with you Data object, holding a reference to it of type DBMain (the interface), and get complete functionality as defined by DBMain. If I cannot, then you have not complied with the contract of the interface.

This is not specific to the certification, this goes for all OO software designs.

- Adam

Originally posted by Oricio Ocle:

A recommended lecture:
3 vs 2 tier

Regards

sorry, but I don't really see how that applies. I have no issue with either a 3 or 2 tier system. And I have no issue with adding additional methods or additional interfaces to the Data object.

my issue is that the methods of the data access class that correspond to the supplied interface should function as described by the supplied interface, without any external interference. When the interface says: this method performs in such a way, then it darn well better perform in that way. that's all I'm saying.

- Adam

When the interface says: this method performs in such a way, then it darn well better perform in that way. that's all I'm saying.

Every one agree, that is implement the interface according to the specs.

sorry, but I don't really see how that applies. I have no issue with either a 3 or 2 tier system. And I have no issue with adding additional methods or additional interfaces to the Data object....

Ok, it that situation does not apply, but your previous words confused me.
I had not clear what were your thoughts.

Think of it this way: you can create an instance of Data in each of the following ways:

1. public DBMain database = new Data();

2. public Data database = new Data();

If you're code will not work correctly using the first, but rather requires the second to work correctly...

Bridge pattern or implementation hiding to the clients is a good practice, but not a must.

If Data class implements the interface the requirement is fulfilled, does not matter if data clients interact through the interface or directly to the implementation, IMO.

Regards

Originally posted by Oricio Ocle:

If Data class implements the interface the requirement is fulfilled, does not matter if data clients interact through the interface or directly to the implementation, IMO.

I think you'd be marked down if you interact directly with the implementation as its bad practice and bad design to do this rather than using references to interfaces.

Yes i think so,
read the previous line.

Regards

Ok, here is an example.
Provided interface: DBMain
Requiered implementation: Data

1)In order to add more funtionality:

In Data.java:

In data clients:


Adam, this client does not work with DBMain, but IMO it fulfills the requirements, since DBMain is implemented, it is waranteed that any other client could use:


Regards
[ August 24, 2006: Message edited by: Oricio Ocle ]

Originally posted by Oricio Ocle:
Ok, here is an example.
Provided interface: DBMain
Requiered implementation: Data

1)In order to add more funtionality:

In Data.java:

In data clients:


Adam, this client does not work with DBMain, but IMO it fulfills the requirements, since DBMain is implemented, it is waranteed that any other client could use:


Regards

[ August 24, 2006: Message edited by: Oricio Ocle ]

Yeah, any other client could call



And you would still get back a valid DBMain object. However, it would NOT work correctly as specified by the DBMain interface, because you need to call additional methods from type Data. So, you have an object of Type DBMain which does not work as you expect it should. Hence, to anybody not are that the object is of type Data (and that's your client, because it thinks it has an object of type DBMain), the object does not work correctly.

This goes beyond the bridge pattern and implementation hiding. This is a matter of "I have an object of type DBMain that does not behave like an object of type DBMain." When all you have is the interface DBMain, and you have NO idea that the type Data exists, then you have to accept the description of the behavior as supplied by DBMain. You don't know that you need to perform some "Extra" operations before you can perform those specified by the interface.

This is the whole purpose of an Interface -> to provide a contract as to how the object behaves, and provide the method signatures used to cause this behavior. You don't know or care about how it's implemented, because the interface is all you need to use it.

Think about it. One of the major goals of Object Orientation is abstraction -> separating implementation from interface. Just give the clients the signatures of the required methods, and tell them how to use them (this is the interface), and keep the implementation hidden -> this way, you can change the implementation later if you need to, and this way, you can re-use the same set of methods in any situation where they apply.

- Adam

it would NOT work correctly as specified by the DBMain interface, because you need to call additional methods from type Data...

sure it works correctly...

have an object of type DBMain that does not behave like an object of type DBMain...

Really cant see what you mean

You don't know that you need to perform some "Extra" operations before you can perform those specified by the interface...

in the example each client expects the behaviour provided by each interface.
Both clients are supported by Data implementation. That is polymorphism.

This is the whole purpose of an Interface -> to provide a contract as to how the object behaves, and provide the method signatures used to cause this behavior.

Adam, you are wrong. Interfaces are always defined before implementations. So the contract is given by the implementation, the object must behaves as the interface states.

You don't know or care about how it's implemented, because the interface is all you need to use it

Repeat, interfaces are not used to explain how implementations must be used, the goal of interfaces is explain what clients are expecting to find.

Think about it...

Oricio
[ August 24, 2006: Message edited by: Oricio Ocle ]

The original DBMain doesn't have any method to allow the user to know how many columnss there are in the database. Isn't it a must to add that to your DBMain interface?

It's a must keep the provided interface unchanged.
Regards
[ August 28, 2006: Message edited by: Oricio Ocle ]

oh, it's good to know that. Back to the drawing board.

Hi Adam,

Whilst I understand what you are saying I think it's possible to design the Data class so that it provides standard functionality required by the DBMain interface, i.e. create, update etc and also additional helper methods such as getDatabaseSchema.

You just need to ensure that the standard methods defined by DBMain interface are not dependant on the helper methods.

I extended the DBMain interface to provide additional helper methods such as getDatabaseSchema which are lacking from the original interface design, and documented my reasons for doing so.

And you would still get back a valid DBMain object. However, it would NOT work correctly as specified by the DBMain interface, because you need to call additional methods from type Data. So, you have an object of Type DBMain which does not work as you expect it should. Hence, to anybody not are that the object is of type Data (and that's your client, because it thinks it has an object of type DBMain), the object does not work correctly.

If I create a reference of type DBMain, this does not stop me from using any of the methods defined by the DBMain interface. However if I use the ExtDBMain interface I also have access to the schema etc.

This goes beyond the bridge pattern and implementation hiding. This is a matter of "I have an object of type DBMain that does not behave like an object of type DBMain." When all you have is the interface DBMain, and you have NO idea that the type Data exists, then you have to accept the description of the behavior as supplied by DBMain. You don't know that you need to perform some "Extra" operations before you can perform those specified by the interface.

I don't see why Data can't behave like an Object of type DBMain, the only difference would be that the additional helper methods are not visible, this does not stop me from updating a record etc.

This is the whole purpose of an Interface -> to provide a contract as to how the object behaves, and provide the method signatures used to cause this behavior. You don't know or care about how it's implemented, because the interface is all you need to use it.

Think about it. One of the major goals of Object Orientation is abstraction -> separating implementation from interface. Just give the clients the signatures of the required methods, and tell them how to use them (this is the interface), and keep the implementation hidden -> this way, you can change the implementation later if you need to, and this way, you can re-use the same set of methods in any situation where they apply.

Agreed, therefore we are providing two interfaces DBMain and ExtDBMain, the fact that they are implemented by the same class is hidden. If I use DBMain interface I know what methods are available and if I use ExtDBMain interface I also know that I have the additional helper methods.

As long as you document your reasons for the design I don't think there should be a problem.

regards
Jason

Hello, Jason.
Good explanation.

Only one thing:

You just need to ensure that the standard methods defined by DBMain interface are not dependant on the helper methods

Not even that it's neccessary.

Regards

Hi Oricio,

Not even that it's neccessary.

I think the point that Adam was trying to make (He can correct me if I'm wrong) and what I was trying to clarify is that the methods defined by the DBMain interface should be able to function without using any additional public methods provided my the extended interface.

i.e. you shouldn't define a new method in the Extended interface that you rely on for example locking a record, as it wouldn't be available using the DBMain interface.

Obviously we are only discussing public methods defined by the interfaces, you can have private helper methods for reading records etc which could used by methods defined in both the DBMain and ExtDBMain.

regards
Jason
[ August 29, 2006: Message edited by: Jason Moors ]

Hello Jason

You just need to ensure that the standard methods defined by DBMain interface are not dependant on the helper methods

If the dependency is inside there is no problem.

If interface methods define a workflow or secuence call, i agree, it is true.
You can not add more states or public calls to this workflow unknown by DBMain clients.
You can not require the client call new methods, but there is no problem let him call new methods.

I think both, were considering different situations...
[ September 01, 2006: Message edited by: Oricio Ocle ]