{"title":"Law of Demeter","description":null,"content":"Have you ever called a method on an object… then chained another… and another… until the line looked like a trail of dots?\n\nOr made a small internal change to one class, and suddenly had to update code across five other layers?\n\nIf yes, you’ve probably run into a violation of one of the most overlooked design principles in software engineering: **The Law of Demeter (LoD)**.\n\nLet’s understand it with a real-world example and see why this principle matters more than you might think.\n\n---\n\n# 1. The Problem\n\nImagine you're building a simple e-commerce system.\n\nYou have:\n\n- A `Customer` who owns a `ShoppingCart`\n- The cart contains a list of `CartItems`\n- Each `CartItem` refers to a `Product`\n- And every `Product` has a `Price`\n\nNow let’s say you want to display the price of the **first product** in a customer’s shopping cart.\n\n\n```mermaid\nflowchart LR\n OS[OrderService]:::red --> CU[Customer]:::red\n CU --> SC[ShoppingCart]:::red\n SC --> LI[\"List of CartItem\"]:::red\n LI --> CI[CartItem]:::red\n CI --> PR[Product]:::red\n PR --> MO[Price]:::red\n\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nA common (but flawed) approach would be to write something like this:\n\n\n```java\nMoney price = customer.getShoppingCart().getItems().get(0).getProduct().getPrice();\n```\n\n```python\nprice = customer.get_shopping_cart().get_items()[0].get_product().get_price()\n```\n\n```cpp\nMoney price = customer.getShoppingCart().getItems()[0].getProduct().getPrice();\n```\n\n```go\nprice := customer.GetShoppingCart().GetItems()[0].GetProduct().GetPrice()\n```\n\n```csharp\nMoney price = customer.GetShoppingCart().GetItems()[0].GetProduct().GetPrice();\n```\n\n```typescript\nconst price = customer.getShoppingCart().getItems()[0].getProduct().getPrice();\n```\n\n\nLook at that chain. `OrderService` is coupled to **six** classes deep. It knows about the customer's cart, the cart's internal list, the structure of a cart item, the product inside it, and the price object. A change to any of these classes could break the `OrderService`, even though those classes have nothing to do with order processing.\n\nThis is called a **\"train wreck\"** or **\"dot-chaining\"**: one object reaching through several others to get what it wants. You start with a `Customer`, go into their `ShoppingCart`, peek into its internal list of `CartItems`, grab the first one, extract the `Product`, and finally get the `Price`.\n\nHere is the full function that uses this pattern:\n\n\n```java\nvoid displayFirstItemPrice(Customer customer) {\n Money price = customer.getShoppingCart()\n .getItems()\n .get(0)\n .getProduct()\n .getPrice();\n System.out.println(\"Price of the first item: \" + price.getAmount());\n}\n```\n\n```python\ndef display_first_item_price(customer):\n price = (customer.get_shopping_cart()\n .get_items()[0]\n .get_product()\n .get_price())\n print(\"Price of the first item:\", price.get_amount())\n```\n\n```cpp\nvoid displayFirstItemPrice(const Customer& customer) {\n Money price = customer.getShoppingCart()\n .getItems()[0]\n .getProduct()\n .getPrice();\n cout << \"Price of the first item: \" << price.getAmount() << endl;\n}\n```\n\n```csharp\nvoid DisplayFirstItemPrice(Customer customer)\n{\n Money price = customer.GetShoppingCart()\n .GetItems()[0]\n .GetProduct()\n .GetPrice();\n Console.WriteLine(\"Price of the first item: \" + price.GetAmount());\n}\n```\n\n```go\nfunc displayFirstItemPrice(customer *Customer) {\n price := customer.GetShoppingCart().\n GetItems()[0].\n GetProduct().\n GetPrice()\n fmt.Println(\"Price of the first item:\", price.GetAmount())\n}\n```\n\n```typescript\nfunction displayFirstItemPrice(customer: Customer): void {\n const price = customer.getShoppingCart()\n .getItems()[0]\n .getProduct()\n .getPrice();\n console.log(`Price of the first item: ${price.getAmount()}`);\n}\n```\n\n\nThis approach works. It compiles. It runs. But it **smells bad**, and it will cause real pain as your system evolves.\n\n---\n\n# 2. What’s Wrong With This?\n\n#### 1. High Coupling\n\nThe `OrderService` method is now tightly coupled to the **entire internal structure** of the customer and their cart.\n\n- If `ShoppingCart` changes how it stores items (e.g., using a `Map` instead of a `List`)\n- If `CartItem` renames its `getProduct()` method\n- Or if `Product` evolves to store pricing in a new way…\n\n**Boom.** Your `OrderService` code breaks. Even though it had nothing to do with those decisions.\n\n#### 2. Encapsulation Violation\n\nYou are reaching deep into object internals, violating encapsulation at multiple levels.\n\n- `Customer` exposes its `ShoppingCart`\n- `ShoppingCart` exposes its internal list\n- You assume the structure of that list\n- And even dig through `CartItem` and `Product` just to get a price\n\nEvery layer of reach is a layer of exposed internals. The whole point of encapsulation is to hide these details, and this code tears down every wall.\n\n#### 3. Maintenance Nightmare\n\nImagine this change: You switch from using a `Money` wrapper to a `BigDecimal` for price representation in `Product`.\n\nNow, every part of your codebase that dot-chased its way to `product.getPrice()` must be updated.\n\n#### 4. Testability Issues\n\nTesting `displayFirstItemPrice()` becomes a *mocking marathon*.\n\nTo test it in isolation, you'd need to mock:\n\n- A `Customer`\n- That returns a `ShoppingCart`\n- That returns a `List`\n- That returns a `CartItem`\n- That returns a `Product`\n- That returns a `Price`\n\nOne function. Six mocks. That is exhausting, fragile, and a clear sign something is wrong with the design.\n\n---\n\n# 3. Enter: The Law of Demeter (LoD)\n\n> **“Only talk to your immediate friends.”** — Law of Demeter\n\nThe Law of Demeter, also known as the **Principle of Least Knowledge**, was formulated in 1987 at Northeastern University during work on the Demeter project. Despite its age, it remains one of the most practical guidelines for writing maintainable object-oriented code.\n\nThe rule is straightforward. A method `M` on an object `O` should only call methods on:\n\n1. **Itself** (the object `O`)\n2. **Its own fields** (objects that `O` holds as instance variables)\n3. **Its method parameters** (objects passed into `M`)\n4. **Objects it creates** (objects instantiated within `M`)\n\nThat's it. In plain terms: **don't reach through one object to get to another.**\n\nIf you call `a.getB().getC().doSomething()`, you are violating LoD because you are reaching through `B` to talk to `C`. You should only be talking to `A`, and let `A` figure out how to get the job done.\n\n---\n\n# 4. Refactoring with LoD in Mind\n\nLet's rewrite the e-commerce example in a cleaner, more respectful way. The strategy is to **push the responsibility down** to the classes that own the data. Each class will expose a meaningful method instead of exposing its internals.\n\n#### Step 1: Add a method to `ShoppingCart`\n\nThe `ShoppingCart` knows about its items. So it should be the one to answer questions about them.\n\n\n```java\nclass ShoppingCart {\n private List items;\n\n // ... constructor, other methods ...\n\n public Money getFirstItemPrice() {\n if (items.isEmpty()) return Money.ZERO;\n return items.get(0).getProduct().getPrice();\n }\n}\n```\n\n```python\nclass ShoppingCart:\n def __init__(self):\n self._items = []\n\n # ... other methods ...\n\n def get_first_item_price(self):\n if not self._items:\n return Money.ZERO\n return self._items[0].get_product().get_price()\n```\n\n```cpp\nclass ShoppingCart {\nprivate:\n vector items;\n\npublic:\n // ... constructor, other methods ...\n\n Money getFirstItemPrice() const {\n if (items.empty()) return Money::ZERO;\n return items[0].getProduct().getPrice();\n }\n};\n```\n\n```csharp\nclass ShoppingCart\n{\n private List items;\n\n // ... constructor, other methods ...\n\n public Money GetFirstItemPrice()\n {\n if (items.Count == 0) return Money.ZERO;\n return items[0].GetProduct().GetPrice();\n }\n}\n```\n\n```go\ntype ShoppingCart struct {\n items []CartItem\n}\n\n// ... other methods ...\n\nfunc (sc *ShoppingCart) GetFirstItemPrice() Money {\n if len(sc.items) == 0 {\n return ZeroMoney\n }\n return sc.items[0].GetProduct().GetPrice()\n}\n```\n\n```typescript\nclass ShoppingCart {\n private items: CartItem[];\n\n // ... constructor, other methods ...\n\n getFirstItemPrice(): Money {\n if (this.items.length === 0) return Money.ZERO;\n return this.items[0].getProduct().getPrice();\n }\n}\n```\n\n\nNotice that `ShoppingCart` still reaches into `CartItem` and `Product`. That is fine here because `ShoppingCart` owns the items. The chain stays within the cart's own responsibility boundary. The important thing is that **external callers** no longer need to know about these internals.\n\n#### Step 2: Add a method to `Customer`\n\nThe `Customer` owns the `ShoppingCart`, so it should be the one to delegate cart-related queries.\n\n\n```java\nclass Customer {\n private ShoppingCart shoppingCart;\n\n // ... constructor, other methods ...\n\n public Money getFirstCartItemPrice() {\n return shoppingCart.getFirstItemPrice();\n }\n}\n```\n\n```python\nclass Customer:\n def __init__(self, shopping_cart):\n self._shopping_cart = shopping_cart\n\n # ... other methods ...\n\n def get_first_cart_item_price(self):\n return self._shopping_cart.get_first_item_price()\n```\n\n```cpp\nclass Customer {\nprivate:\n ShoppingCart shoppingCart;\n\npublic:\n // ... constructor, other methods ...\n\n Money getFirstCartItemPrice() const {\n return shoppingCart.getFirstItemPrice();\n }\n};\n```\n\n```csharp\nclass Customer\n{\n private ShoppingCart shoppingCart;\n\n // ... constructor, other methods ...\n\n public Money GetFirstCartItemPrice()\n {\n return shoppingCart.GetFirstItemPrice();\n }\n}\n```\n\n```go\ntype Customer struct {\n shoppingCart *ShoppingCart\n}\n\n// ... other methods ...\n\nfunc (c *Customer) GetFirstCartItemPrice() Money {\n return c.shoppingCart.GetFirstItemPrice()\n}\n```\n\n```typescript\nclass Customer {\n private shoppingCart: ShoppingCart;\n\n // ... constructor, other methods ...\n\n getFirstCartItemPrice(): Money {\n return this.shoppingCart.getFirstItemPrice();\n }\n}\n```\n\n\n#### Step 3: Update the `OrderService`\n\nNow the `OrderService` only talks to its direct friend: the `Customer`.\n\n\n```java\nvoid displayFirstItemPrice(Customer customer) {\n Money price = customer.getFirstCartItemPrice();\n System.out.println(\"Price of the first item: \" + price.getAmount());\n}\n```\n\n```python\ndef display_first_item_price(customer: Customer):\n price = customer.get_first_cart_item_price()\n print(\"Price of the first item:\", price.get_amount())\n```\n\n```cpp\nvoid displayFirstItemPrice(const Customer& customer) {\n Money price = customer.getFirstCartItemPrice();\n cout << \"Price of the first item: \" << price.getAmount() << endl;\n}\n```\n\n```csharp\nvoid DisplayFirstItemPrice(Customer customer)\n{\n Money price = customer.GetFirstCartItemPrice();\n Console.WriteLine(\"Price of the first item: \" + price.GetAmount());\n}\n```\n\n```go\nfunc displayFirstItemPrice(customer *Customer) {\n price := customer.GetFirstCartItemPrice()\n fmt.Println(\"Price of the first item:\", price.GetAmount())\n}\n```\n\n```typescript\nfunction displayFirstItemPrice(customer: Customer): void {\n const price = customer.getFirstCartItemPrice();\n console.log(`Price of the first item: ${price.getAmount()}`);\n}\n```\n\n\nMuch better. Now the dependency chain looks completely different:\n\n\n```mermaid\nflowchart LR\n OS[OrderService]:::green --> CU[Customer]:::green\n CU --> SC[ShoppingCart]:::green\n SC --> CI[CartItem]:::green\n\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n`OrderService` only talks to `Customer`. `Customer` only talks to `ShoppingCart`. Each layer hides the next one. Now `OrderService` does not care about:\n\n- How the cart stores items\n- What a `CartItem` contains\n- How the `Product` holds its price\n\nIt just asks the `Customer` for what it needs, and the `Customer` delegates to the objects it owns. This is the Law of Demeter at work.\n\n---\n\n# 5. Benefits of Law of Demeter\n\n#### **Low Coupling**\n\nEach class depends only on its immediate collaborators. Code changes in one place don't ripple across your codebase. When `ShoppingCart` changes its internal storage from a `List` to a `Map`, only `ShoppingCart` needs updating.\n\n#### **Better Encapsulation**\n\nEach class handles its own logic. No external code peeks into internals. Objects expose meaningful behaviors (\"give me the first item price\") instead of raw structure (\"give me your list so I can dig through it\").\n\n#### **Easier Refactoring**\n\nYou can evolve internal implementations without affecting consumers. If `Product` changes how it stores pricing, only `CartItem` and `ShoppingCart` need to adapt. The `OrderService` remains untouched.\n\n#### **Improved Testability**\n\nFewer mocks are needed. To test the refactored `displayFirstItemPrice`, you only need to mock `Customer` and have it return a `Money` value. No more six-layer mock chains.\n\n#### **Cleaner APIs**\n\nPublic methods become expressive, intentional, and meaningful. Instead of forcing callers to navigate your object graph, you provide clear entry points that describe what the caller actually wants.\n\n---\n\n# 6. Common Questions About LoD\n\n#### Isn't this just more code? I have to write all these wrapper methods!\n\nYes, following LoD can result in additional small, delegating methods. But this “extra” code serves a critical purpose: **it reduces coupling**.\n\nThink of it this way: would you rather write 3 lines now to isolate behavior, or refactor 300 later when your system breaks?\n\nThese small wrappers protect the rest of your codebase from internal changes. They enforce the principle of **“Tell, Don’t Ask”, **you tell an object what you want it to do, instead of reaching inside and doing it yourself.\n\n#### Does the Law of Demeter mean I can’t use getters at all?\n\nNot at all. LoD doesn’t forbid getters.\n\nSimple property access like `customer.getName()` is perfectly fine—`name` is a direct part of `Customer`.\n\nThe issue arises with **chained getters** across object boundaries:\n\n\n```java\ncustomer.getCart().getItems().get(0).getProduct().getPrice();\n```\n\n\nThis creates tight coupling between the caller and the internal structure of several unrelated classes. Instead, you’re encouraged to **delegate** the operation to the object that owns the knowledge.\n\n#### What about data structures? Can I call `size()` on a list I get from an object?\n\nThis is a nuanced area.\n\nIf `getUsers()` returns a standard collection like `List`, then `getUsers().size()` is generally **acceptable**. Lists are transparent and well-understood abstractions, and operations like `size()` don’t break encapsulation.\n\nHowever, this would be a violation:\n\n\n```java\ngetUsers().get(0).getAddress().getStreet();\n```\n\n\nThe more layers of domain objects you traverse, the more you're violating LoD. The key is whether you're interacting with a **simple data structure** or delving into **another object’s responsibility chain**.\n\n#### When is it okay to “violate” the Law of Demeter?\n\nLike most principles, LoD is a guideline—not a hard rule. Some common exceptions include:\n\n- **DTOs / Value Objects**: It’s acceptable to traverse simple data carriers where behavior isn't expected.\n- **Stable, Low-Level Libraries**: Using well-known APIs (like `Map.get()` or `List.size()`) is typically safe.\n- **Fluent APIs / Builders**: Method chaining in fluent interfaces is usually an intentional design, not a violation.\n\nThe key is **intentional design**. If you understand the coupling trade-off and still find it justifiable, go for it. Just don’t do it by accident.\n\nIn short: **LoD is like a guardrail**. It helps you avoid the slippery slope of exposing internals and tying your code together too tightly.\n\n---\n\n# 7. Practical Example: Ride Notification\n\nLet's look at another scenario to reinforce the pattern. This time, we are building a notification system for a ride-sharing app like Uber or Lyft.\n\n### The Problem\n\nA `NotificationService` class needs three pieces of information to send a ride update to a passenger:\n\n- The driver's name (from the driver's profile)\n- The car's license plate (from the driver's vehicle registration)\n- The passenger's phone number (from their contact info)\n\nA developer in a hurry writes the following:\n\n\n```java\nclass NotificationService {\n public void sendRideUpdate(Ride ride) {\n // Train wreck 1: reaching through Driver -> Profile to get name\n String driverName = ride.getDriver()\n .getProfile()\n .getFullName();\n\n // Train wreck 2: reaching through Driver -> Vehicle -> Registration\n String plate = ride.getDriver()\n .getVehicle()\n .getRegistration()\n .getLicensePlate();\n\n // Train wreck 3: reaching through Passenger -> ContactInfo\n String phone = ride.getPassenger()\n .getContactInfo()\n .getPhoneNumber();\n\n String message = String.format(\n \"Your driver %s is arriving in a %s. Contact: %s\",\n driverName, plate, phone);\n System.out.println(\"SMS to \" + phone + \": \" + message);\n }\n}\n```\n\n```python\nclass NotificationService:\n def send_ride_update(self, ride):\n # Train wreck 1: reaching through Driver -> Profile to get name\n driver_name = (ride.get_driver()\n .get_profile()\n .get_full_name())\n\n # Train wreck 2: reaching through Driver -> Vehicle -> Registration\n plate = (ride.get_driver()\n .get_vehicle()\n .get_registration()\n .get_license_plate())\n\n # Train wreck 3: reaching through Passenger -> ContactInfo\n phone = (ride.get_passenger()\n .get_contact_info()\n .get_phone_number())\n\n message = f\"Your driver {driver_name} is arriving in a {plate}. Contact: {phone}\"\n print(f\"SMS to {phone}: {message}\")\n```\n\n```cpp\nclass NotificationService {\npublic:\n void sendRideUpdate(const Ride& ride) {\n // Train wreck 1: reaching through Driver -> Profile to get name\n string driverName = ride.getDriver()\n .getProfile()\n .getFullName();\n\n // Train wreck 2: reaching through Driver -> Vehicle -> Registration\n string plate = ride.getDriver()\n .getVehicle()\n .getRegistration()\n .getLicensePlate();\n\n // Train wreck 3: reaching through Passenger -> ContactInfo\n string phone = ride.getPassenger()\n .getContactInfo()\n .getPhoneNumber();\n\n cout << \"SMS to \" << phone << \": Your driver \" << driverName\n << \" is arriving in a \" << plate\n << \". Contact: \" << phone << endl;\n }\n};\n```\n\n```csharp\nclass NotificationService\n{\n public void SendRideUpdate(Ride ride)\n {\n // Train wreck 1: reaching through Driver -> Profile to get name\n string driverName = ride.GetDriver()\n .GetProfile()\n .GetFullName();\n\n // Train wreck 2: reaching through Driver -> Vehicle -> Registration\n string plate = ride.GetDriver()\n .GetVehicle()\n .GetRegistration()\n .GetLicensePlate();\n\n // Train wreck 3: reaching through Passenger -> ContactInfo\n string phone = ride.GetPassenger()\n .GetContactInfo()\n .GetPhoneNumber();\n\n string message = $\"Your driver {driverName} is arriving in a {plate}. Contact: {phone}\";\n Console.WriteLine($\"SMS to {phone}: {message}\");\n }\n}\n```\n\n```go\ntype NotificationService struct{}\n\nfunc (ns *NotificationService) SendRideUpdate(ride *Ride) {\n // Train wreck 1: reaching through Driver -> Profile to get name\n driverName := ride.GetDriver().\n GetProfile().\n GetFullName()\n\n // Train wreck 2: reaching through Driver -> Vehicle -> Registration\n plate := ride.GetDriver().\n GetVehicle().\n GetRegistration().\n GetLicensePlate()\n\n // Train wreck 3: reaching through Passenger -> ContactInfo\n phone := ride.GetPassenger().\n GetContactInfo().\n GetPhoneNumber()\n\n fmt.Printf(\"SMS to %s: Your driver %s is arriving in a %s. Contact: %s\\n\",\n phone, driverName, plate, phone)\n}\n```\n\n```typescript\nclass NotificationService {\n sendRideUpdate(ride: Ride): void {\n // Train wreck 1: reaching through Driver -> Profile to get name\n const driverName = ride.getDriver()\n .getProfile()\n .getFullName();\n\n // Train wreck 2: reaching through Driver -> Vehicle -> Registration\n const plate = ride.getDriver()\n .getVehicle()\n .getRegistration()\n .getLicensePlate();\n\n // Train wreck 3: reaching through Passenger -> ContactInfo\n const phone = ride.getPassenger()\n .getContactInfo()\n .getPhoneNumber();\n\n const message = `Your driver ${driverName} is arriving in a ${plate}. Contact: ${phone}`;\n console.log(`SMS to ${phone}: ${message}`);\n }\n}\n```\n\n\nLook at what the `NotificationService` now knows about. It is coupled to `Driver`, `Profile`, `Vehicle`, `Registration`, `Passenger`, `ContactInfo`, and their internal structures.\n\n\n```mermaid\nflowchart TD\n NS[NotificationService]:::red --> R[Ride]:::red\n R --> D[Driver]:::red\n D --> P[Profile]:::red\n D --> V[Vehicle]:::red\n V --> REG[Registration]:::red\n R --> PA[Passenger]:::red\n PA --> CI[ContactInfo]:::red\n\n classDef red fill:#ff8787,stroke:#000,color:#000\n```\n\n\nIf `Vehicle` restructures how it stores registration data, the notification service breaks. If `Passenger` changes from `ContactInfo` to a different contact model, the notification service breaks. Every internal change in any of these classes becomes a potential breaking change for `NotificationService`.\n\n### The Fix: Delegation Methods\n\nInstead of letting `NotificationService` navigate the entire object graph, we add delegation methods to `Ride`. The `Ride` class already has references to its driver and passenger, so it is the natural place to answer these questions.\n\n\n```java\nclass Ride {\n private Driver driver;\n private Passenger passenger;\n\n // ... constructor, other methods ...\n\n public String getDriverName() {\n return driver.getProfile().getFullName();\n }\n\n public String getVehiclePlate() {\n return driver.getVehicle().getRegistration().getLicensePlate();\n }\n\n public String getPassengerPhone() {\n return passenger.getContactInfo().getPhoneNumber();\n }\n}\n```\n\n```python\nclass Ride:\n def __init__(self, driver, passenger):\n self._driver = driver\n self._passenger = passenger\n\n # ... other methods ...\n\n def get_driver_name(self):\n return self._driver.get_profile().get_full_name()\n\n def get_vehicle_plate(self):\n return self._driver.get_vehicle().get_registration().get_license_plate()\n\n def get_passenger_phone(self):\n return self._passenger.get_contact_info().get_phone_number()\n```\n\n```cpp\nclass Ride {\nprivate:\n Driver driver;\n Passenger passenger;\n\npublic:\n // ... constructor, other methods ...\n\n string getDriverName() const {\n return driver.getProfile().getFullName();\n }\n\n string getVehiclePlate() const {\n return driver.getVehicle().getRegistration().getLicensePlate();\n }\n\n string getPassengerPhone() const {\n return passenger.getContactInfo().getPhoneNumber();\n }\n};\n```\n\n```csharp\nclass Ride\n{\n private Driver driver;\n private Passenger passenger;\n\n // ... constructor, other methods ...\n\n public string GetDriverName()\n {\n return driver.GetProfile().GetFullName();\n }\n\n public string GetVehiclePlate()\n {\n return driver.GetVehicle().GetRegistration().GetLicensePlate();\n }\n\n public string GetPassengerPhone()\n {\n return passenger.GetContactInfo().GetPhoneNumber();\n }\n}\n```\n\n```go\ntype Ride struct {\n driver *Driver\n passenger *Passenger\n}\n\n// ... other methods ...\n\nfunc (r *Ride) GetDriverName() string {\n return r.driver.GetProfile().GetFullName()\n}\n\nfunc (r *Ride) GetVehiclePlate() string {\n return r.driver.GetVehicle().GetRegistration().GetLicensePlate()\n}\n\nfunc (r *Ride) GetPassengerPhone() string {\n return r.passenger.GetContactInfo().GetPhoneNumber()\n}\n```\n\n```typescript\nclass Ride {\n private driver: Driver;\n private passenger: Passenger;\n\n // ... constructor, other methods ...\n\n getDriverName(): string {\n return this.driver.getProfile().getFullName();\n }\n\n getVehiclePlate(): string {\n return this.driver.getVehicle().getRegistration().getLicensePlate();\n }\n\n getPassengerPhone(): string {\n return this.passenger.getContactInfo().getPhoneNumber();\n }\n}\n```\n\n\nNow the `NotificationService` becomes simple and clean:\n\n\n```java\nclass NotificationService {\n public void sendRideUpdate(Ride ride) {\n String driverName = ride.getDriverName();\n String plate = ride.getVehiclePlate();\n String phone = ride.getPassengerPhone();\n\n String message = String.format(\n \"Your driver %s is arriving in a %s. Contact: %s\",\n driverName, plate, phone);\n System.out.println(\"SMS to \" + phone + \": \" + message);\n }\n}\n```\n\n```python\nclass NotificationService:\n def send_ride_update(self, ride):\n driver_name = ride.get_driver_name()\n plate = ride.get_vehicle_plate()\n phone = ride.get_passenger_phone()\n\n message = f\"Your driver {driver_name} is arriving in a {plate}. Contact: {phone}\"\n print(f\"SMS to {phone}: {message}\")\n```\n\n```cpp\nclass NotificationService {\npublic:\n void sendRideUpdate(const Ride& ride) {\n string driverName = ride.getDriverName();\n string plate = ride.getVehiclePlate();\n string phone = ride.getPassengerPhone();\n\n cout << \"SMS to \" << phone << \": Your driver \" << driverName\n << \" is arriving in a \" << plate\n << \". Contact: \" << phone << endl;\n }\n};\n```\n\n```csharp\nclass NotificationService\n{\n public void SendRideUpdate(Ride ride)\n {\n string driverName = ride.GetDriverName();\n string plate = ride.GetVehiclePlate();\n string phone = ride.GetPassengerPhone();\n\n string message = $\"Your driver {driverName} is arriving in a {plate}. Contact: {phone}\";\n Console.WriteLine($\"SMS to {phone}: {message}\");\n }\n}\n```\n\n```go\nfunc (ns *NotificationService) SendRideUpdate(ride *Ride) {\n driverName := ride.GetDriverName()\n plate := ride.GetVehiclePlate()\n phone := ride.GetPassengerPhone()\n\n fmt.Printf(\"SMS to %s: Your driver %s is arriving in a %s. Contact: %s\\n\",\n phone, driverName, plate, phone)\n}\n```\n\n```typescript\nclass NotificationService {\n sendRideUpdate(ride: Ride): void {\n const driverName = ride.getDriverName();\n const plate = ride.getVehiclePlate();\n const phone = ride.getPassengerPhone();\n\n const message = `Your driver ${driverName} is arriving in a ${plate}. Contact: ${phone}`;\n console.log(`SMS to ${phone}: ${message}`);\n }\n}\n```\n\n\nThe dependency picture is now dramatically simpler:\n\n\n```mermaid\nflowchart LR\n NS[NotificationService]:::green --> R[Ride]:::green\n\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\n`NotificationService` only knows about `Ride`. It has no idea that `Driver`, `Profile`, `Vehicle`, `Registration`, `Passenger`, or `ContactInfo` even exist.\n\n#### Why This Design Works\n\n- **Single point of change.** If `Vehicle` restructures how it stores registration data, you update `Ride.getVehiclePlate()` and nothing else.\n- **Easy to test.** To test `NotificationService`, you only mock `Ride` with three simple return values.\n- **Self-documenting.** Method names like `getDriverName()` and `getPassengerPhone()` clearly describe what data is being retrieved without exposing how it is obtained.\n- **Contained ripple effects.** Internal restructuring of `Driver`, `Vehicle`, or `Passenger` stays contained within the classes that own them.","pageType":"lld-interviews"}

Get Premium