How would you design an object oriented solution to compute areas for multiple shapes in a polymorphic way?

How would you design an object oriented solution to compute areas for multiple shapes in a polymorphic way?

• A. Create separate area methods in each shape class and dispatch manually.
• B. Use a single global function that handles all shapes.
• C. Define a Shape interface with an area method and implement Circle and Rectangle; call area() polymorphically on a collection of Shape.
• D. Store shapes as primitive types and use type checks to compute area.

Answer: (C)

Using a common abstraction and polymorphism lets you treat all shapes the same way while letting each shape provide its own specific area calculation. Define a Shape interface (or abstract class) that requires an area method. Each concrete shape, like Circle and Rectangle, implements that method with its own formula. When you keep shapes in a collection of Shape and iterate, you call area() on each item and the runtime dispatches to the correct implementation. This means you don’t need to know which shape you have to compute its area; you just rely on the contract that every Shape can provide an area. It also makes the design easy to extend: add a new shape by implementing Shape, and it automatically works with existing code that processes Shape objects. For example: interface Shape { double area(); } class Circle implements Shape { double radius; double area() { return Math.PI * radius * radius; } } class Rectangle implements Shape { double width, height; double area() { return width * height; } } List<Shape> shapes = Arrays.asList(new Circle(2.0), new Rectangle(3.0, 4.0)); for (Shape s : shapes) System.out.println(s.area()); The other options miss this polymorphic approach. Having separate area methods in each class requires manual dispatch and tight coupling to specific types. A single global function that handles all shapes centralizes logic and breaks the polymorphic handling that lets each shape own its behavior. Storing shapes as primitive types and using type checks reintroduces conditional logic, undermines encapsulation, and makes it harder to add new shapes without touching the dispatch code.

Using a common abstraction and polymorphism lets you treat all shapes the same way while letting each shape provide its own specific area calculation. Define a Shape interface (or abstract class) that requires an area method. Each concrete shape, like Circle and Rectangle, implements that method with its own formula. When you keep shapes in a collection of Shape and iterate, you call area() on each item and the runtime dispatches to the correct implementation. This means you don’t need to know which shape you have to compute its area; you just rely on the contract that every Shape can provide an area. It also makes the design easy to extend: add a new shape by implementing Shape, and it automatically works with existing code that processes Shape objects.

For example:

interface Shape { double area(); }

class Circle implements Shape { double radius; double area() { return Math.PI * radius * radius; } }

class Rectangle implements Shape { double width, height; double area() { return width * height; } }

List shapes = Arrays.asList(new Circle(2.0), new Rectangle(3.0, 4.0));

for (Shape s : shapes) System.out.println(s.area());

The other options miss this polymorphic approach. Having separate area methods in each class requires manual dispatch and tight coupling to specific types. A single global function that handles all shapes centralizes logic and breaks the polymorphic handling that lets each shape own its behavior. Storing shapes as primitive types and using type checks reintroduces conditional logic, undermines encapsulation, and makes it harder to add new shapes without touching the dispatch code.