DEV Community: Jasper Oh/YJ Oh

🧑‍🎨 Structural Patterns - 3️⃣

Jasper Oh/YJ Oh — Sun, 08 Dec 2024 22:50:56 +0000

Structural Patterns (🏗 Third)

Patterns that focus on the structure of objects

1. Proxy

What is Proxy Design Pattern?

Proxy is a wrapper, and it controls access to the wrapee.

Lets check the UML of Proxy Design Pattern.

It looks exact same structure as a wrapper.

And lets just dive in to the code.

First, Interface and Service. As you can see in the below, Service and Proxy must fully implement all abstract methods

class ServiceInterface {
public:
    virtual void doSomething() = 0;
};

//The actual service where the work is done
class Service : public ServiceInterface {
public:
    void doSomething() override {
        cout << "doing service code" << endl;
    }
};

Second, Our Proxy code is here.

class Proxy : public ServiceInterface {

    Service* service;

public:
    Proxy(Service* s) : service(s) {}

    void doSomething() override {
        cout << "doing proxy code before" << endl;
        service->doSomething();
        cout << "doing proxy code after" << endl;
    }
};

Proxy contains a pointer to the actual service. Any calls made to the proxy are directed to the actual service. Some pre and post code may be done before
and after the call to service (checking the security or logging...)

And Client, the client can use real service or proxy version, client doesn't know

void client(ServiceInterface *si) {
    si->doSomething();
}

At last, in main method, instantiate real and proxy services, pass pointer of real service to proxy

    Service *service = new Service;
    Proxy *proxy_youtube = new Proxy(service);

    // Directly use the service
    client(youtube);

    cout << endl;

    // use the proxy service
    client(proxy_youtube);

    delete youtube;
    delete proxy_youtube;

As we can see, proxy implements the same interface as the service, it can be passed to any object that expects a Service Interface.

And proxy can work even if the original service is not available.

2. Facade

What is Facade Design Pattern?

The Facade pattern encapsulates a complex system or API. Used when we need to provide a simple interface to a complex system. Abstracts away the details of the complex system or API.

Lets check the UML of the Facade

I want to highlight in the UML, that Facade provides convenient access to a particular part of the subsystem's functionality. And Subsystem classes aren't aware of the facade's existence. They operate within the system and work with each other directly. At the last, Client uses the facade instead of calling the subsystem objects directly

With these information, lets dive in to the code.

There will be lots(?) of subsystem called ClassA, B, C

class Class1 {
public:
    void doSomething() {
        cout << "class 1 doing something" << endl;
    }
};

class Class2 {
public:
    void doSomething() {
        cout << "class 2 doing something" << endl;
    }
};

class Class3 {
public:
    void doSomething() {
        cout << "class 3 doing something" << endl;
    }
};

And we need a Facade class to provides a simple interface for the client to access in order to begin the action of the complicated code

class Facade {
private:
    Class1 c1;
    Class2 c2;
    Class3 c3;

public:
    void execute1() {
        c1.doSomething();
        c2.doSomething();
        c3.doSomething();
    }

    void execute2() {
        c3.doSomething();
        c1.doSomething();
        c2.doSomething();
        c3.doSomething();
        c1.doSomething();
        c1.doSomething();
    }
};

And in main we can just simply instantiate the Facade to execute subsystems

    Facade f;

    //f.execute1();
    f.execute2();

But we need to aware that this pattern can become epicentre of coupling. And become an extremely complex and large class to maintain

3. Bridge

What is Bridge Design Pattern?

When we want to separate a large class or a set of highly closely related classes into two separate hierarchies, an "Abstraction" and an "Implementation"

Lets jump to the UML of bridge pattern,

Lets say we want to create the shapes - circle, square ... There will be lots of thing to considerate like colour of the shape, scale..etc. With this Bridge pattern, we can divide these with abstraction and implementation.

This can be hard to understand, but lets check the code with the UML + example of shapes

First, lets jump to implementation box.

In this case, our color class can be a implementation context as a interface.

struct Color {
    string color;
    virtual string get_color() = 0;
};

And for the concrete Implementation, There would be a concrete Color like red, blue... with implement the Color interface.

struct Red : Color {
    Red() {
        color = "#FF0000";
    }

    string get_color() override {
        return "Red";
    }
};

struct Blue : Color {
    Blue() {
        color = "#0000FF";
    }

    string get_color() {
        return "Blue";
    }
};

And we need Abstraction. Shape that have Color as data member.


struct Shape {
    Color* my_color;

    Shape(Color *color) {
        my_color = color; //here is the BRIDGE to the color object/class
    }

    virtual void draw() {
        cout << "I'm a Shape with color " << my_color->get_color() << endl;
    }

    virtual ~Shape() {
        delete my_color;
    }
};

With this abstraction, we can create circle and square.

struct Square : Shape {
    Square(Color *color) : Shape(color) {};
    void draw() override {
        cout << "I'm a Square with color " << my_color->get_color() << endl;
    }
};

struct Circle : Shape {
    Circle(Color *color) : Shape(color) {};
    void draw() override {
        cout << "I'm a Circle with color " << my_color->get_color() << endl;
    }
};

And in main, we can create the each shape with color!

    cout << "---- COMBO 1: Red Square ----" << endl;
    Square red_square{new Red()};
    red_square.draw();

    cout << "\n---- COMBO 2: Blue Circle ----" << endl;
    Circle blue_circle{new Blue()};
    blue_circle.draw();

    cout << "\n---- COMBO 3: Red Circle ----" << endl;
    Circle red_circle{new Red()};
    red_circle.draw();

So, When we want to divide and conquer a huge class that has many variation, we can use bridge pattern. And plus, if we want to switch implementations at run-time, we can use the bridge pattern as well.

4. Decorator

What is Decorator Design Pattern?

To understand the Decorator Design pattern, we need to recap the wrapper concept Recap-Wrapper. And Decorator is We 'wrap' our base object using decorative pieces. In other words, Decorator lets you attach new behaviours to objects by replacing these objects inside special wrapper objects that contain the behaviours.

Lets say we want to create a donut with toppings.

Lets check the UML.

As you can see, WheatDonut and RiceDonut implement the "Component" interface and the "Decorator" as well. And few Sprinkles, Gummies, Chocolate implement the Decorator, which means we can "decorate" donuts with decorator pattern.

Now, lets dive into the code.

First, check the component

