Win a copy of Soft Skills: The software developer's life manual this week in the Jobs Discussion forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Implementing Requirements in DB not on GUI

 
Alan W Morgan
Greenhorn
Posts: 23
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

Doing URLyBird 1.1.3 and have questions on Unbook, Create and Delete.

Create and Delete are method on my DB interface but are not mentioned in GUI requirements.
So to follow the mantra of if its not in don't do it I'm not putting the ability to Delete or Create on my UI.
But do I still have to implement it on the DB side for future purposes ?

UnBook is not mentioned anywhere. This means that once I book a record I can never unbook it. Logically it doesn't make sense.
But again if its not mentioned should I do it ?
And if I don't worry about it do I still have to check if a record is booked before I update it as the only records I will disply in UI will be those available to book surely ?

Any thoughts would be appreciated.

Alan.
 
Ta Ri Ki Sun
Ranch Hand
Posts: 442
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alan W Morgan:
Hey,

Doing URLyBird 1.1.3 and have questions on Unbook, Create and Delete.

Create and Delete are method on my DB interface but are not mentioned in GUI requirements.
So to follow the mantra of if its not in don't do it I'm not putting the ability to Delete or Create on my UI.
But do I still have to implement it on the DB side for future purposes ?

UnBook is not mentioned anywhere. This means that once I book a record I can never unbook it. Logically it doesn't make sense.
But again if its not mentioned should I do it ?
And if I don't worry about it do I still have to check if a record is booked before I update it as the only records I will disply in UI will be those available to book surely ?

Any thoughts would be appreciated.

Alan.


Hi Alan
Create and delete, I've yet to see someone post that they've passed without implementing those methods, they may have, and never posted, or I didn't see it. The interface has to be implemented, and there's a good chance those methods form part of their tests.

Unbook/cancel booking is unheard of, but I made it easier to later implement this by not filtering records displayed to the user based on whether they're booked or not. All records, except deleted ones, are displayed, even if they're in the past. As I said last week I feel this allows a user to do more than make a booking, they can track bookings, confirm a clients booking, print a report when filtering a specific hotel or location, and possibly in the future cancel a booking.

Whatever you do make sure you can justify your decision, and you should be alright
 
Alan W Morgan
Greenhorn
Posts: 23
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ta Ri Ki Sun:


Hi Alan
Create and delete, I've yet to see someone post that they've passed without implementing those methods, they may have, and never posted, or I didn't see it. The interface has to be implemented, and there's a good chance those methods form part of their tests.

Unbook/cancel booking is unheard of, but I made it easier to later implement this by not filtering records displayed to the user based on whether they're booked or not. All records, except deleted ones, are displayed, even if they're in the past. As I said last week I feel this allows a user to do more than make a booking, they can track bookings, confirm a clients booking, print a report when filtering a specific hotel or location, and possibly in the future cancel a booking.

Whatever you do make sure you can justify your decision, and you should be alright


Thanks for the reply.
What you said about automated testing makes sense.
So I'll implement them in the DB but no expose them to the GUI.

Good point on not filtering on booked records.
Your explanation has sold me on it.
 
Ta Ri Ki Sun
Ranch Hand
Posts: 442
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Alan W Morgan:


Thanks for the reply.
What you said about automated testing makes sense.
So I'll implement them in the DB but no expose them to the GUI.

Good point on not filtering on booked records.
Your explanation has sold me on it.


You're welcome
 
Cleverson Schmidt
Ranch Hand
Posts: 55
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ta Ri Ki Sun,

I've yet to see someone post that they've passed without implementing those methods

So click here

Cleverson Schmidt
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remember that post too. I am still not sold....

Just because one person passed with empty methods does not mean that everybody would. There are several different assessors, and while one of them may have appreciated his justification for "technically" implementing the interface, others may not. If I pulled that kind of scam on a client, I would probably end up on the wrong end of a lawsuit!

If anyone else want to brave it... it's your $150. Be my guest and make sure you let us know how it turns out! It didn't take long at all to provide the extra code, and I feel better about my application for doing it.
 
Liang Anmian
Ranch Hand
Posts: 119
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Previously, there's a member here who e-mailed Sun, and this Sun representative has clearly stated that they do not use automated testing.

I think it's not possible either. After all, all the instructions require is that your Data class implements the interface. There are many ways to write the Data class. Some may make it a singleton, and some may not. For others, they may code in such a way that the constructor is empty, some may use a String as an argument to the constructor to specify filename, while others may use a File object. Since there are so many ways to write that class, there's virtually no way to write an automated test, unless they peek at your source code and modify their automated test codes. But like what I mentioned, this Sun representative has already denied usage of automated tests.

Come to think of it, if they do not use such tests, how will they know for sure that our codes are bug-free? They can't possibly do it by just inspecting our source codes. This one, I don't know. LOL!

Ok back to topic. I do agree that it is safer to implement all the methods in the interface. A strict accessor may fail you straight if you don't, no matter how you try to explain. It doesn't hurt to implement them even if you are not going to use them.
[ April 27, 2005: Message edited by: Liang Anmian ]
 
Frans Janssen
Ranch Hand
Posts: 357
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Paul Bourdeaux:
I remember that post too. I am still not sold....

Neither am I. I think it proves that you can pass with empty implementations of create and delete, but I also think you will never get more than the 44 points for locking.

A key issue with respect to locking is what happens when a record your client is waiting to lock, is deleted. By leaving delete blank, you have just nullified this scenario and thus evaded a key challenge of the assignment.

So yes, you can pass with emply implementations, but you will be allowing yourself a major flaw in your solution and it's going to cost you points.

Frans.

DISCLAIMER: all of the above is of course pure speculation, because apart from the assessors no one knows how the assignments are graded.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic