• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: DBMain and Data: Is Ambiguity Fun?

 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
When I first started this project, I was quite concerned about being flunked out-right
due to my mis-understandings or mis-readings of the unclear and ambiguous
instructions.
Recently, I've been going through the DBMain interface and taking notes, and thinking
about what to do with his interface, how it might be molded to my purposes, and
the like. Also, thinking about the exceptions, do they make sense for the method,
and the like. And, thinking about what "a record" means (i.e., is it a logical record,
a physical record) and what a "field" means (is it a logical field, a physical field).
I have to say that I have found this quite enjoyable. One of the assumptions which
I personally think that it is safe to make is that the DBMain interface has not been
implemented within the company, because, afterall, this is the first Java project.
So, it becomes a fun, "legalistic" game to think about DBMain because you can,
if your nose can sniff out a superior micro-design, interpret the Sun (purposefully)
ambiguity to your advantage!
Please keep in mind that anything I say in this particular post is temporary, in that
I may change my mind tomorrow or the next day. But, here is an example from
DBMain interface:

--------------------------------------
So, if you actually think Sun will instantiate your Data object and actually
run it and test it (which I think is very, very unlikely), you might miss out
on the fun that's actually involved in this project.
I think that one should feel free to use the ambiguity or what appears
as mis-formed sentences to one's advantage.
So, you have to decide what a RecordNotFound exception is; does it make
sense for the complete interface as you define it. Also, what is a record?
As an example, and again, this is preliminary, as it takes some thinking and
time to go through each method and think everything through (of course,
it's always best to think on paper for some people like me),
my read() method will return a String array wherein the first element
is all the logical fields of the record concatenated together as read
from the file's record, and the second element will be a representation
in String form of whether or not the record is active or inactive.
I would then, when I have found a consistent usage for the meaning of
the methods and the meaning of the exceptions and the meanings
of the arguments and return values, justify my answer for my own
personal design goals.
So, what I'm saying is that for me there certainly was an initial fear factor,
in that you want to submit your project, you have must conditions that
you must follow, conditions which are ambiguous at the same time, and
this may make the person taking the test "brittle" in that they may not
realize that they actually are in a position of power to come up with
whatever design and implementation they want (within reason). So,
if you find that nice balance between knowing what you must do, and
knowing that there are tons of options available to you, not only is the
exam rich in that there is quite a wide field of options available, but
it can be quite fun.
Thanks,
Javini Javono
[ January 07, 2004: Message edited by: Javini Javono ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
If I were you, I wouldn't do what you describe above, because it could/should lead you to an automatic failure.
You take argument of a *possible* (little) ambiguity in the provided DBMain interface, to conclude that you can interpret it the way you want. The problem is that you transform that little possible ambiguity by a huge certain one.
Let's start with the ambiguity you pointed out : "Returns an array where each element is a record value". OK, they should have written "Returns an array where each element is a field value".
But the method signature clears that ambiguity ! As the param is a recNo, it's clear that what you return is *one* record. So why do they ask us to return an *array* if the record had to be returned as a whole as you suggest ?! The fact that the word "record", misused in the comment, is to be translated in "field" becomes obvious. Your interpretation is different : as I *want* to return a record as a whole, and as I don't need an array for doing that, I decide to put in other elements whatever suits my own needs : the active flag in this case, but what about the recNo mapped in an Integer, or whatever else ? Not only the "deleted" flag is useless for your Data class users (a record marked as "deleted" simply doesn't exist anymore in the system (I mean "logically")), but the way you "structure" the array (with a convention of your own) makes it unusable by the callers.
Have a look at this very recent thread, and particularly at Jim's posts in it : interfaces are public contracts which must not be ambiguous. So if you find some ambiguity in them, you have no choice but try to solve it. It's not, in any way, like a permission to replace it by your own contract.
Best regards,
Phil.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
Thanks for your comment and response. From being a timid piper, perhaps I have
suddenly become an overly bold and daring lion.
Here are some of your comments which I paste here so that I can look at them
while I try to response.
***Phil:************************************************************************
Let's start with the ambiguity you pointed out : "Returns an array where each element is a record value". OK, they should have written "Returns an array where each element is a field value".
************************************************************************
Please remember that I am certainly not saying that I am absolutely right;
but it does say "record value", and who is to define what "value" means. Why
could I not define "value" to be all the logical fields in the record. Also,
the active/inactive flag is also a record value, and I can return that in another
element of the String array.
Again, I would not want anyone to lose points on the assumption that I have
any more inside information than anyone; for I have none. I'm just pointing
out that I'm writing
and defining the DBMain interface for the first time for this company. I'm not
changing the interface, but redefining what the input argument means, or at
least clarifying it; and, I'm suggesting that one might wish to do this for
reasons that they would have to substantiate to Sun. For instance, I want
the records always to be physical records, and I want to layer my more powerful
and client-programmer-friendly classes on top of Sun's given interface. Now,
will I really do this, will I really take this risk? I might very well; but, then again,
I might also change my mind. So, that's why I'm writing, to learn; and, I appreciate
your comments very much.
***Phil:***********************************
But the method signature clears that ambiguity ! As the param is a recNo, it's clear that what you return is *one* record. So why do they ask us to return an *array* if the record had to be returned as a whole as you suggest ?! The fact that the word "record", misused in the comment, is to be translated in "field" becomes obvious. Your interpretation is different : as I *want* to return a record as a whole, and as I don't need an array for doing that, I decide to put in other elements whatever suits my own needs : the active flag in this case, but what about the recNo mapped in an Integer, or whatever else ? Not only the "deleted" flag is useless for your Data class users (a record marked as "deleted" simply doesn't exist anymore in the system (I mean "logically")), but the way you "structure" the array (with a convention of your own) makes it unusable by the callers.
***************************************************
Well, I'm still returning information for only one record as two array elements:
element 0 is all the logical fields for one record; element 1 is the active/inactive
flag converted to a String representation.
It is true that for the most part I want to return the logical fields in the record
as a whole. Keeping in mind that I'm still in the process of analyzing DBMain
to come up with a consistent java interface, at this time, I see no reason for
this low-level read() method to be concerning itself with where the fields are;
I might have a more responsible class carry this out. If I do this,
it would be justified due to the following: that the complete java interface
works correctly within my particular design and is logically consistent. And,
I would justify this to Sun giving specific details about all the inputs, outputs,
exceptions, and the context in which things can occur.
The active/inactive flag still exists, but this preliminary idea of mine is suggesting
that if you have physical records, then the physical record obviously must exist
always. A higher level, more responsible class would be responsible for taking
action based upon the active/inactive flag.
I hope I don't sound like I'm not listening to what you said, Phil. I appreciate
your comments. I've seen plenty of posts where people came up with "daring ideas"
only to have reality eventually hit them and then decide to back down and do
something a more conventional way.
If I do indeed go on this "dangerous" path, I would justify it by what to me is a
very important concern: that the DBMain method be consistent in its meaning
with respect to exceptions, outputs, and contexts (for instance, the create()
method, even if I don't implement it, will, we can all almost be certain, eventually
be implemented by future enhancements, otherwise the company simply will
not be able to grow; so, for example, it's important to me that even if I don't
personally implement create(), the DBMain() interface must be defined so that
someone could in the future implement create() without having to say, gosh,
this guy didn't think his interface through correctly).
Thanks again for giving your time to challenge my ideas. As I consider to think,
I may very well change my mind and reasoning. For the ideas posted here are only
preliminary in nature.
Thanks,
Javini Javono
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Javini,
I hope I don't sound like I'm not listening to what you said, Phil. I appreciate
your comments. I've seen plenty of posts where people came up with "daring ideas"
only to have reality eventually hit them and then decide to back down and do
something a more conventional way.

That's what this forum is for : discussing design and coding issues in relation with our SCJD assignment. If all people all the time had the same opinions, this forum would be boring, definitely !
It is true that for the most part I want to return the logical fields in the record
as a whole. Keeping in mind that I'm still in the process of analyzing DBMain
to come up with a consistent java interface, at this time, I see no reason for
this low-level read() method to be concerning itself with where the fields are;

I might have a more responsible class carry this out.

The problem is that Data is *less low-level* than you think (and that you want it to be BTW). Data is higher-level than what you do (and in a consistant way : in create(), update() and read()), because it breaks an otherwise meaningless record into useful pieces of information : the field values. If your Data class doesn't carry that job, yes you'll need another class to do it indeed, but in which way would it be "more responsible" ?
Best,
Phil.
 
Remote Javini Javono
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Question: If your Data class doesn't carry that job, yes you'll
need another class to do it indeed, but in which way would it be
"more responsible" ?
Well, simply by being at a higher level, classes tend to be more
responsible or have more ability to do something more easily.
But, I think I mean simply that that particular responsibility
of determining the individual fields will be given to a class
which uses a Data which implement DBMain.
Again, it's important to note what the driving motivation is:
it's not necessarily that I want the responsibility moved (though
this certainly was my initial, intuitive impulse), the motivation
at its core must be a goal: to create a logically consistent
DBMain interface with respect to input and output definitions,
what exceptions mean and when they will be thrown, and the like.
Thanks,
Remote Javini Javono
 
james airey
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One problem with the ambiguity is that you are guessing how Sun interpret it.
If they disagree with your interpretation, they are not going to phone you up for clarification. Especially not in the areas that are computer marked, which lead to automatic failure.
All exams require a measure of guessing what the examiner meant.
All functional requirements require guessing what your client wants, even if they think they have been clear.
Your goal is to give them the best system you can, not to twist their words on them. Unless you are a lawyer, and then why are you taking a java exam
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic