Question on immediate failure

[Frank Verbruggen]

Topic: Should I expose the lockRecord and unlock methods to clients of the server program
The DBAccess interface specifies the lockRecord and the unlock methods, do I, or don�t I expose these methods to clients.


Choice: Should I expose the lockRecord and unlock methods to clients of the server program
It clearly states the following:
quote:
________________________________________
SERVER
Required Interface

Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
________________________________________


This means that for accessing my data, server-side ! I must have a class called "Data.java" in package "suncertify.db", NOTHING is mentioned about having to expose this interface to the clients !!!

Also using this design improves code clarity.
Since the assignment DOES state:
quote:
________________________________________
Use of functionality provided by the core Java classes will be prefereed to your own implementation of that functionality
________________________________________

and ALSO:
quote:
________________________________________
A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one
________________________________________

So, I currently have a solution in which I dont offer these methods to my clients.

Will sun treat this as an immediate failure or not ???



I would VERY much like to know before handing in my assignment.

Thx in advance

[Dieskun Koper]

I think you should not expose your lock methods to the client unless your instructions explicitely tell you to.
I used the adapter pattern for my Data class and did not expose any methods of the DBMain interface to my clients, and passed.

[Stephen Loh]

Actually I feel that it's up to you. If you think you have a reason to allow the clients to control the locking mechanism, just go ahead, AS LONG AS YOU JUSTIFY YOUR DECISION IN THE DESIGN CHOICES FILE!

There are memebers who claimed that you should design your application in a fat client fashion, which exposes the locking methods to the client. They claimed that the thin client model may not necessarily meet certain requirements. I'm not 100% sure too, but to play safe, I will expose it.

And yes, my instructions also said nothing about having to expose that interface to the client. If you notice, the interface given to you does not extend the Remote interface in the first place, and we are prohibited from changing the interface! That means we have to decide on our own Remote interface to expose to the client, which could be as simple as simply routing the method calls to the Data class, meaning it acts like a proxy.

[Frank Verbruggen]

Hmm, the above is most of my justification from the choices file
(HTML format)
Do you think it is enough, or should I write a more elaborate justification ?

[Andrew Monkhouse]

Hi Frank,

You might be interested in reading some of the thoughts in the long discusssions held in "Should lock methods be callable by the client". There are arguments both for and against exposing the lock methods to the clients directly.

It does appear that the choice is yours - either method of coding can lead to a high pass mark. Just ensure you document your decisions .

Regards, Andrew