class Component
{
public:
    virtual std::string Description()
    {
        return "Unknown component";
    }
    virtual int getCost() = 0;
    virtual ~Component() {};
};

And with this component, create the wheat-donut, and rice-donut

class WheatDonut : public Component
{
public:
    std::string Description() override
    {
        return "Wheat donut";
    }
    int getCost() override {  return 200;  }
    //~WheatDonut() { std::cout << "deleted WheatDonut" << std::endl;  };
};

class RiceDonut : public Component
{
public:
    std::string Description() override
    {
        return "Rice donut";
    }
    int getCost() override {  return 300; }
    //~RiceDonut() { std::cout << "deleted RiceDonut" << std::endl;  };
};

And now, we realize we need a decorator which can enable to put on the topping in donut. We can put the data-member in each donuts, but rather than that, create the decorator which implement the component.

class Decorator : public Component
{
protected:
    Component *component;
    virtual ~Decorator() {
        delete component;
    }
};

Can then, create the toppings with implementing decorator.

class Sprinkles : public Decorator
{
public:
    Sprinkles(Component *donut) { this->component = donut; }
    std::string Description() override {
        return component->Description() + ", Sprinkles";
    }
    int getCost() override { return 50 + component->getCost(); }
    //~Sprinkles() { std::cout << "deleted Sprinkles" << std::endl;  };
};

class Gummies : public Decorator
{
public:
    Gummies(Component *donut) {  this->component = donut;  }
    std::string Description() override {
        return component->Description() + ", Gummies";
    }
    int getCost() override {
        return 90 + component->getCost(); }
    //~Gummies() { std::cout << "deleted Gummies" << std::endl;  };
};
class Chocolate : public Decorator
{
public:
    Chocolate(Component *donut)  {  this->component = donut; }
    std::string Description() override {
        return component->Description() + ", Chocolate";
    }
    int getCost() override {  return 75 + component->getCost(); }
    //~Chocolate() { std::cout << "deleted Chocolate" << std::endl;  };
};

And after that, in main we can "decorate" each donut with decorators

    Component *riceDonut = new RiceDonut();

    riceDonut = new Sprinkles(riceDonut);

    riceDonut = new Gummies(riceDonut);

    riceDonut = new Chocolate(riceDonut);

    cout << riceDonut->Description() << " Cost: $" << riceDonut->getCost() << endl;

    // create new WheatDonut component
    Component *wheatDonut = new WheatDonut();

    // decorate it with Sprinkles topping
    wheatDonut = new Sprinkles(wheatDonut);

    //decorate it with Gummies topping
    wheatDonut = new Gummies(wheatDonut);

    cout << wheatDonut->Description() << " Cost: $" << wheatDonut->getCost() << endl << endl;

    delete riceDonut;
    delete wheatDonut

This pattern, adhere to the single responsibility principle - which mean each decorator is responsible for one thing, and also open close principle.

This enables add or remove responsibilities at run-time.

🧑‍🎨 Creational Patterns - 2️⃣

Jasper Oh/YJ Oh — Sat, 07 Dec 2024 08:19:26 +0000

Creational Patterns (🛠 Second) - draft

Patterns that deal with object creation

1. Singleton

What is Singleton Pattern?

Start from I need a system where there is a single object that is accessible from anywhere in the code - how do I do this without global variables? - In other word, Singleton is a globally accessible class where we guarantee only a single instance is created.

Let's see the code

class singleton
{
public:
    static singleton& get_instance()
    {
        static singleton instance; // Lazy Initialization is used in Singleton
        return instance; // Instantiated on first use.
    }
private:
    int value;
    singleton() = default; //private constructor

public:
    singleton(singleton const&)= delete; //deleting copy constructor
    void operator=(singleton const&)= delete; //deleting assignment operator

    int get_value() {
        return value++;
    }
};

So, As you can see in this pattern,

Instantiates the object on its first use
Ideally hides a private constructor
Reveals a public get_instance function that returns a reference to a static instance of the class
Provides "global" access to a single object

2. Factory / Factory Method

What is the Factory / Factory Method Pattern?

In some articles & stackoverflows, mention that Factory and Factory Method is slightly different, but trying to explain in the same category.

When you want to separate creation code from client code.

When you want a client or service to only depend on a base class for object creation and not each concrete class

Let's check the UML of Factory Pattern

Just like above UML, We can create the "ConcreteProductA and B" with the AbstractFactory.

Base on this, lets see the code actually trying to solve the real world problem.

/*
Forum class - ForumWebsite
*/

struct Forum {
    string name;
    vector<User*> users;
    Forum(string name) : name(name) {}

    UserFactory* register_user() {
        cout << "Welcome! Do you want to make an account or continue as a guest?" << endl;
        cout << "1. Make Account" << endl;
        cout << "2. Continue as Guest" << endl;
        int choice = 0;
        cout << "Enter your choice (1-2)" << endl;
        cin >> choice;

        UserFactory *factory_class;
        if(choice == 1)
            factory_class = new MemberUserFactory;
        else
            factory_class = new GuestUserFactory;

        return factory_class;
    }

    void add_user() {
        UserFactory *factory = register_user(); //get a member or guest factory
        users.push_back(factory->create_user());
        delete factory;
    }

    ~Forum() {
        for (User *u : users)
        {
            delete u;
        }
    }
};

UserFactory, GuestFactory, MemberFactory


struct UserFactory {
    virtual User* create_user() = 0;
};


struct GuestUserFactory : UserFactory {
    User* create_user() override {
        return new Guest("","");
    }
};

struct MemberUserFactory : UserFactory {
    User* create_user() override {
        string username;
        string password;
        cout << "Enter username: " << endl;
        cin >> username;
        cout << "Enter password: " << endl;
        cin >> password;
        return new Member(username, password);
    }
};

User Abstract class, Member, Guest

enum Permission {
    NONE,
    READ,
    LIKE,
    SHARE,
    FLAG,
    WRITE
};

struct User {
    string username;
    string password;
    vector<Permission> permissions;
    string date_joined;

    User(string username, string password) : username(username), password(password) {
        // declaring argument of time()
        time_t my_time = time(NULL);
        date_joined = ctime(&my_time);
    }

    bool authenticate(const string& password_input) {
        return password_input == password;
    }

    pair<string, string> get_profile() {
        return make_pair(username, date_joined);
    }

