The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Class design help

I have a class called RoomType,part of Hotel entity.RoomType has roomrate.Now,there are two cases..In one case it has a single rate(whatever be the group size),and in another case it has 2 rates(depending on the size of group wanting to book rooms).I am thinking of defing 3 enums for these type of rates,and when I create roomrate object,i will define what type it is using enum.
thks
vishy
Tuesday, August 08, 2006
 
 
How likely is it that a hotel might want to change its rates, do you figure?

Is it ever possible that two rooms of the same RoomType might be billed at a different rate?

Are there operations you may want to do on room rates? Say, add some of them up to get the total bill, or multiplying by a tax rate?  Does adding enums sound like a good idea?

Wouldn't it be better to ask the teacher of the class questions like this? Immediate feedback, and all that.


(Don't do it.)
Mark Jeffcoat Send private email
Tuesday, August 08, 2006
 
 
Re-reading the question, I find it more ambiguous than I did the first time. I was talking about making RoomRate an enum; I don't see any problem offhand with RoomType.SMALL and RoomType.BIG.
Mark Jeffcoat Send private email
Tuesday, August 08, 2006
 
 
In most cases when I have booked hotels, the rate is not solely determined by the time of room, but by seasonal variation, day of week, length of stay and promotional affiliations, so no I wouldn't put the rate in the type class.
Cade Roux Send private email
Tuesday, August 08, 2006
 
 
A rule of thumb is, whenever you're tempted to use an enum, to consider using an interface or abstract base class instead, for example:

interface IRoomType
{
  double getRate(int groupSize);
}

class RoomTypeOneRate : IRoomType
{
  double m_rate;
  RoomTypeOneRate(double rate) { m_rate = rate; }
  double getRate(int groupSize) { return m_rate; } //rate is independent of groupSize
}

class RoomTypeTwoRates : IRoomType
{
  double m_rate1;
  double m_rate2;
  int m_groupSize;
  RoomTypeTwoRates(...etc...) { ...etc... }
  double getRate(int groupSize) { return (groupSize < m_groupSize) ? m_rate1 : m_rate2; } //rate depends on groupSize
}
Christopher Wells Send private email
Tuesday, August 08, 2006
 
 
As an extension to what Christopher Wells was saying, using an enum is probably a bad idea, put it in a class instead.

If you are looking at going beyond the simple case of small room = $x  and big room = $y, you might want to look into the decorator pattern.

interface IRoom
{
  double getRate();
  string description{ get; }
}

public class SmallRoom : IRoom
{
  double getRate(){ return $10 }
  string description{ get{ return "Small Room"; }
}

public class LargeRoom : IRoom
{
  double getRate(){ return $20 }
  string description{ get{ return "Large Room"; }
}

public class KingBed : IRoom
{
  private IRoom _parent;
  public KingBed(IRoom parent)
  {
    _parent = parent;
  }

  double getRate()
  {
    return $25 + _parent.getRate()
  }
 
  string description{ get{ return ", King Bed"; }
}

public class TwoDoubleBeds : IRoom
{
  private IRoom _parent;
  public TwoDoubleBeds (IRoom parent)
  {
    _parent = parent;
  }

  double getRate(int groupSize)
  {
    return $15 + _parent.getRate(groupSize)
  }
 
  string description{ get{ return parent + ", with two double beds"; }
}

usage:

class BookRoom
{
  IRoom room = new SmallRoom()
  room = new KingBed (room);

  Console.WriteLine(room.Description);  //"Small Room, King bed"
  Console.WriteLine(room.getRate); //"$35"
}

Then you can add seasonal decorators, amenity decorators, etc
Another Anonymous Coward
Tuesday, August 08, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz