#liskov

No mundo do desenvolvimento de software, é fundamental que os princípios de design sejam seguidos para criar sistemas escaláveis e manuteníveis. Entre os mais importantes estão os princípios SOLID, um acrônimo que representa cinco princípios de design orientado a objetos. Neste post, focaremos no ‘L’ de SOLID – o Princípio da Substituição de Liskov (LSP). Esse princípio foi nomeado como…

Single responsibility principle 

Open / Close principle

Liskov substitution

Interface segregation

Dependency injection

Rigidity

The design is difficult to change

Fragility

The design is easy to break

Immobility

Design is difficult to reuse

Viscosity

Difficult to do the right thing

Single Responsibility

Single class should have single responsibility. Class should have only one reason to change. Each class should do one thing and do it well.

Open Close Principle

Open for extensibility, closed for modification. Interfaces are not designed, interfaces are discovered when system grows. (Rule of three - start to generalize when something appears 3x. If there are two similar cases, it is not large for generalize). Anyone should be able to extend functionality (inheritance or composition (strategy pattern, decorator pattern as wrapper)). For getting correct strategy we can use Factory method. We should prefer composition over inheritance.

 Liskov Substitution Principle

Subtypes must be substitutable for their base types. If we flip any implementation of interface system will working correctly. i.e. ReadOnlyCollection<T> is implementing ICollection. If we call Add on ReadOnlyCollection it always throws NotSupportedException. VIOLATES LISKOV because correctness of the system is broken.

Extracting interfaces is the most common way of violating.

Interface Segregation Principle

Clients should not be forced to depend on methods they don’t use. We should prefer role interfaces over header interfaces (extracted from classes, old fashioned way).

ISP Protects over LSP violation

Role interfaces - just a few members i.e. one member.

Dependency Injection

Substitutability is a principle in object-oriented programming. It states that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conferencekeynote address entitled Data abstraction and hierarchy. It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. Barbara Liskov and Jeannette Wing formulated the principle succinctly in a 1994 paper as follows:

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

As I continue to work on refactoring my Java TTT application, I wanted to revisit the the Liskov Substitution Principle (LSP), one of the SOLID principles from Agile Software Development, Principles, Patterns, and Practices [Robert C. Martin]. I haven't blogged about this principle before, and I think that it will be helpful as I refactor my Java TTT classes.

To summarize the LSP, subclasses, which extend base classes, should be substitutable for their bases classes. In other words, you should be able to replace all instances of a base class with any of its subclasses without breaking the application.

A popular example describes a Square class as a subclass of a Rectangle class with width and hight getter and setter methods. This implementation violates LSP because a square's height and width shouldn't be changed independently, whereas this would be okay for rectangles.

In my Java TTT application, I had originally had both my AlphaBetaPlayer class, which was responsible for scoring potential moves based on whether the marker was for the current player (maximizing) or the opponent (minimizing), and my HumanPlayer, ComputerPlayer, and AIPlayer classes, extend my AbstractPlayer class. I choose to implement this design because some of the methods (getMarker(), getOpponent(), and addMarker()) were common among all of the classes.

However, the implementation was  somewhat confusing, and it violated the LSP.

For example, if you were to substitute the AlphaBeta player class for the AbstractPlayer class, it would produce errors. The AbstractPlayer class defines an addMarker() method that takes strings and adds markers to the cell corresponding to the string value. AlphaBeta, on the other hand, adds markers according to the cells array index value for the purpose of getting the score for potential move scenarios.