    virtual string getString() const {
        return "Username: ";
    }
    friend ostream& operator<<(ostream& os, const User& u)
    {
        os << u.getString() << u.username << " Date joined: " << u.date_joined << endl;
        return os;
    }
};

struct Guest : User {
    Guest(string username, string password) : User(username, password) {
        permissions.push_back(Permission::READ);
        permissions.push_back(Permission::LIKE);
        permissions.push_back(Permission::SHARE);
        permissions.push_back(Permission::FLAG);
    }

    string getString() const override {
        return "Guest User: ";
    }

};

struct Member : User {
    Member(string username, string password) : User(username, password) {
        permissions.push_back(Permission::READ);
        permissions.push_back(Permission::LIKE);
        permissions.push_back(Permission::SHARE);
        permissions.push_back(Permission::FLAG);
        permissions.push_back(Permission::WRITE);
    }

    string getString() const override {
        return "Member User: ";
    }
};

As we can see, these codes provide a separate interface for object creation where each subclass can alter the type of object created.

If we want to add a new product, just create a new Factory and override the creation method in it.

3. Abstract Factory

What is Abstract Factory Design Pattern?

Creational Design Pattern that lets you produce families of related objects without specifying their concrete classes

Let's check the UML of Abstract Factory Pattern

Looks very similar with Factory Pattern (Obviously) - and as we can see this pattern offers the interface for creating a family of related objects, without explicitly specifying their classes - factory for factories

Base on the UML, lets check code

AbstractProductA, B

/**
 * AbstractProductA
 */
class AbstractProductA {
public:
    virtual ~AbstractProductA() {}
    virtual string UsefulFunctionA() const = 0;
};

/**
 * AbstractProductB
 */
class AbstractProductB {
public:
    virtual ~AbstractProductB() {}
    virtual string UsefulFunctionB() const = 0;

    virtual string AnotherUsefulFunctionB(const AbstractProductA& collaborator) const = 0;
};

class ConcreteProductB1 : public AbstractProductB {
public:
    string UsefulFunctionB() const override {
        return "ConcreteProductB1";
    }

    string AnotherUsefulFunctionB(const AbstractProductA& collaborator) const override {
        const string result = collaborator.UsefulFunctionA();
        return "The result of the B1 collaborating with ( " + result + " )";
    }
};

ConcreteA1, A2, B1, B2

class ConcreteProductA1 : public AbstractProductA {
public:
    string UsefulFunctionA() const override {
        return "ConcreteProductA1";
    };
};

class ConcreteProductA2 : public AbstractProductA {
public:
    string UsefulFunctionA() const override {
        return "ConcreteProductA2";
    }
};

class ConcreteProductB1 : public AbstractProductB {
public:
    string UsefulFunctionB() const override {
        return "ConcreteProductB1";
    }

    string AnotherUsefulFunctionB(const AbstractProductA& collaborator) const override {
        const string result = collaborator.UsefulFunctionA();
        return "The result of the B1 collaborating with ( " + result + " )";
    }
};

class ConcreteProductB2 :public AbstractProductB {
public:
    string UsefulFunctionB() const override {
        return "ConcreteProductB2";
    }
    string AnotherUsefulFunctionB(const AbstractProductA& collaborator) const override {
        const string result = collaborator.UsefulFunctionA();
        return "The result of the B2 collaborating with ( " + result + " )";
    }
};

Abstract Factory (interface)

class AbstractFactory {
public:
    virtual AbstractProductA* CreateProductA() const = 0;
    virtual AbstractProductB* CreateProductB() const = 0;
};

ConcreteFactory1, 2

class ConcreteFactory1 : public AbstractFactory {
public:
    AbstractProductA* CreateProductA() const override {
        return new ConcreteProductA1();
    }

    AbstractProductB* CreateProductB() const override {
        return new ConcreteProductB1();
    }
};

class ConcreteFactory2 : public AbstractFactory {
public:
    AbstractProductA* CreateProductA() const override {
        return new ConcreteProductA2();
    }

    AbstractProductB* CreateProductB() const override {
        return new ConcreteProductB2();
    }
};

Client code

void ClientCode(const AbstractFactory& factory) {
    AbstractProductA* productA = factory.CreateProductA();
    AbstractProductB* productB = factory.CreateProductB();

    cout << productA -> UsefulFunctionA() << endl;
    cout << productB -> AnotherUsefulFunctionB(*productA) << endl;

    delete productA;
    delete productB;
}

At last, in main

    ConcreteFactory1* factory1 = new ConcreteFactory1();
    ClientCode(*factory1);

    ConcreteFactory2* factory2 = new ConcreteFactory2();
    ClientCode(*factory2);

    delete factory1;
    delete factory2;

Just like we saw, if the exact number of product families are unknown and you have to add new ones in the future, we can use this pattern.

4. Builder

What is the builder design pattern?

In easy words, I hate my constructor looks ugly and long.. like new House( ... x 100); and we can customize the Builder class to take in its own parameters and options. And plus, We can optionally implement a manager class called Director that can be responsible for different subroutines that call different methods in a builder class.

Lets check a UML

And base on the UML, lets dive in to the code

Builder interface

class Builder{
    public:
    virtual ~Builder(){}
    virtual void AddTopping(string topping) const =0;
    virtual void AddBase(string base) const =0;
    virtual void AddSauce(string sauce) const =0;
};

ConcreteBuilder1

class ConcreteBuilder1 : public Builder{
    private:

    Product1* product;

    public:
    ConcreteBuilder1(){
        this->Reset(); //builder has an instance of Product ready
    }

    ~ConcreteBuilder1(){
        delete product;
    }

    void Reset(){
        this->product= new Product1();
    }
    /**
     * All production steps work with the same product instance.
     */

    void AddTopping(string topping)const override{
        this->product->toppings.push_back(topping);
    }

    void AddBase(string base)const override{
        this->product->base = base;
    }

    void AddSauce(string sauce)const override{
        this->product->sauce = sauce;
    }

    /**
     * Please be careful here with the memory ownership. Once you call
     * GetProduct the user of this function is responsable to release this
     * memory. Here could be a better option to use smart pointers to avoid
     * memory leaks
     */

    Product1* GetProduct() {
        Product1* result= this->product;
        this->Reset(); //resets product pointer to be ready for next pizza to build
        return result;
    }
};

Product1

class Product1{
    public:
    std::vector<std::string> toppings;
    string base = "";
    string sauce = "";

