[URLyBird] Should I use a business object or String[] in my Data class?

[Georgiana Lungu]

Hello,

I have done an implementation and, again, the thought that the design might become inappropriate is bothering me.
Thing is like this, as in my supplied interface from Sun, most of the methods take or return String Arrays as arguments and as I use byte Arrays to write data into file, I found natural to make a business object aut of my Accomodation instead of just a value objects and I decided to implement the business ruls directly here:
pad the fields with spcaes when it is the case directly in this class setters,
made 3 constructors, 1 nonargument, 1 that takes a byte[] and looks like this:

  
    public Accomodation(byte[] byteArray) 
	    throws UnsupportedEncodingException {
	int offset = 0;
	validFlag = new String(byteArray, offset, VALID_FLAG_LENGTH, "UTF-8");
	offset = VALID_FLAG_LENGTH;
	name = new String(byteArray, offset, NAME_LENGTH, "UTF-8");
	offset = NAME_LENGTH;
	location = new String(
		byteArray, offset, CITY_LOCATION_LENGTH, "UTF-8");
	offset += CITY_LOCATION_LENGTH;
	size = Integer.parseInt(
		new String(byteArray, offset, ROOM_SIZE_LENGTH, "UTF-8"));
	offset += ROOM_SIZE_LENGTH;
	smokingFlag = new String(
		byteArray, offset, SMOKING_FLAG_LENGTH, "UTF-8");
	offset += SMOKING_FLAG_LENGTH;
	rate = new String(byteArray, offset, RATE_LENGTH, "UTF-8");
	offset += RATE_LENGTH;
	date = new String(byteArray, offset, DATE_LENGTH, "UTF-8");
	offset += DATE_LENGTH;
	owner = new String(byteArray, offset, DATE_LENGTH, "UTF-8");
    }
  

and one that takes a String[] and also sets the values of the fields

I also have these two methods:

  
    public String[] toStringArray() {
	return new String[] { 		
		name, 
		location, 
		Integer.toString(size),
	        smokingFlag, 
	        rate, 
	        date, 
	        owner};
    }
    
    public byte[] toByteArray() throws UnsupportedEncodingException{
	String entireRecord = validFlag + name + location + size + smokingFlag
		+ rate + date + owner; 
	
	return entireRecord.getBytes(ENCODING);
    }
  

I could use an opinion about this

And since I am here, one more question, may i presume that recNo "n" corresponds with n'th record found in file?

[Ryan Hamilton]

I never placed my conversion functions Accommodation<->ByteArray in the Accomodation class as I felt that what should Accomodation know about one particular byte format to represent its data. I felt it was more appropriate such a function would go in a "lower level" object. In my case FileStore. As if I wanted in future to make a DatabaseStore that returned Accomodation objects. It would seem even weirder for accomodation to have a byte conversion function.

Your recNo question:
- Again if you think about protecting against change. recNo should not be considered nth record in file. But just as a unique identifier.
- If you reuse record numbers you should consider the scenario where:

User Alice performs a search

User Bob performs a search

Bob books recNo 1

Administrator deletes recNo 2

Administrator adds new record which is given recNo 2

Alice goes to book recNo 1 or 2 - as displayed in her search

As you can see Alice may attempt to book a room which no longer exists, was booked, was deleted and/or has changed.

Thats just what I think. I am curious how do you handle them situations?

[Georgiana Lungu]

You are right about the method converting to bytes, I gave that up. And also I gave up the setters padding thing as the code become faaaar to ugly amd it was really no worth, because as you said, makes Accomodation application specific(file database) and can become of no use for long term. So i removed Accomodation <> byte[]. Though, I am thinking to keep the Accomodation <> String[] conversion, cause otherways, I don't see much use of the Accomodation object itself, since I am directly taking and returning String[] accordingly to Sun interface... Am I wrong?

My question abuot the n-th record was actually pointing this: read(int recNo) is supposed to return the n-th record in the file, 193 + n * RECORD_LENGTH , that is, excluding the begining section of the file and the prievious records? I was just talking about position in the file, not design considerations.

[Roel De Nijs]

I will give you my remarks:

I would never add a business object, like Accomodation to my Data class. Simply because it makes your Data class not reusable. Your Data class is nothing more than a DAO. I just worked with String[] in my Data class, also because all my interface methods have String[] in their signatures. This makes my Data class a reusable component: I can reuse the Data class to manage a database file containing customers with a few, very small changes (also because I decided to read the database file structure dynamically). Code reusability is one of the main advantages of object-oriented development.

the values in my String[] are trimmed, so not padded with spaces. I pad the values with spaces when I'm writing the values to the file

I use a business object (just as a transfer object) in my business service, so I can use it in my client as well (because using an object is easier and less error-prone than having to handle an array). So I have an utility class which has 2 methods to convert a String[] into an instance of the business object, and vice versa.

the "deleted" flag is not a part of my String[], nor is it a part of my business object. Because when the "deleted" flag represents a deleted record, the record is deleted, it does NOT exist at all, so why would you then create a String[] (or an Accomodation object) just to set its deleted-property to true? The String[] (and the Accomodation object) should just be null (that's what I did )

I used the record number as the primary key of my records (and business objects), because in the URLyBird assignment there is no other field (or combination of fields) which is appropriate as primary key. So you can use this record number to calculate the position of the record in the database file.

Ryan Hamilton wrote:As you can see Alice may attempt to book a room which no longer exists, was booked, was deleted and/or has changed. I am curious how do you handle them situations?

That's why my business service method "book a room" might throw an exception that a room is already booked. If a room is already booked, your application should take care of this situation. Because double bookings will result in customers, which might lead to bad publicity, which might lead to bankrupcy of URLyBird and you (as a developer of its IT department) losing your job
The other situation (booking a room that was deleted and created or just changed) I didn't handle at all (although I reuse the record number of deleted entries, because for the simple reason: there is no possibility to delete, create or update room records. The application just has 2 functions: search rooms (read-only) and book a room (which is an update of 1 specific field, which I handled as described just above). So when new functionality is added to the application to delete, create and/or update rooms; you'll have to handle these situations by throwing an InconsistentRoomException for example. And there are different alternatives on how to implement this behavior: you can add a version number (like Hibernate does), you can compare the value of important fields, you can stop reusing the record number of deleted entries,...

These are just my 2 cents, nothing more than just my opinion. You don't have to agree with them at all, and you are not required to change your implementation based upon my remarks. I just described how I implemented this assignment and handled these situations. Whatever decision you make, don't forget to justify your decision in the choices.txt file.

Hope it helps!
Kind regards,
Roel