design of this small programe?

Question

Kindly don't mind my question as it is a little theoretical.

Last week I gave an interview for job where I was given an assignment to and later they ask question and my design was faulty. So I couldn't get the job. I am sharing my design. Please see it and suggest me where I am wrong and what solution will be a good design of it.

Problem This is a package for a construction company who builds swimming pools. Swimming pool has 2 parts swimming pool surrounding area and pool it self. Both (pool and surrounding area) can be in rectangular or circular shape (please see attached picture) and so there will be 4 possible shapes. Program should calculate shaded area (outer area of pool to concrete).

****Formula** to calculate rectangular area** is Length * Width * 2 Formula to calculate circular area is 2 * 2.1718

My Design I made IPool Interface with 2 methods (1) CalculateCircularArea (2) CalculateRectangularArea. Made 2 classes (CircularPool, RectangularPool) implementing IPool interface.

Question What if there are more shapes other then rectangular and circular. Say if there are 100 other shapes, what solution will be considering future prospectus ? Here my design was not good as it was requiring change in interface when ever a new shape comes.

Answer 1

The design was already given in the question: A swimming pool has-a surrounding and it has-a inner pool. The task calls for composition rather then inheritance.

With that design we can invent other pool shapes and surroundings and still have swimming pools

public interface SwimmingPool {
  Surrounding getSurrounding();
  Pool getPool();
  double getOuterArea();
}

public interface Surrounding extends Shape{
  // some methods for surroundings
}

public interface Pool extends Shape {
  // some methods for pools
}

public interface Shape {
   double getArea();
}

Next you create concrete classes for rectangular and circular pools and surroundings use those modules to design swimming pools.

---

Now, we create a concrete swimming pool class:

public SwimmingPoolImpl implements SwimmingPool {
 private Surrounding surrounding;
 private Pool pool;
 public SwimmingPoolImpl(Surrounding surrounding, Pool pool) {
   this.surrounding = surrounding;
   this.pool = pool;
 }

 public double getOuterArea() {
   return surrounding.getArea() - pool.getArea();
 }

 public Surrounding getSurrounding() { return surrounding; }
 public Pool getPool() { return pool; }
}

Imagine, we have a library of dozens of differen pools and surroundings and we want to create a custom swimmingpool:

SwimmingPool customPool = new SwimmingPoolImpl(new OvalSurrounding(), new StarShapedPool());
double pavementArea =  customPool.getOuterArea();

That's it. Now we can mainatin a library of different pools and outer areas and use them immediatly to create swimming pools without having to change the swimming pool implementation. That's the benefit of composition.

Answer 2

I think a better design would be to have something like a IShape interface that exposes the getArea() method. (Or, even better, have it as a property).

This way, both your "objects" implement such interface, and you can calculate the area you want by simply taking the difference between the values of getArea().

Answer 3

A typical case for subclassing. Design an abstract class Shape with an abstract function getArea(), and make a concrete subclass for each possible form you have to deal with.

Pool or SurroundingArea just need to call getArea(), something like this:

public class SwimmingPool {
   Shape pool;
   Shape surrounding;

   public double geArea() {return pool.getArea() + surrounding.getArea()}
}

public abstract class Shape {
   public abstract double getArea();
}

public class Circle extends Shape {
   public double getArea() {
     // implementation of area calculation of circles
   }
}

public class Square extends Shape {
   public double getArea() {
     // implementation of area calculation of squares
   }
}

...

For pools or surroundings of other shapes, you just need to design another subclass of Shape.