    friend ostream& operator<<(ostream& os, const Product1& p) {
        stringstream toppings_str;
        os << "Product parts: ";
        for (size_t i=0;i<p.toppings.size();i++){
            if(p.toppings[i]== p.toppings.back()){
                toppings_str << p.toppings[i];
            }else{
                toppings_str << p.toppings[i] << ", ";
            }
        }
        os << p.base << ", ";
        os << p.sauce << ", ";
        os << toppings_str.str();
        os << "\n\n";
        return os;
    }
};

Director (Completely Optional)

class Director{
    /**
     * @var Builder
     */
    private:
    Builder* builder;
    /**
     * The Director works with any builder instance that the client code passes
     * to it. This way, the client code may alter the final type of the newly
     * assembled product.
     */

    public:

    void set_builder(Builder* builder){
        this->builder=builder;
    }

    /**
     * The Director can construct several product variations using the same
     * building steps.
     */

    void BuildMinimalViableProduct(){
        this->builder->AddBase("Wheat Pizza");
    }

    void BuildFullFeaturedProduct(){
        this->builder->AddBase("Wheat Pizza");
        this->builder->AddSauce("Tomato");
        this->builder->AddTopping("Pepperoni");
        this->builder->AddTopping("Mozzarella");
        this->builder->AddTopping("Olives");
    }
};

Client Code

void ClientCode(Director& director)
{
    ConcreteBuilder1* builder = new ConcreteBuilder1();
    director.set_builder(builder);

    //Use director to call builder to create pre-made products for us
    std::cout << "Standard basic product:\n";
    director.BuildMinimalViableProduct();

    Product1* p= builder->GetProduct();
    cout << *p;
    delete p;

    std::cout << "Standard full featured product:\n";
    director.BuildFullFeaturedProduct();

    p = builder->GetProduct();
    cout << *p;
    delete p;

    // Remember, the Builder pattern can be used without a Director class.
    std::cout << "Custom product:\n";
    builder->AddBase("Sour dough Pizza");
    builder->AddTopping("Mushrooms");
    builder->AddSauce("Sour cream");
    p=builder->GetProduct();
    cout << *p;
    delete p;

    delete builder;
}

At last in main

    Director* director= new Director();
    ClientCode(*director);
    delete director;
    return 0;

As you can see we can get rid of numerous constructors. And When a product is built out of many parts that can be mixed and matched.

This allows you to build variations while avoiding inheritance hierarchies

🧑‍🎨 Helper Concept (some design pattern) - 1️⃣

Jasper Oh/YJ Oh — Sat, 07 Dec 2024 05:54:42 +0000

Helper Concepts (💡 First)

Some useful ideas & design pattern that support design patterns

1. Wrapper (a concept similar to Structural Patterns)

What is Wrapper?

A class that wraps around another class, It is used to implement a design pattern that has an instance of an object and presents its own interface or behaviour to that object, without changing the original class.

Number of design patterns that can be considered Wrappers:

Adapter (Will not cover in this series)
Proxy (Will cover in this series)
Decorator (Will cover in this series)

Wrapper Classes' UML looks like below.

We can check,

The wrapper has the same interface as the wrapee
The wrapper has the same public method and attributes as the wrapee.

Base on the UML, the example of student, procrastinating Student and student Interface UML looks like below.

/*
Student Interface
*/

class StudentInterface {
public:
    virtual void study() = 0;
    virtual void procrastinate() = 0;
    virtual void print() = 0;
    virtual ~StudentInterface() = default;
};

/*
Student Class
*/

class Student : public StudentInterface {
private:
    string name;
    int age;
    string school;
    int knowledge;
    int happiness;

public:
    Student(string name, int age, string school) : name(name), age(age), school(school) {
        knowledge = 0;
        happiness = 100;
    }

    void study() {
        cout << "I'm studying" << endl;
        knowledge += 10;
        happiness -= 5;
    }

    void procrastinate() {
        cout << "I'm procrastinating" << endl;
        happiness += 10;
    }

    void print() {
        cout << "name: " << name
             << " Age: " << age
             << " School: " << school
             << " Knowledge: " << knowledge
             << " Happiness: " << happiness << endl;
    }
};

/*
ProcrastinatingStudent class
*/

class ProcrastinatingStudent : public StudentInterface {
private:
    Student *student; //wrapping around student class

public:
    ProcrastinatingStudent(Student *student) : student(student) {}

    void study() {
        student->procrastinate();
        student->study();
    }

    void procrastinate() {
        student->procrastinate();
    }

    void print() {
        student->print();
    }
    ~ProcrastinatingStudent(){delete student;}
};

With above implementation, we can use the student object like below

StudentInterface* student = new Student("J", 100, "A");
student = new ProcrastinatingStudent((Student*)student);

student->study();
delete student;

End Wrapper

2. Lazy Initialization (a concept similar to Creational Patterns)

What is Lazy Initialization?

Mandates that we don't initialize an object/resource unless we need it. In easy words, We procrastinate on initializing an expensive resource until we need it.

Lazy Initialization's UML looks like below. (But it can be implemented in so many ways, there really isn't much point in a UML diagram.)

Base on the UML, this is the example that Create the Car object (Expensive Car...) with Lazy Initialization

/*
 Car class -> Core
*/
struct Car {
    Car() {
        cout << "Building a car. This is a time consuming process" << endl;
        sleep(2);
        cout << "Wait for it..." << endl;
        sleep(1);
        cout << "Car has been made" << endl;
    }

    friend ostream& operator<<(ostream& os, const Car& c) {
        return os << "I am an expensive car that uses a lot of resources" << endl;
    }
};

/*
Client class -> service
*/

class Client {
private:
    Car *car = nullptr;
public:
    Client() {
        //car = new Car; //normally instantiate all data members right away but we don't do in Lazy Initializaiton
    }

    Car* getCar() {
        if(car == nullptr)
            car = new Car;
        return car;
    }

    ~Client(){
        delete car;
    }
};

/*
Main
*/
    Client client; //don't initialize the Car() inside client right away
    cout << *client.getCar() << endl; //initialize the Car() inside client only the first time .car is called
    cout << "End of program" << endl;

🚨 Not a good choice if the object needs to be initialized every time it is accessed

End Lazy Initialization

3. Dependency Injection (DI)

What is Dependency Injection?

