My coworker Lyubo came up with the following OOP problem while we were having lunch the other day. He says it is a well known problem that you can see on numerous places but it is new to me.

   We know from mathematics that the square is a special case of rectangle. In OOP terms "special case" means inheritance. Obviously the mathematical square inherits from mathematical rectangle. Your task is to create OOP model for that relationship. Lets say that we want the rectangle to expose get property (getter for you Java readers) – the area of the rectangle. This is not as simple as it sounds. Here is one of the simplest (and very wrong) solutions:

   class Rectangle
   {
       /// <summary>
       /// A side of the rectangle
       /// </summary>
       public uint A { get; set; }

       /// <summary>
       /// B side of the rectangle
       /// </summary>
       public uint B { get; set; }

       virtual public uint Area
       {
           get { return A * B; }
       }
   }

   class Square : Rectangle
   {
       public override uint Area
       {
           get
           {
               return A * A;
           }
       }
   }

However this means that the B property is not actually used. This can lead to unexpected results in polymorphic client code. We expect a rectangle to have a area of A*B and somehow it will not if it is an instance of Square. We can override the property setters, add some exceptions but what inheritance means is that the child class can do ANYTHING that the base class can. If you need to add special case behavior for any of the child classes then the inheritance hierarchy you have created is simply wrong. So go ahead make it right... (or read ahead for explanation)

I am proud to say that after giving several wrong answers I found the correct one on my own. Here is the right implementation:

   class Rectangle
   {
       private Rectangle()
       {
       }

       public Rectangle(uint a, uint b)
       {
           this.a = a;
           this.b = b;
       }

       private uint a;

       /// <summary>
       /// Gets A side of the rectangle
       /// </summary>
       public uint A
       {
           get { return a; }
       }

       private uint b;
       /// <summary>
       /// Gets B side of the rectangle
       /// </summary>
       public uint B
       {
           get { return b; }
       }

       public uint Area
       {
           get { return A * B; }
       }
   }

   class Square : Rectangle
   {
       public Square(uint a)
           : base(a, a)
       {
       }
   }

   That is right the classes should be immutable. Why? Because the mathematical objects that they represent are in fact immutable. If we want to use the relationship that mathematics teaches us we must conform to its rules. As most objects in mathematics geometric figures are immutable. There is no assignment operator nor setters in mathematics.

   On a side note functional programing that is supposed to be more mathematical makes heavy use of immutability. Now I see why.