I'd probably model the hotel as an object Hotel
, the room as an object Room
etc. rather than stacking everything together in a multi-tiered collection. That becomes very verbose very quickly, and as soon as you change the relationships then that change is reflected throughout your code.
Each object then contains references to its components (Hotel
contains a list of Room
s etc.). Once you do this I think everything should become a lot clearer. Furthermore your Hotel
object understands how to find Room
s, the Room
objects understand how to get its attributes and your calling code becomes a lot less verbose, and a lot less dependent on the Hotel
/Room
implementation. e.g. you can do this:
Hotel hotel = new Hotel();
Set<Room> rooms = hotel.getFreeRooms(RoomType.NON_SMOKING);
and so your objects do the work for you (the client) rather than you navigating the object hierarchy and doing the work yourself.
That's the ultimate goal of OO. As soon as I find myself putting together collections of collections, that's often an indicator that a new object class is required.