Concept, Technique, Framework. To understand dependency injection, we first need to explore the meaning of "dependency." What does it mean when we say "A is dependent on B"? This implies that if B changes, it affects A. In other words, if the functionality of B is added or modified, it directly impacts A.

For example, consider the statement:

"A hamburger restaurant chef is dependent on a burger recipe."

This means that if the recipe changes, the chef must also adapt the cooking process accordingly.

class BurgerChef {
    HamburgerRecipe* hamburgerRecipe;

public:
    BurgerChef() {
        hamburgerRecipe = new HamburgerRecipe();
    }
};

In the example above, BurgerChef depends solely on HamburgerRecipe. However, if we want the chef to work with various types of burger recipes, we need to abstract the dependency using an interface.

class BurgerRecipe {
public:
    virtual void prepareBurger() = 0; // Abstract method
    virtual ~BurgerRecipe() {}       // Virtual destructor for cleanup
};

class HamburgerRecipe : public BurgerRecipe {
public:
    void prepareBurger() override {
        // Implementation for hamburger
    }
};

class BurgerChef {
BurgerRecipe* burgerRecipe;

public:
    BurgerChef() {
        burgerRecipe = new HamburgerRecipe(); // Direct dependency
    }

    ~BurgerChef() {
        delete burgerRecipe; // Ensure proper cleanup
    }
};

By abstracting the dependency with an interface, we can support various burger recipes, reducing tight coupling and improving flexibility.

Introducing Dependency Injection

In the implementation above, the BurgerChef internally determines which BurgerRecipe to use.
Now, imagine a scenario where the burger restaurant owner decides the recipe instead of the chef.
In this case, the BurgerRecipe dependency is determined externally and "injected" into the BurgerChef.

This concept of externalizing and injecting dependencies is known as Dependency Injection (DI).

How do we implement the DI?

using Constructor

class BurgerChef {
BurgerRecipe* burgerRecipe;

public:
    BurgerChef(BurgerRecipe* recipe) : burgerRecipe(recipe) {}

    ~BurgerChef() {
        delete burgerRecipe; // Clean up the injected dependency
    }
};

class BurgerRestaurantOwner {
    BurgerChef* burgerChef;

public:
    BurgerRestaurantOwner() {
        burgerChef = new BurgerChef(new HamburgerRecipe());
    }

    void changeMenu() {
        delete burgerChef; // Clean up the old chef
        burgerChef = new BurgerChef(new CheeseburgerRecipe());
    }

    ~BurgerRestaurantOwner() {
        delete burgerChef;
    }
};

using Method (Setter)

class BurgerChef {
BurgerRecipe* burgerRecipe;

public:
    BurgerChef() : burgerRecipe(new HamburgerRecipe()) {}

    void setBurgerRecipe(BurgerRecipe* recipe) {
        delete burgerRecipe; // Clean up the old recipe
        burgerRecipe = recipe;
    }

    ~BurgerChef() {
        delete burgerRecipe;
    }
};

class BurgerRestaurantOwner {
BurgerChef burgerChef;

public:
    void changeMenu() {
        burgerChef.setBurgerRecipe(new CheeseburgerRecipe());
    }
};

Factory Pattern is a way of implementing Dependency Injection.

🧑‍🎨 Design Pattern (feat. C++)

Jasper Oh/YJ Oh — Fri, 06 Dec 2024 23:24:49 +0000

Introduction to Design Patterns

In this blog series, we’ll explore a few widely used design patterns. As a reference, I’ll be using the Refactoring Guru website, which offers detailed explanations and adorable illustrations to help demystify design patterns.

What to Expect in This Series

1. How We Classify Design Patterns

Design patterns are typically divided into three main categories:

Behavioral Patterns:

Focused on communication and interaction between objects.

How do we enable objects to collaborate while minimizing dependencies?
Structural Patterns:

Focused on designing architectures for flexibility and maintainability.

How do we combine classes and objects to form robust program structures?
Creational Patterns:

Focused on object creation mechanisms.

What are the best strategies for instantiating objects or groups of objects?

2. Design Patterns Covered in This Series

I’ll structure this series by category, covering a mix of foundational and practical patterns.

Helper Concepts (💡 First)

Some useful ideas that support design patterns:

Wrapper (a concept similar to Structural Patterns)
Lazy Initialization (a concept similar to Creational Patterns)
Dependency Injection

Creational Patterns (🛠 Second)

Patterns that deal with object creation:

Singleton
Factory / Factory Method
Abstract Factory
Builder

Structural Patterns (🏗 Third)

Patterns that focus on the structure of objects:

Proxy
Facade
Bridge
Decorator

Behavioral Patterns (🔄 Last)

Patterns that handle communication between objects:

Observer
Chain of Responsibility
Strategy
State
Mediator

3. Cheat-Sheet for Interviews and Practical Use

To wrap things up, I’ll include a cheat-sheet summarizing key patterns. This will be helpful for preparing for technical interviews and as a quick reference when designing your own projects.

1. Behavioural

Singleton

Chain of responsibility

Strategy

State

Mediator

2. Structural

Proxy

Facade

Bridge

Decorator

3. Creational

Observer

Factory <-> Factory Method

Abstract Factory

Builder

4. Helper Concept

Wrapper (More like Structural)
Lazy Initialization (More like Creational)

Dependency Injection

How Twitter, Instagram feed system made?

Jasper Oh/YJ Oh — Fri, 29 Nov 2024 18:04:15 +0000

The Big Picture

Even at the same moment, the feed you see on your screen differs from the one your friend sees. Why?

Because your activities—like follows, likes, comments, shares, and even blocks—are unique to you.

A feed system must tailor itself to show each user a personalized experience.

How Feed Systems Work

A feed system is generally divided into two main components to efficiently achieve personalized feeds:

Feed Publishing System
- Activated when a user creates a new post.
- Includes tasks like authentication, rate limiting, and fanout services.
Feed Reading System
- Activated when a user opens the app to view their feed.
- Handles dynamic updates, such as refreshing posts on-demand.
- Powered by tools like Content Delivery Networks (CDNs) and caching systems.

Two Ways to Build Feeds

When a user creates a post, the system must determine how to distribute it to everyone who should see it (e.g., Instagram followers or Facebook friends).

This process, known as fanout, can happen in two ways:

1. Push Model (Fanout-on-Write)

Posts are distributed to followers as soon as they are created.

✔ Advantages:

