What is the Liskov Substitution Principle and how is…

The Liskov Substitution Principle (LSP) states that objects of subclasses should be able to replace objects of the superclass without affecting the correctness of the program.

Application in Android development:

Class hierarchies: When designing class hierarchies (e.g., inheriting from View, Fragment, Activity), LSP ensures that using an instance of a subclass instead of a superclass does not lead to unexpected behavior.

Interfaces: If a class implements an interface, it should do so in a way that it can be used wherever the interface type is expected, without violating the consumer's expectations.

// Incorrect (violates LSP)
// The Printer interface expects print() to always print something
interface Printer {
    fun print(document: String)
}

class BasicPrinter : Printer {
    override fun print(document: String) {
        println("Printing: $document")
    }
}

class BrokenPrinter : Printer {
    override fun print(document: String) {
        // Sometimes prints nothing, violating the interface contract
        if (Math.random() > 0.5) {
            // Do nothing
        } else {
            println("Printing: $document")
        }
    }
}

// Correct (adheres to LSP)
class SimplePrinter : Printer {
    override fun print(document: String) {
        println("Printing: $document")
    }
}

class MockPrinter : Printer {
    override fun print(document: String) {
        // Always performs an action consistent with the contract (even if just simulated)
        println("Mock printing: $document")
        // Could log or perform other expected actions
    }
}

Testing: Adhering to LSP simplifies testing, as mocks or stubs (which are subtypes) can be substituted for real implementations without changing the test logic.

Contracts: LSP emphasizes the importance of following method contracts — all expected preconditions, postconditions, and invariants (object state). A subclass should not weaken preconditions or strengthen postconditions of the parent class.

Condition	Parent class (Supertype)	Subclass (Subtype)
Precondition	Can be weakened	Should be the same or weaker
Postcondition	Can be strengthened	Should be the same or stronger
Invariant	Must be maintained	Must be maintained as strict or stricter
Exceptions	Can throw `X`	Can throw `X` or subtype `X`

What is the Liskov Substitution Principle and how is it applied in programming?