How do SOLID principles apply in LLD design?

Direct Answer

SOLID principles guide LLD design: Single Responsibility Principle means each class has one clear purpose (ParkingSpot manages occupancy, not billing). Open/Closed means you extend behavior through subclasses or interfaces, not by modifying existing code. Liskov Substitution means subclasses can replace parent classes without breaking functionality. Interface Segregation means using focused interfaces instead of one fat interface. Dependency Inversion means depending on abstractions like interfaces, not concrete classes.

Deep Dive & Architecture

SRP and OCP shape the responsibilities

ParkingSpot manages occupancy while FeeCalculator owns pricing. That is Single Responsibility. Pricing is Open/Closed when a weekend or electric-vehicle rule is added as another FeePolicy implementation rather than another branch inside the exit service.

LSP and ISP protect contracts

Liskov Substitution means every implementation must honour the promises of its interface. If ElectricSpot extends ParkingSpot but throws from a normal park() call, the hierarchy is misleading. Interface Segregation avoids that problem by using focused capabilities such as Parkable and Chargeable instead of one large spot interface.

DIP keeps orchestration testable

An ExitService can receive FeePolicy and PaymentGateway abstractions through its constructor. A test then supplies small fakes, while production supplies real implementations. SOLID is useful when each principle explains a concrete design decision; it is not a reason to add interfaces that have no alternative behaviour or testing value.

Code Example

// DIP: high-level ParkingLot depends on the FeeCalculator abstraction, not a concrete class
interface FeeCalculator { BigDecimal calculate(ParkingTicket t); }

class ParkingLot {
    private final FeeCalculator fee;                 // abstraction
    ParkingLot(FeeCalculator fee) { this.fee = fee; } // injected
}
// OCP: add weekend pricing without editing ParkingLot
class WeekendFeeCalculator implements FeeCalculator {
    public BigDecimal calculate(ParkingTicket t) { /* new rule */ return BigDecimal.TEN; }
}

New pricing = new class (Open/Closed); the lot depends on the interface (Dependency Inversion).

Common Mistakes & Pitfalls

• Reciting SOLID as definitions — show it in the design (split a class, inject an interface).
• LSP violations — a subclass that throws on an inherited method breaks substitutability.
• Fat interfaces — forcing implementers to stub methods they don't need (ISP).
• Depending on concretes — new MySqlRepo() inside a service couples them; inject the interface (DIP).