Real-time updates: Feeds feel immediate.
Quick reads: Posts are preloaded into followers’ feeds.

✘ Disadvantages:

Hot Key Problem: Popular users with millions of followers (e.g., Elon Musk) require immense resources to update all feeds. > Example: One tweet from Elon Musk can trigger updates for over 100 million feeds.
Resource Waste: Updating inactive users' feeds consumes unnecessary computing power.

2. Pull Model (Fanout-on-Read)

Posts are fetched and added to a feed only when a user refreshes it.

✔ Advantages:

Optimized for inactive users: Resources are spent only when users actively check their feed.
No Hot Key Problem: System avoids bottlenecks caused by distributing posts to millions of followers at once.

✘ Disadvantages:

Slower reads: Fetching posts on demand can increase loading time.

3. Hybrid Model

Combines the strengths of both the Push and Pull Models to optimize performance and scalability.

Push Model: Used for most users to ensure fast, real-time feed updates.
Pull Model: Applied to high-profile users to handle the Hot Key Problem.

Example Scenario

A follower subscribes to both an average user and a celebrity:

When the average user posts (Push Model), it instantly appears in the follower’s feed.
When the celebrity posts (Pull Model), the post is only added when the follower refreshes their feed.

Additional Considerations

Web Server Responsibilities

When a user creates a post, the web server handles the following:

Authentication: Verify the user making the request.
Rate Limiting: Prevent spam by restricting the frequency of posts.
Post Handling:
- Save the post (usually as metadata to conserve storage).
- Distribute it to followers.
- Send notifications about the new post.

Graph Databases

Graph databases are ideal for managing relationships (e.g., friends, followers) in feed systems. They allow:

Efficient retrieval of user relationships.
Seamless integration with both Push and Pull Models.

Caching and Message Queues

These tools enhance speed and efficiency:

Caching Layers: Separate caches for:
- Feed IDs
- Post Content
- Relationship Data
- User Interactions (likes, comments)
- Metrics (follower counts, engagement stats)
CDNs: As a distributed caching layer, CDNs improve global feed delivery.

By blending the Push, Pull, and Hybrid Models with advanced data management techniques, feed systems deliver fast, personalized, and scalable user experiences. 🌟

How they created this service

Jasper Oh/YJ Oh — Fri, 29 Nov 2024 17:46:25 +0000

Exploring Big Tech's Genius: How They Build Scalable Services

I’m thrilled to share something I’ve been deeply curious about: how big tech companies create their groundbreaking systems and architectures. This blog series will dive into the fascinating strategies behind the services we rely on every day.

Of course, due to privacy concerns and the limited information available online, this post will share only what’s publicly known and reasonably inferred. I’m not an insider, but I’m eager to explore the circumstances and challenges that drive these innovative solutions.

For instance:

How does WhatsApp handle the colossal volume of 100 billion messages sent daily with its system architecture?
How does Netflix seamlessly stream high-quality video to millions of viewers at the same time?

These are just a couple of examples of the exciting questions I want to unpack.

I’m aiming to make this a weekly series, so stay tuned as we explore the engineering marvels of the tech giants. Let’s dive in!

Network - Web Socket (2)

Jasper Oh/YJ Oh — Tue, 27 Feb 2024 00:08:07 +0000

Difference Between TCP/IP Socket and WebSocket

TCP/IP sockets and WebSockets both facilitate communication via IP and port numbers and share the characteristic of supporting bidirectional communication.

The differences are as follows:
WebSocket operates on the HTTP layer, whereas TCP/IP sockets operate on a different layer. So, the two concepts are fundamentally distinct and should not be confused.

WebSocket

WebSocket is a technology developed to address the issue of real-time communication in HTTP! Let's briefly examine the characteristics of HTTP, which led to the development of WebSocket.

HTTP Cannot Provide Real-time Communication

To understand the background of WebSocket, we need to look at the characteristics of HTTP.

Statelessness (Unidirectional)
Cost of establishing and terminating connections each time
Request-response structure
Heavyweight headers -> In cases where a large volume of data needs to be exchanged in real-time, this becomes a significant burden.

HTTP has these characteristics. In other words, due to its unidirectional request-response communication structure, similar to TCP/IP protocol-based sockets where the connection is continually maintained, it cannot perform real-time communication. WebSocket protocol was developed to address this issue.

WebSocket Provides Real-time Communication

Connection-oriented (Bidirectional)
Maintains the connection once established
While the handshake process involves significant header overhead, once the connection is established, only simple messages are exchanged, making it very economical

WebSocket allows real-time communication with these characteristics. WebSocket isn't a replacement for HTTP; it's just one of the protocols commonly used for real-time communication on the web. As mentioned earlier, because it's called WebSocket, it operates on top of the HTTP layer.

When Exactly to Use WebSocket?

It's obvious but used in situations requiring real-time communication. For example:

case 1 | In gaming, where refreshing every time another player takes an action would be very inconvenient
case 2 | During chatting sessions

WebSocket Operation Method

First, Shake Hands 🤝 (Handshaking)! An automated negotiation process that dynamically sets variables for an established communication channel between two entities before normal communication on the channel begins
Now, let's structure the frame for data insertion! Frame Composition

Since the handshake occurs only during the initial connection over the HTTP protocol, we use HTTP headers.

There's no separate port for WebSocket; it utilizes existing ports (HTTP - 80, HTTPS - 443) to ensure compatibility.

Communication occurs through logical units called frames, which are part of the message exchange.

The exchangeable message types (frames) that can be included in a message are limited to text and binary!

Limitations of WebSocket

WebSocket emerged after HTML5. What if you need to implement services using technologies predating HTML5?

Socket.io, SockJS

Socket.io and SockJS are technologies that enable real-time communication similar to WebSocket in services implemented using pre-HTML5 technologies. They facilitate real-time communication.

Ultimately, by identifying the types and versions of browsers and web servers, you can select the most suitable technology to mimic WebSocket functionality!

STOMP

WebSocket merely facilitates the exchange of strings and doesn't handle anything beyond that. The interpretation of the exchanged strings is entirely left to the application.
HTTP, on the other hand, is interpretable as it has predefined formats, provided everyone adheres to the agreed-upon conventions. However, WebSocket often employs sub-protocols to specify the format of the messages being exchanged.
One commonly used sub-protocol is STOMP.

STOMP

Similar with Web Socket

Before WebSocket, there were various methods for achieving real-time communication using HTTP.

