Deep Dive

Explain design tradeoffs you considered. Check and explain whether your design adheres to SOLID principles. Explain how your design can handle changes in scale and whether it would be easy to extend with new functionalities. Identify areas for future improvement...

Design tradeoffs

Strategy + Factory for fee calculation vs. a single method. Your earlier version had one CalculateFee with a hardcoded $10/hour. The current design splits fee logic into three independent dimensions — time-of-day, vehicle type, spot type — each behind its own factory and strategy. The tradeoff: you traded a one-line method for roughly a dozen classes and interfaces. What you bought is that each pricing dimension can change independently (add a "weekend" time strategy without touching vehicle pricing), and the dimensions combine additively in CalculationStrategy. The cost is real, though: for a system this size it's arguably over-engineered, and there's a subtle bug hiding in the complexity (more below). A middle ground would have been a single IPricingStrategy with the three rules inlined, split out only when a second pricing scheme actually appeared.

Linear search vs. indexed lookup. AssignParkingSpot scans every spot on a floor until one fits; HandleExistRequest scans every floor's spot list to find the one matching the ticket. This is O(spots) per operation. The tradeoff is simplicity over speed — fine for a demo, but it directly contradicts your non-functional requirement of "efficient data structures for fast lookup." You accepted simple code now at the cost of performance at scale.

Attendant as a thin facade vs. giving it real responsibility. ParkingAttendant currently just forwards to IParkingLot with identical method signatures. The tradeoff: it adds an indirection layer that today does nothing, but it gives you a natural seam to later add attendant-specific concerns (multiple attendants, request queuing, logging) without touching the lot. Right now it reads as ceremony; whether it pays off depends on whether those concerns ever materialize.

Coarse-grained locking vs. fine-grained. Each floor has a static lock object shared across all floor instances. This serializes every assignment across the entire lot — safe, but it throttles concurrency to one assignment at a time system-wide. The tradeoff was correctness-simplicity over throughput, but the static is almost certainly a mistake rather than an intentional tradeoff (see scale section).

SOLID adherence

Single Responsibility — mostly good, with cracks. Most classes have one clear job: ParkingSpot knows fitting, ParkingFloor manages spots, each fee strategy owns one rule. The crack is ParkingLot.HandleExistRequest, which does ticket lookup, spot release, fee calculation, and payment orchestration in one method. That's four responsibilities in one place. ParkingTicket also mixes being a data record with implementing IParkingTicket (a factory that creates other tickets) — the object is both the product and the factory, which muddies its responsibility.

Open/Closed — strong for pricing and payment, weak elsewhere. Adding a new payment type or a new fee-strategy dimension is clean-ish, but the factories violate OCP: PaymentFactory.CreatePayment is an if/else chain on a string, so adding "ApplePay" means editing that method. Same for the three fee factories. True OCP would register strategies in a dictionary or use DI so new types plug in without modifying the factory. And CanFit hardcodes the vehicle-to-spot rules in a conditional — a new vehicle type forces you to edit that method.

Liskov — a genuine violation lurking. Your vehicle-type fee strategies each check the type and return 0 if it doesn't match (CarTypeWiseFeeStrategy returns 20 only for a car, else 0). This means the factory could hand you the wrong strategy and it would silently return 0 rather than fail. The strategies aren't cleanly substitutable — each only works for its one input, so passing the "wrong" vehicle produces a wrong-but-silent answer. A cleaner design has each strategy assume it's only ever called for its type, or returns a rate without re-checking.

Interface Segregation — good. Interfaces are small and focused (IParkingSpot has three methods, IPaymentStrategy has one). Nobody's forced to implement methods they don't use. One nit: IParkingTicket bundles CreateTicket, CalculateDuration, and LookUpParkingTicketByParkingId — those are arguably three different concerns that a client rarely needs all of.

