Lecture_Notes/imperfect_notes/pragy/intro week - LLD 101.md

Intro Week - 4 - LLD 101

Why LLD?

• Must know for cracking any good tech company
• Don't miss out, because it will be a red flag in a design interview

What will we cover?

• Basics & Fundas
• 10-12 days for LLD later on
• Essential Design Patterns - factory, consumer producer, etc
• Class Diagrams
• Object Oriented
• Design Patterns
• Different Paradigms

Contrast from what we usually do

• All code in one file
  • some functions where all logic goes
• From top to bottom
• What paradigm is this?
  • procedural
• functional / declarative / event loop driven

Object Oriented

1. Split the code according to entities
2. For every entity that you can think of for your problem
   • create a separate blueprint
3. For each entity, think of
   • properties
   • attributes
4. Think of
   • functionalities
   • behavior
5. Think of relationships

class Bird:
    weight: float
    height: float
    color: Color
    
    def fly(): ...
    def eat(): ...

Note that classes are blueprints When you create an instance/snapshot of a class, you get an object

new Bird()
Bird()

Constructor

# python
class Bird:
    def __init__(self):
        pass
b = Bird()

// java
class Bird {
    public Bird() {}
}

Bird b = new Bird();

Now,

• different birds can fly in different ways
• some birds don't even fly

Thus, our fly function must depend on the bird

def fly(bird_type):
    if bird_type == 'hen':
        ...
    elif bird_type == 'kiwi':
        ...
    ...

Issues:

• Hard to read
• Hard to maintain
• Hard to test
• Hard to change

Solution:

• Abstract out the common things

Inheritance

Explain inheritance

• super class
• subclasses

class Bird:
    def fly():
        // flap wings
        
class Eagle(Bird):
    ...

class Peacock(Bird):
    ...

Does this solve the problem?

• Not yet
• Need method overriding

class Bird:
    def fly():
        # flap wings
        
class Eagle(Bird):
    @override
    def fly():
        ...

class Peacock(Bird):
    @override
    def fly():
        ...

Issue:

• No schema enforcement
  • I want every subclass to implement fly
  • some user can forget to implement the method
  • user won't get any warning/error

Solutions: abstract classes / interfaces

Interfaces

• Enforce implementations
• Issue: Code replication
• can't put common logic in an interface

Abstract Base Classes

• Put common logic in parent class.
• Put specific logic in child classes.

---

Encapsulation

• don't want client to change my stuff
• private/protected .. access modifiers
• What if I still want to access stuff?
  • getter/setter

Abstraction vs Encapsulation

• Hiding details vs Hiding data

python doesn't have encapsulation

---

How will you

• Explain a 10k line code?
• design interviewbit?

UML diageram Code -> IB -> TLE/Acc/Failed

Ignore asyncronous, other details

Ways to Explain

1. Structural explanation
   • classes
   • relations b/w classes
2. Behavioral explanation
   • non-tech guy can understand
     • what the system does
     • How things behave
   • use cases
     • responsibilities of system
   • not the responsibilities of system
     • as important as knowing the responsibilities

Use-Case vs Test-Case

• Usecase
  • broader version of test case
  • Any person can understand a use case

Example: Library management system

• use case
  • search books
  • issue books
• test case
  • what if searched booked doesn't exist?
  • what if it has a unicode char
  • what if book already issued?

Online shopping system

• use cases
  • search product
    • by category
    • by name
  • add to cart
  • checkout cart
  • make payment

Draw System boundary

Anything that is inside my use case. Everything outside, I don't care about

Actors

• customer

Relations b/w use cases

• when is a checkout successful? when the payment succeeds
• so, checkout usecase uses payment usecase
• similarly, search by category, and search by name, extend the search usecase


---

Example LLD Question

• DS/Algo questions are deterministic problems
• LLD, HLD are open ended
• Questions are very short
• You need to ask lots of questions.

Design a Cofee Machine

• first step?
  • start drawing?
  • start coding?
  • cry?
• Gather Requirements & Usecases
  1. Design a coffee machine which makes different beverages based on set ingredients.
  2. The initialization of the recipes for each drink should be hard-coded, although it should be relatively easy to add new drinks.
  3. The machine should display the ingredient stock (+cost) and menu upon startup, and after every piece of valid user input.
  4. Drink cost is determined by the combination of ingredients. For example, Coffee is 3 units of coffee (75 cents per), 1 unit of sugar (25 cents per), 1 unit of cream (25 cents per).
  5. Ingredients and Menu items should be printed in alphabetical order. If the drink is out of stock, it should print accordingly. If the drink is in stock, it should print "Dispensing: ".
  6. To select a drink, the user should input a relevant number. If they submit "r" or "R" the ingredients should restock, and "q" or "Q" should quit. Blank lines should be ignored, and invalid input should print an invalid input message.

Entities are nouns. Verbs are usually not entities

Detected entities

• beverage
• ingredient
• recipe
• stock
• menu
• user
• cofee-machine

Identify relations

Example

• beverage has a recepie

• recepie can have multiple ingredients

• stock has multiple ingredients

• menu has multiple beverages

• user has account - hidden requirement

• Think the rest of the entities and relations

• Give us a write up on the same

• Purpose

  • try
  • learn in LLD class
  • contrast with earlier submission