I'm really starting to get into the detailed design of the Bodgitt and Scarper (2.1.2) assignment and I was wondering if anyone else thinks that the presence of create and delete methods implies extra functionality not stated in the problem description.
The problem description seems to suggest the client either wants to search for records or show them all. There is no mention of creation and deletion anywhere else in the spec. This leaves me a little confused because I can't see how create and delete really fit in anywhere else unless the user is specifically going to perform these operations.
The way I see the architecture going is the client is very thin and can call the Data class (which implements the above interface) to do whatever it needs. Meanwhile Data will actually call another class (Database) to do the real work of searching, reading, creating etc etc. Does this seem reasonable?
On a side note: why are we being given a specific interface to implement in a problem description? In my experience this simply wouldn't happen. You would get incomplete requirements and be forced to make trade-offs etc but this interface is a bit of a pain
I would just stick to the "must" requirements and don't do any extras, because you may only loose points for functionalities which where not required (and you certainly won't receive extra credit).
So you'll have to implement the interface you got (with delete and create methods), but in the gui a user will only can search for rooms and book a room. So the create and delete methods will be not referenced at all. But you should provide well functioning create and delete methods. You could use a JUnit test-case for example to make sure these methods (and/or all other methods from Data class) work as expected.
why are we being given a specific interface to implement in a problem description? In my experience this simply wouldn't happen.
I had already a project where some company was responsible for implementing the back-end (business service and database stuff) and I was responsible for developing the front-end. Because I knew what to expect (because I had the interface) I created a dummy implementation and could develop the front-end, so front-end and back-end could be developed concurrently by 2 different teams/companies.
And of course it's just because with these requirements there will be some frame of reference to grade these assignments, which will result in a more objective score: everybody has similar requirements to implement, otherwise you make an application with all the trimmings and I make a very simplistic application with just 2 functions: book a room and search rooms. To get an objective score will be a lot harder. And I notice how many troubles people (developers) have with just doing what is asked and nothing more. Nonetheless this assignment will be a true challenge (it was for me).
You must implement all the methods of the interface provided by Sun/Oracle. Otherwise, if you
don't, since it is a must requirement, you will fail.
I got the URLyBird assignment and all the assignments vary and are a bit different from each other
but the whole idea is that when you are faced with multiple options you choose the option
that best fits the requirements: simple code easy to read and maintain by a junior developer
that could easily extend and add functionality to the building blocks you create in your assignment.
If yours is similar to mine at the most at a high level you have to implement 2 main features
in your application: search and book or reserve.
These will eventually call your Data class API: find(), read() and lock(), update() and unlock().
Whenever you are faced with several options make sure to justify them in your choices.txt file.
I see the reasoning for it now. I was just getting a little frustrated because I felt I could've implemented a solution which was still pretty generic without using the Data class at all.
I suppose the reason I've never seen this type of requirement (implement an interface) is because I work on message driven projects where I'm given format of messages rather than being given a specific API to implement. Maybe in a future role