HTTP Polling

Periodically sending requests to the server.

Polling: Checking the state of another program periodically for purposes such as collision avoidance or synchronization, and performing data processing when certain conditions are met.

In real-time communication, it's impossible to predict when communication will occur.

Creates unnecessary requests and connections.

Results in unnecessary waiting time between events since requests are made even when there are no events. This introduces a gap between the event occurrence and receiving the response, leading to ambiguous real-time communication.

HTTP Long-Polling Sending a request to the server and keeping the connection open until an event occurs. Upon receiving a response, the connection is closed, and a new request is made.

Long-polling: The client asks the web server if there is any new content. The web server does not respond until new content is available.

Eliminates unnecessary requests (partially addressing the drawback of polling).

Ultimately behaves similarly to polling when a large volume of messages is sent.

HTTP Streaming Sending continuous data without closing the connection after sending a request to the server.

It's difficult for the client to send data to the server.

However...

All of these methods use HTTP for communication, which means both the request and response headers are unnecessarily large (a bottleneck when exchanging data quickly).

But... why is HTTP unidirectional communication?

While summarizing this information, I couldn't clearly understand the difference between HTTP, a web protocol, and TCP. This is because HTTP is fundamentally designed to operate on top of TCP/IP. However, when setting up a TCP server using sockets for real-time communication, why does applying the HTTP protocol result in unidirectional communication? I was puzzled by this question. HTTP's characteristics do indeed include unidirectional communication... but why can't a protocol originally based on TCP provide real-time communication?

Why does HTTP, which is built on top of TCP/IP, behave unidirectionally?

After some research, I concluded that it depends on the perspective.

HTTP is built on top of TCP, meaning it exists as a protocol layered on top of TCP, using sockets as endpoints. Despite numerous articles discussing "HTTP vs. socket," HTTP is essentially a protocol that utilizes socket communication. Therefore, HTTP can be considered a method of communication using sockets.

However, communication involves layers. HTTP and sockets are different protocols that operate on different layers. While TCP/IP-based socket communication (TCP communication) starts from the 4th layer, where packets are generated, HTTP communication starts from the 7th layer, where packets are also generated.

Therefore, from the perspective of the 4th layer, both operate as connection-oriented communication. From the perspective of the 7th layer, HTTP is non-connection-oriented, while socket communication is connection-oriented.

Network - socket (1)

Jasper Oh/YJ Oh — Mon, 26 Feb 2024 23:45:54 +0000

Socket

How / Why socket is appeared?

To make programs to operate on the network easier, system divide the network in to OSI 7 layers and manage it.

BUT, there are limitations to dividing the layers. WHY? Each protocol at each layer is a kind of communication protocol, but specific implementation functions are needed inside for protocol implementation.

Sockets provide the body of these functions. We can use sockets without separate implementations. In other words, instead of defining the detailed specifications of the protocol one by one, we can use sockets.

What is Socket?

A connector, typically utilizing the TCP/IP protocol, is created to enable programs to connect to the network environment for sending and receiving data.

To summarize, a Socket:

Is placed on top of the transport layer in the TCP/IP 4-layer model.
Provides code for protocol control of the transport layer above the transport layer.
In essence, a socket is an endpoint. It exists at both ends of communication, akin to entrances and exits.

What Socket do?

1.Connecting software to software

Connects via IP and service ports.

2.Data communication between software

Locates sockets on the internet, established connections, and transmits data.

What is Socket Programming?

The communication programming using Sockets, which are used for inter-process communication, is called Socket Programming.

It is divided into Client Socket and Server Socket. The socket that accepts communication connection requests is called the "Server Socket", and the socket that sends communication connection requests is called the "Client Socket".

🔥 Although they have the same structure of sockets, they differ slightly in their flow of processing based on their roles.

Socket API Execution Flow (Client, Server)

Client: Socket creation, connection request, data transmission/reception, closing the socket.
Server: Socket creation, binding, listening, accepting, data transmission/reception, closing the socket.

Client Flow

1.Create Client Socket

Create a socket (Empty box socket) with out information about the connection target. When creating the socket, we need to specify the type of socket. For TCP socket, we can specify a stream type, and for UDP sockets, we can specify a datagram type.

2.Connection Request

Send a request to the target we want to connect to, asking to establish a connection. Specify the target destination you want to connect to using the IP address and service port number.

The execution of "Connect" is not completed simply by sending the request; it is completed only when the result of the request comes back.

What is service port?

Service Identification Number

Used in the form of 'IP address: service port'

Enables conversations like "What is the port number for connecting to XX service?"

Default service ports (e.g., port 22 for initial SSH connection, port 80 for HTTP setup)

3.Data Transmission (Send, Receive)

Similar to connection requests, execution is not completed just by sending a request; it is completed only when a response (signal) to the request is received

However, when sending data, you know when and how much data you are sending, but when receiving, there is a difference in that you do not know when and how much data the other party will send. Therefore, the receiving API is typically executed in a separate thread.

4.Closing the Socket

When it is determined that there will be no further data transmission, the socket is closed

Server Flow

0.When I try to send data, the receiving end should not blindly accept data; it should only accept the appropriate process identified by the port number.

1.Create Server Socket
Similar to the client socket, create a shell socket without information about the connection target.

2.Binding (Bind)
When using a computer, numerous services are utilized simultaneously, meaning many processes are running concurrently. If the port numbers of these processes are the same, confusion may arise when the server socket needs to send data back. Therefore, it's necessary to bind the socket with a unique port number to ensure the server socket can create its unique port number.

If the port number used by a socket overlaps with the port number of another socket, what would happen? If all sockets use the same port number, say 10000, then there would be a problem determining which socket should handle data received on port 10000. For this reason, operating systems internally manage port numbers and socket connection information to ensure that sockets do not use duplicate port numbers.

By the way, a single process can bind multiple sockets with the same port number. This means a host can create multiple sockets with the same port and exchange data with other hosts.

Thanks to this, we can chat with many people simultaneously using a single chat app.

So, imagine a scenario where a specific port opens multiple sockets: the first socket for mom, the second for dad, the third for chatting with siblings on Chat app.

3.Client Connection Request Waiting

Once the server socket has completed the binding with the port number, it is ready to accept connection requests from clients.

It waits until a connection request comes from the client and, upon receiving the request, exits the waiting state and returns.

4.Client Connection Establishment
The actual connection begins here!

