Room class and conversion methods package location

[Carlos Morillo]

Hello Everybody,


I moved my Room class out the suncertify.db package where I have my Data class to a suncertify.domain package
where I intend to have all the business logic code.

I wrote a couple of conversion methods:

- Room to String[] and
- String[] to Room

and at the moment they are part of my Room class.

Does this sound like a reasonable approach?
Any pros and cons?


Thanks in advance,


Carlos.

[Roel De Nijs]

Hi Carlos,

I created a RoomUtils utility class (in a util package) which has both conversion methods and a whole lot other utility methods (e.g. see if a room is booked, filter list of rooms for exact matches,...).

Kind regards,
Roel

[Roberto Perillo]

Howdy, Carlos!

Does this sound like a reasonable approach?

Champion, I'd say that, even it the Room class is indeed a domain class, it depends on how you are organizing the domain logic. If you are organizing it with Transaction Scripts, then it is better to have a utility class to do that (which is what I did too), so that the Room class will simply be a DTO. If you are organizing it with a Domain Model (which I would not advise for the solution of this problem), then it is better to have these methods in the Room class.

[Carlos Morillo]

Hi Roberto,


Could you please elaborate a bit further?
I don't quite clearly understand what you are saying.

I do see the Room object as a Value Object.


Thanks,


Carlos.

[Roberto Perillo]

Howdy, Carlos!

First, here's an interesting text by Martin Fowler about value objects:

You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality.

Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead.

Transaction scripts is an object-oriented procedural approach. In this case, you'll only have DTOs, which will be responsible for carrying data back and forth between the database all way up to the presentation layer. A DTO usually reflects the same structure as of a database table. For this approach, it is a good idea to have a utility class that transforms Room -> String [] and vice-versa.

On the other hand, if your design is based on a model, and you have MDD, then the entities of your domain will hold the domain logic, and in this case, it would be a good idea to have the logic of Room -> String [] in the Room class. However, it is sort of impossible to see the Room class as an entity (even though it sound like one), because its strucutre do not provide anything that we can see as an identity.

In a nutshell: in a real-world scenario, it would depend on how you are organizing the design of your architecture. For this assignment, you can go for the utility class and you'll do well!

[Carlos Morillo]

Hi Roberto,

On the other hand, if your design is based on a model, and you have MDD,

What does MDD stand for?

Thanks,


Carlos.

[Andriy Pererva]

What does MDD stand for?

Model-Driven Design