Section 1.1: The Square and Rectangle Dilemma

In the context of software development, an experienced developer might argue that a square should NOT be classified as a rectangle. The rationale behind this perspective is quite straightforward. Let's examine the class abstractions for both Rectangle and Square:

class Rectangle {

length: number;

width: number;

getArea(): number {

return this.length * this.width;

}

}

class Square {

size: number;

getArea(): number {

return Math.pow(this.size, 2);

}

}

These classes are fundamentally different. The Rectangle class has properties for both length and width, while the Square class has only a single property, size. Attempting to implement Square extends Rectangle or vice versa would violate important best practices, specifically the Liskov Substitution Principle from the SOLID principles, as well as the is-a relationship principle. Hence, we conclude that a square does NOT fit the definition of a rectangle.

Photo by Vincent LaVigna on Unsplash

Section 1.2: Shared Properties and Interface Design

However, claiming that there is no relationship between these two classes would also be incorrect. What do they have in common? Both classes implement the getArea method.

So, how can we establish a connection between these classes in software without contravening the Liskov Substitution Principle or the is-a relationship? The answer lies in using interfaces:

interface Shape {

getArea(): number;

}

class Rectangle implements Shape {...}

class Square implements Shape {...}

The Interface Segregation Principle, another tenet of SOLID, comes to the rescue here. This principle advocates for smaller, more specialized interfaces. By creating a Shape interface that includes shared properties among Rectangle, Square, and any future shapes, we can adhere to both the Liskov Substitution Principle and the is-a relationship.