The server socket, upon accepting a connection request, creates a new socket.

The main role of the server socket is to wait for client connection requests. Therefore, when it receives a connection request from a client, it opens a new socket, maps it with the client socket, and passes it on.

5.Data Transmission (Send, Receive)
Same as for the client.

6.Closing the Socket
Same as for the client. However, the server socket also needs to manage the sockets it creates!

MSA with spring cloud

Jasper Oh/YJ Oh — Sat, 24 Feb 2024 04:19:39 +0000

Before getting deep to understand what is the Micro Service Architecture, we should understand WHY the MSA is introduced.

The main reason of MSA introduce is the Monologue Architecture. Many developer likes to debate with these two different architectures like which is the better one in separate point of view.

Anyway, I don't want to participate in this meaningful(?) debate, but I want to learn & study how to establish, manage, scale or de-scale MSA project. So this is the purpose of this series and this process is based on my personal understand with the book name "Micro-services with Spring Boot 3 and Spring Cloud 3rd" by Magnus Larsson.

FYI, the writer has +1 year experience with Java SpringBoot environment in prev company and almost zero knowledge with Docker and Kubernetes(Only understand the concept). So this series can become longer than I expected.

Hopefully after write and read this series, the writer and reader can briefly understand what is MSA architecture and how to start to build and design. We'll definitively confront with tons of issues together and trying to solve it.

Anyway, talk is cheap lets write code.

C - Pointer & Struct

Jasper Oh/YJ Oh — Mon, 16 Oct 2023 20:02:13 +0000

🔥 This post will discuss about pointer which is the one of the most important concept in C language to actually implement a LinkedList.

So, what is the pointer? what is the definition? (I captured below paragraph from KNK C programming)

Although addresses are represented by numbers, their range of values may differ from that of integers, so we can't necessarily store them in ordinary integer variables. We can, however, store the in special p, we say that p "points to" i. In other words, a pointer is nothing more than an address, and a pointer variable is just a variable that can store an address. KNK C programming P.242

We can understand the concept with the Excel (Google Spreadsheet).

According to above image,

Cell B6, I put value 15.
Cell D9, I put a cell-address with =B6.

You can understand with the code below,

int num = 15; // 1. Cell B6, I put value 15.
int *numPtr = &num; // 2. Cell D9, I put a cell-address with =B6.

Of course, We should think like computer memory, not a cell in excel. B6 and D9 (address value) is almost randomly assigned by compiler.

So, the valuable named "num" is allocated the address of memory. (the size is 4 byte b/c int type)

✅ Just sec in here, I think we should recap the structure of memory.

Memory Structure in C

When we execute a program, OS allocate the memory space for the program. And this allocated memory space is divided by

Data Area
Stack Area
Heap Area

And I'll deal with this memory area soon.

Before that, I'll put more detailed code under about pointer.

Example 1

int main(){
 int x; // 1. declare x -> int variable
 int *ptr_x; // 2. declare pointer var ptr_x, which means this variable can save the memory address and read only 4 bytes because this is int pointer var
 x = 100; // 3. init x with 100
 ptr_x = &x; // 4. save x's memory address in ptr_x
 printf("x : %d, &x : %p\n", x , &x); // 5.using %d to print a decimal format, and %p to pointer(address) format and & operator showing the memory address of x
 printf("*ptr_x: %d, ptr_x: %p\n",*ptr_x, ptr_x); // 6. if we put * operator in pointer var then, It shows the variable that saved in address
 *ptr_x = 200; // 7. change the value to 200 that ptr_x indicate
 printf("x: %d, *ptr_x: %d\n" , x, *ptr_x);
 return 0;
}

🌱 Project Series Intro

Jasper Oh/YJ Oh — Sun, 17 Sep 2023 23:05:01 +0000

In this series, I plan to categorize and organize projects into two distinct types. Firstly, I will delve into academic projects, which I collaborated on with fellow students during my time at BCIT. These projects will include the likes of 1800 and 2800 projects, and I will provide a detailed account of their progression, along with an explanation of my specific contributions.

Irrespective of the project type, the posts in this series will follow the following structure.

Each post will commence with an explanation of the projects theme and how it was executed, with a particular focus on my roles and responsibilities.

During the span of one to two projects, I will employ the STAR strategy to describe the experiences and insights gained.

I will articulate significant aspects and practices that I deem valuable and worth remembering.

I intend to share areas where improvements could have been made and outline what needs to be addressed in future updates.

I will be presenting these projects under these four overarching sections.

As someone who believes in gaining knowledge through exposure to numerous projects, I sincerely appreciate anyone who reads my blog posts and is able to take something away from them. If you have any feedback or suggestions for improvements, please feel free to share them.

I look forward to your continues interest in this ongoing series. Your support is greatly appreciated.

To infinity and beyond 🚀

Jasper Oh/YJ Oh — Wed, 09 Aug 2023 06:39:55 +0000

Why am I writing?

I enjoy writing in general.

If there's something I did well in 2023, it's receiving decent grades at BCIT, getting the opportunity to do a Co-op, and the proudest achievement is consistently keeping a diary. Usually, when the new year arrives, buying a new diary has been a sort of tradition after becoming an adult.

While reflecting on past diaries, I took the time to read through the chaotic diary of 2020, and while setting a dream for 2021, I was able to engage in my own form of studying.

Anyway, as I reflected on the writings composed of tangled sentences, it naturally guided me towards how to live from the standpoint of 2023.

This blog also came about with the thought of creating not just a record or study notes but a compass for my future self.

Having a dream and following that path, these writings become an affectionate compass.

It's as if this could be the README.md file of the project named JasperLife?

Really want to make a branch of my life with...
git branch test_life

How should I make it?

First, I'll use it primarily to record what I've learned.

Based on, STAR framework
S - situation T - task A - Action R - Result
I'll document various situations that arise, set goals to improve them, and record the actions I took to achieve these results.

Starting from past projects and continuing through reflections, I believe I can document what I've felt, learned, and how my thoughts process have evolved over time.

Conclusion?

Studying various topics related to programming and seeing the connections I've made along the way has brought me immense joy in my learning journey. And now, I realize that it's important to solidify what I've learned as I organize and document my studies up to the present.

Continuing to write this blog consistently, I hope to accurately delineate my areas of interest and contribute to significant growth in the future.

And Ofcourse, I want to get lots of feedback from dev users🙂