Dependency Inversion — this is the design's real strength. ParkingLot depends on IParkingTicket, ICalculationStrategy, IPaymentFactory — all abstractions, all injected via constructor. CalculationStrategy depends on factory interfaces. This is textbook DIP and it's what makes the system testable. The one leak: ParkingLotBuilder news up all the concrete classes itself, so the composition root is hardcoded rather than fed by a DI container — acceptable, since something has to know the concretes, but it means swapping implementations requires editing the builder.

Scale and extensibility

Where it holds up. Adding a new payment method, a new pricing dimension, or a new floor is genuinely easy — the interfaces absorb those changes. Supporting more floors is just more list entries; the multi-floor requirement is satisfied structurally.

Where it breaks under load. Three things bite as the lot grows:

The static object _lockObject on ParkingFloor is shared by every floor, so all assignments across all floors serialize through one lock. A 20-floor garage gets no more concurrency than a 1-floor one. This should be a per-instance lock (drop static), and ideally per-spot-type so different vehicle classes don't contend.

The linear scans mean lookup cost grows with lot size. At thousands of spots, both entry (find a fit) and exit (find the ticket's spot) get slow. Fixing this means maintaining an availability index — e.g. a Queue<ParkingSpot> per spot type per floor for O(1) assignment, and a Dictionary<int, ParkingSpot> keyed by spot id for O(1) release.

Ticket lookup is a LINQ Where over the full ticket list on every exit — also linear. A Dictionary<Guid, ParkingTicket> makes it O(1) and directly serves your "fast ticket validation" requirement.

Extensibility verdict. New pricing/payment/floors: easy. New vehicle types or spot types: not easy — you'd edit CanFit, add a vehicle fee strategy and factory branch, add nothing for spot rules but touch the factory if/else. The design is extensible along the axes it was built for and rigid along the ones it wasn't.

Areas for future improvement

Ordered roughly by payoff:

Fix the concurrency correctness bug. The static lock is wrong, but there's a deeper issue: in AssignParkingSpot the CanFit check happens outside the lock and Assign happens inside. Two threads can both see the same spot as fittable, then both assign it. The check-and-assign must be atomic — move CanFit inside the lock, or lock per spot.

Wire lookups through dictionaries/queues as above — this is the single biggest step toward the stated performance and scalability NFRs.

Extract exit orchestration. Pull fee-calc + payment out of ParkingLot.HandleExistRequest into something like a CheckoutService, restoring single responsibility and making the exit flow unit-testable in isolation.

Separate the ticket record from ticket creation. Make ParkingTicket a pure data object and move CreateTicket into a dedicated TicketFactory/ITicketService. Right now a ticket instance creating other tickets is conceptually odd.

Replace factory if/else chains with a registry. A Dictionary<string, Func<IPaymentStrategy>> (or DI-registered map) makes payment and fee factories genuinely open/closed.

Make pricing configurable, not hardcoded. The rates ($10, $20, $30…) are baked into strategy classes. Your NFR calls for configurability without code changes — load rates from config so pricing changes don't require a recompile.

Harden input validation and the fee/duration coupling. HandleExistRequest handles a bad Guid gracefully now (good), but note CalculationStrategy recomputes duration internally while ParkingTicket.CalculateDuration also exists and is never called — dead code signaling the duration concern isn't cleanly owned. Pick one home for it.

Add transactional integrity. Your ACID NFR isn't met — if payment fails after the spot is freed, the spot is lost and no money collected. The exit sequence needs a defined ordering (calculate → collect payment → only then release) or compensation logic.

Introduce a real DI container at the composition root so ParkingLotBuilder stops hand-newing dependencies.

The short version: the design's spine — dependency inversion through injected interfaces — is solid and is what makes everything else improvable without a rewrite. The gaps are concentrated in the runtime concerns (concurrency correctness, lookup performance, transactional safety) that the class structure alone doesn't address, plus a couple of factories that promise open/closed but deliver if/else.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10