
## What is Visitor Design Pattern ?

The Visitor Design Pattern is a behavioral design pattern used to separate algorithms from the objects on which they operate. This pattern allows you to add new operations to existing object structures without modifying those structures. It is particularly useful when you need to perform a series of operations on objects with different types.

## Key Components of the Visitor Pattern
 ### Visitor Interface: 
 This defines the visit operations for each type of element (object). In your case, visitorInterface serves this role.

### Concrete Visitors: 
These classes implement the visitor interface and provide specific behavior for each type of element. For example, hotelVisitor, petrolPumpVisitor, and groceryVisitor are concrete visitors in your implementation.

### Element Interface: 
This is an interface that allows the visitor to perform operations on the elements. The cardInterface class in your code represents this.

### Concrete Elements: 
These are the classes that implement the element interface and accept visitors. creditCard, debitCard, and chargeCard are concrete elements in your example.

### Accept Method: 
Each concrete element class must have an accept method that takes a visitor as a parameter. This method calls the appropriate visit method on the visitor. In your case, accept methods are implemented in creditCard, debitCard, and chargeCard.

--------------
Let's consider one example scenario stated below .
Suppose we have a case like we have different types of payment cards and we have to provide different discounts based on the merchants and the cards .	         


For Debit card hotel-discount=10% , petrol-pump=5% , grocery=6%  similarly for credit card hotel-discount=8% , petrol-pump=4% , grocery=3% and for charge card hotel-discount=6% , petrol-pump=3% , grocery=1% 

						
The person who is unaware about visitor design pattern will follow a generic and traditional approach of binding the operations or methods to the objects i.e. classes .
for e.g. 
```js
class debitCard{
	hotel(){};
	petrol_pump(){};
	grocery(){};
}	
class creditCard{
	hotel(){};
	petrol_pump(){};
	grocery(){};
}
class chargeCard{
	hotel(){};
	petrol_pump(){};
	grocery(){};
}	
```		
It may look convenient but consider onboarding merchants in future , the classes will increase in number and similarly , if the types of cards increase then also it is a tedious task to refactor the whole code .
To overcome this problem , visitor design pattern came into picture .
This design pattern moves operational logic into other classes making it easy to manage the increasing classes and methods . It involves creating visitor abstract class which will be inherited or implemented by concrete visitors (in our case hotelVisitor, petrolPumpVisitor , groceryVisitor will implement visitorInterface) and there will be classes for objects which also can be implemented from a common interface (in our case creditCard, debitCard, chargeCard will implement cardInterface ) . Visitors have operational logic and perform specific operations as per the object passed into it dynamically . This makes the card classes simpler and focused only on their core responsibilities .

```js
#include<iostream>
using namespace std;

//pre-declaring the concrete classes 
class debitCard;
class creditCard;
class chargeCard;

//visitor interface 
class visitorInterface{ 
	public:
	virtual void visitDebitCard(debitCard * debit_card_element)=0;
	virtual void visitCreditCard(creditCard *credit_card_element)=0;
	virtual void visitChargeCard(chargeCard * charge_card_element)=0;
	/*
	.... we can have multiple visitor functions here which the concrete visitors will override 
	*/
};

//This card interface declares the accept method that allows a visitor to visit the elements.
class cardInterface{ 
	public:
	virtual void accept(visitorInterface * visitor_interface_element)=0;
};

//Each concrete element (creditCard, debitCard, chargeCard) implements the cardInterface and accepts a visitor. The "accept" method calls the appropriate visit method on the visitor.
class creditCard : public cardInterface{
	public:
	void accept(visitorInterface *visitor_interface_instance)override{
		visitor_interface_instance->visitCreditCard(this);
	}
};

class debitCard : public cardInterface{
	public:
	void accept(visitorInterface *visitor_interface_instance)override{
		visitor_interface_instance->visitDebitCard(this);
	}
};
class chargeCard : public cardInterface{
	public:
	void accept(visitorInterface *visitor_interface_instance)override{
		visitor_interface_instance->visitChargeCard(this);
	}
};


//Each concrete visitor (hotelVisitor, petrolPumpVisitor, groceryVisitor) implements the visitorInterface and provides specific behavior for each type of card.
class hotelVisitor : public visitorInterface{ //concrete visitor 
	public:
	void visitDebitCard(debitCard * debit_card_element)override{
		cout<<"Debit card visitor for hotel 10% discount"<<endl;
	}
	void visitCreditCard(creditCard * credit_card_element)override{
		cout<<"Credit card visitor for hotel 8% discount"<<endl;
	}
	void visitChargeCard(chargeCard * charge_card_element)override{
		cout<<"Charge card visitor for hotel 6% discount"<<endl;
	}	
};

class petrolPumpVisitor : public visitorInterface{ //concrete visitor 
	public:
	void visitDebitCard(debitCard * debit_card_element)override{
		cout<<"Debit card visitor for petrol pump 5% discount"<<endl;
	}
	void visitCreditCard(creditCard * credit_card_element)override{
		cout<<"Credit card visitor for petrol pump 4% discount"<<endl;
	}
	void visitChargeCard(chargeCard * charge_card_element)override{
		cout<<"Charge card visitor for petrol pump 3% discount"<<endl;
	}	
};

class groceryVisitor : public visitorInterface{ //concrete visitor 
	public:
	void visitDebitCard(debitCard * debit_card_element)override{
		cout<<"Debit card visitor for grocery 6% discount"<<endl;
	}
	void visitCreditCard(creditCard * credit_card_element)override{
		cout<<"Credit card visitor for grocery 3% discount"<<endl;
	}
	void visitChargeCard(chargeCard * charge_card_element)override{
		cout<<"Charge card visitor for grocery 1% discount"<<endl;
	}	
};



int main(){
	creditCard c1;
    debitCard d1;
    chargeCard ch1;

    hotelVisitor hv1;

    // Applying visitor to each card type
    c1.accept(&hv1);
    d1.accept(&hv1);
    ch1.accept(&hv1);

    return 0;
}

```

## Benefits of the Visitor Pattern in Your Code
### Separation of Concerns: 
The logic for discounts is separated from the card classes. This makes the card classes simpler and focused only on their core responsibilities.

### Extensibility: 
Adding new types of visitors (e.g., restaurantVisitor) or new card types can be done with minimal changes. You only need to add new classes without modifying the existing ones.

### Maintenance: 
Modifying discount calculations or adding new types of discounts can be done by updating or adding new visitor classes.


Visitor Design Pattern in Software Engineering


## What is the problem that this design pattern solves ?
Let's take a classical example of a coffee shop .
There is a coffee class . Suppose you want to give user choices to construct object with his choice for eg. Users can add extra whipped cream , mousse toppings or sweet cream . 
Now we need to define many subclasses to solve the above issue like coffee_with_extra_whipped_cream , coffee_with_mousse_toppings , coffee_with_sweet_cream . Now consider the user wants coffee with extra whipped cream as well as mousse toppings . Now we need to consider each and every combination and create subclasses for it . For this case you may say that it is convenient here . But if there are many possibilities for object creation , it is not a convenient method for defining subclasses for each and every object .
This is where the decorator design pattern comes into picture . The main idea in this design pattern is  there are concrete classes to construct base objects and there are decorator classes to decorate the object as per users choice . In the above case we will have a coffee class which will act as base class and it will create the base object . There will be the decorator classes like whipped_cream , mousse_toppings , sweet_cream and many more . The reference of the coffee object will be present in decorators and the functions will be present in the decorators to decorate the object as needed . 


```cpp
#include <iostream>
#include <string>

using namespace std;

// Abstract base class for the coffee
class Coffee {
public:
    virtual string getDescription() const = 0;
    virtual double cost() const = 0;
    virtual ~Coffee() {}
};

// Concrete implementation of a basic coffee
class SimpleCoffee : public Coffee {
public:
    string getDescription() const override {
        return "Simple Coffee";
    }

    double cost() const override {
        return 1.0; // Base price for simple coffee
    }
};

// Decorator base class
class CoffeeDecorator : public Coffee {
protected:
    Coffee* coffee;
public:
    CoffeeDecorator(Coffee* c) : coffee(c) {}

    string getDescription() const override {
        return coffee->getDescription();
    }

    double cost() const override {
        return coffee->cost();
    }
};

// Concrete decorator class for adding whipped cream
class WhippedCreamDecorator : public CoffeeDecorator {
public:
    WhippedCreamDecorator(Coffee* c) : CoffeeDecorator(c) {}

    string getDescription() const override {
        return coffee->getDescription() + ", Whipped Cream";
    }

    double cost() const override {
        return coffee->cost() + 0.5; // Extra cost for whipped cream
    }
};

// Concrete decorator class for adding mousse toppings
class MousseToppingsDecorator : public CoffeeDecorator {
public:
    MousseToppingsDecorator(Coffee* c) : CoffeeDecorator(c) {}

    string getDescription() const override {
        return coffee->getDescription() + ", Mousse Toppings";
    }

    double cost() const override {
        return coffee->cost() + 0.75; // Extra cost for mousse toppings
    }
};

// Concrete decorator class for adding sweet cream
class SweetCreamDecorator : public CoffeeDecorator {
public:
    SweetCreamDecorator(Coffee* c) : CoffeeDecorator(c) {}

    string getDescription() const override {
        return coffee->getDescription() + ", Sweet Cream";
    }

    double cost() const override {
        return coffee->cost() + 0.6; // Extra cost for sweet cream
    }
};

int main() {
    // Create a simple coffee
    Coffee* myCoffee = new SimpleCoffee();
    cout << "Description: " << myCoffee->getDescription() << ", Cost: $" << myCoffee->cost() << endl;

    // Add whipped cream
    myCoffee = new WhippedCreamDecorator(myCoffee);
    cout << "Description: " << myCoffee->getDescription() << ", Cost: $" << myCoffee->cost() << endl;

    // Add mousse toppings
    myCoffee = new MousseToppingsDecorator(myCoffee);
    cout << "Description: " << myCoffee->getDescription() << ", Cost: $" << myCoffee->cost() << endl;

    // Add sweet cream
    myCoffee = new SweetCreamDecorator(myCoffee);
    cout << "Description: " << myCoffee->getDescription() << ", Cost: $" << myCoffee->cost() << endl;

    delete myCoffee;

    return 0;
}

```

Decorator design pattern


# CAP theorem can be explained with the following trade-off:

## Consistency (C) 
Everyone sees the same data at the same time.

## Availability (A)
Every request gets a response, without guaranteeing it's the most recent data.

## Partition Tolerance (P)
The system continues to work despite network issues or "partitions."

![Create routes via your file + folder structure](cap.png)

The CAP theorem asserts that a distributed system can achieve at most two out of these three properties simultaneously. In the presence of a network partition, a system has to choose between maintaining consistency or availability. In other words:

If a system prioritizes Consistency and Partition Tolerance, it may experience unavailability during network partitions.

If a system prioritizes Availability and Partition Tolerance, it may sacrifice consistency, potentially serving stale or conflicting data during network partitions.

If a system prioritizes Consistency and Availability, it may choose to halt operations during network partitions to ensure that all nodes have consistent data.

# Let's use some scenarios to illustrate the trade-offs in the CAP theorem:

## Scenario 1: Prioritizing Consistency and Partition Tolerance

Consistency (C): All nodes have the same data at the same time.

Availability (A): The system may become unavailable during network partitions to ensure that all nodes have consistent data.

Partition Tolerance (P): The system can still function even if there are network issues.

Example: Imagine a banking system where transferring money between accounts needs to be perfectly consistent. During a network partition, the system may choose to become temporarily unavailable to prevent any inconsistencies in account balances.

## Scenario 2: Prioritizing Availability and Partition Tolerance

Consistency (C): There might be a delay in propagating updates to all nodes, so not everyone sees the latest data immediately.

Availability (A): The system remains operational even during network partitions, and clients receive responses.

Partition Tolerance (P): The system can handle network partitions without sacrificing availability.

Example: Consider a social media feed where the latest posts might not be instantly visible to all users during network issues. However, the system remains available, allowing users to interact with the content that is currently accessible.

## Scenario 3: Prioritizing Consistency and Availability

Consistency (C): All nodes have the same data at the same time.

Availability (A): The system may choose to become unavailable during network partitions to ensure that all nodes have consistent data.

Partition Tolerance (P): The system can still function even if there are network issues.

Example: In a stock trading platform, it's crucial that all users see the same stock prices. During a network partition, the system might temporarily halt trading to avoid discrepancies in stock values.




CAP theorem for Databases


## What is Design Pattern ?

Design patterns are reusable solutions to common problems that arise during software design and development. They are like templates or blueprints that provide a way to structure code to solve specific types of problems. Design patterns are not complete solutions or ready-made code; instead, they offer general guidelines and best practices.

These patterns help developers create software that is more modular, flexible, and maintainable. They encapsulate proven design principles and promote code organization that facilitates easier understanding and modification of the software.

## There are many design patterns which can be categorized as belows 

### 1. Creational Design Pattern
    Factory Pattern , Builder Pattern , Singleton Pattern

### 2. Structural Desgin Pattern
    Proxy pattern , Adaptor pattern 

### 3. Behavioral Design Pattern
    Observer Pattern , Iterator Pattern

# Lets discuss above all in detail below 

## Factory Pattern 

The Factory Pattern is a creational design pattern that provides an interface for creating instances of a class, but allows subclasses to alter the type of objects that will be created. In other words, it defines an interface or abstract class for creating objects, but the actual instantiation is delegated to its subclasses.

Product Interface/Abstract Class:

This defines the interface or abstract class for the object to be created.

Concrete Products:

These are the actual classes that implement the Product interface or extend the Product abstract class. Each concrete product provides a specific implementation of the object to be created.

Creator Interface/Abstract Class:

This declares the factory method that returns an object of type Product. The Creator class may also include some default implementation for other methods.

Concrete Creators:

These are the classes that implement the Creator interface or extend the Creator abstract class. Each concrete creator class provides an implementation for the factory method, which creates and returns a specific instance of the Product.

```js
// Step 1: Product Interface
interface Product {
    void create();
}

// Step 2: Concrete Products
class ConcreteProductA implements Product {
    @Override
    public void create() {
        System.out.println("Product A is created");
    }
}

class ConcreteProductB implements Product {
    @Override
    public void create() {
        System.out.println("Product B is created");
    }
}

// Step 3: Creator Interface
interface Creator {
    Product factoryMethod();
    void operation();
}

// Step 4: Concrete Creators
class ConcreteCreatorA implements Creator {
    @Override
    public Product factoryMethod() {
        return new ConcreteProductA();
    }

    @Override
    public void operation() {
        Product product = factoryMethod();
        System.out.println("Creator A uses " + product.getClass().getSimpleName());
    }
}

class ConcreteCreatorB implements Creator {
    @Override
    public Product factoryMethod() {
        return new ConcreteProductB();
    }

    @Override
    public void operation() {
        Product product = factoryMethod();
        System.out.println("Creator B uses " + product.getClass().getSimpleName());
    }
}

// Step 5: Client Code
public class FactoryPatternExample {
    public static void main(String[] args) {
        // Using ConcreteCreatorA
        Creator creatorA = new ConcreteCreatorA(); // Creating an instance of ConcreteCreatorA
        creatorA.operation(); // Output: Creator A uses ConcreteProductA

        // Using ConcreteCreatorB
        Creator creatorB = new ConcreteCreatorB(); // Creating an instance of ConcreteCreatorB
        creatorB.operation(); // Output: Creator B uses ConcreteProductB
    }
}

```
Product Interface (Step 1):

Product interface declares the method create(), which is implemented by concrete products (ConcreteProductA and ConcreteProductB).

Concrete Products (Step 2):

ConcreteProductA and ConcreteProductB are the concrete implementations of the Product interface. They provide specific implementations of the create() method.

Creator Interface (Step 3):

Creator interface declares two methods: factoryMethod() and operation(). The factoryMethod() is responsible for creating a product, and operation() is a method used by clients to interact with the created product.

Concrete Creators (Step 4):

ConcreteCreatorA and ConcreteCreatorB are concrete implementations of the Creator interface. They provide specific implementations for the factoryMethod() and operation() methods.

Client Code (Step 5):

In the main method of the FactoryPatternExample class, we create instances of ConcreteCreatorA and ConcreteCreatorB and call their operation() methods. This demonstrates how different creators can create different products without the client knowing the concrete product classes.

## Builder Pattern 

The Builder Pattern is a creational design pattern that separates the construction of a complex object from its representation, allowing the same construction process to create different representations. It is especially useful when an object has a large number of parameters, and you want to provide a more readable and maintainable way to construct instances of that object. The Builder Pattern allows you to construct a product step by step, specifying only the desired features, and providing a more fluent and readable way to create complex objects.

```js
// Step 1: Product class with a complex construction process
class Product {
    private String part1;
    private String part2;
    private String part3;

    // Private constructor to force the use of the builder
    private Product() {}

    // Getter methods for the parts

    public String getPart1() {
        return part1;
    }

    public String getPart2() {
        return part2;
    }

    public String getPart3() {
        return part3;
    }

    // Step 2: Builder interface
    interface Builder {
        Builder buildPart1(String part1);
        Builder buildPart2(String part2);
        Builder buildPart3(String part3);
        Product build(); // Build method to create the final product
    }

    // Step 3: Concrete Builder class implementing the Builder interface
    static class ConcreteBuilder implements Builder {
        private Product product = new Product();

        @Override
        public Builder buildPart1(String part1) {
            product.part1 = part1;
            return this;
        }

        @Override
        public Builder buildPart2(String part2) {
            product.part2 = part2;
            return this;
        }

        @Override
        public Builder buildPart3(String part3) {
            product.part3 = part3;
            return this;
        }

        @Override
        public Product build() {
            return product;
        }
    }

    // Step 4: Director class to orchestrate the construction process
    static class Director {
        public Product construct(Builder builder) {
            return builder
                    .buildPart1("Part 1")
                    .buildPart2("Part 2")
                    .buildPart3("Part 3")
                    .build();
        }
    }
}

// Step 5: Client Code
public class BuilderPatternExample {
    public static void main(String[] args) {
        // Creating a builder
        Product.Builder builder = new Product.ConcreteBuilder();

        // Creating a director
        Product.Director director = new Product.Director();

        // Constructing the product using the director and builder
        Product product = director.construct(builder);

        // Accessing the parts of the constructed product
        System.out.println("Part 1: " + product.getPart1());
        System.out.println("Part 2: " + product.getPart2());
        System.out.println("Part 3: " + product.getPart3());
    }
}

```

Product class (Step 1):

Represents the complex object to be constructed.
It has a private constructor to enforce the use of the builder.

Builder interface (Step 2):

Declares the methods to build different parts of the product and a build() method to create the final product.

Concrete Builder class (Step 3):

Implements the builder interface.
Constructs and assembles parts of the product.

Director class (Step 4):

Orchestrates the construction process using a builder.
Defines a method (construct) that takes a builder and constructs a product using it.

Client Code (Step 5):

Creates a builder (ConcreteBuilder).
Creates a director.
Uses the director to construct a product through the builder.
Accesses and prints the parts of the constructed product.

## Singleton Design Pattern 

The Singleton Pattern is a creational design pattern that ensures a class has only one instance and provides a global point of access to that instance. It is used when exactly one instance of a class is needed to coordinate actions across the system. The Singleton Pattern is often employed for logging, driver objects, caching, thread pools, database connections, and more. The Singleton Pattern ensures that there is only one instance of the class, and it provides a global point of access to that instance. The lazy initialization technique in the example delays the creation of the instance until it is first needed, improving performance.

```js
// Step 1: Singleton class
public class Singleton {
    // Step 2: Private static instance variable
    private static Singleton instance;

    // Step 3: Private constructor to prevent instantiation from outside
    private Singleton() {
        // Private constructor to prevent instantiation
    }

    // Step 4: Public static method to get the instance
    public static Singleton getInstance() {
        // Step 5: Lazy initialization (creating the instance only when needed)
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }

    // Other methods and properties of the singleton
    public void showMessage() {
        System.out.println("Hello, I am a Singleton!");
    }
}

// Step 6: Client Code
public class SingletonPatternExample {
    public static void main(String[] args) {
        // Attempt to create instances directly (will not work)
        // Singleton obj = new Singleton(); // Error: Singleton() has private access in Singleton

        // Get the singleton instance using the public method
        Singleton singleton1 = Singleton.getInstance();
        Singleton singleton2 = Singleton.getInstance();

        // Both instances should be the same
        System.out.println(singleton1 == singleton2); // Output: true

        // Using the singleton instance
        singleton1.showMessage(); // Output: Hello, I am a Singleton!
        singleton2.showMessage(); // Output: Hello, I am a Singleton!
    }
}

```
Singleton class (Step 1):

Represents the singleton class.

Private static instance variable (Step 2):

Holds the single instance of the class.

Private constructor (Step 3):

Ensures that the class cannot be instantiated from outside the class.

Public static method to get the instance (Step 4):

Provides a global point of access to the single instance.

Lazy initialization (Step 5):

Creates the instance only when it is needed, making it efficient.

Client Code (Step 6):

Demonstrates the usage of the singleton pattern.
Attempts to create instances directly result in a compilation error.
Gets the singleton instance using the getInstance() method.
Verifies that both instances obtained are the same.
Calls a method on the singleton instance.

## Iterator Pattern

The Iterator Pattern is a behavioral design pattern that provides a way to access elements of an aggregate object sequentially without exposing its underlying representation. It defines a common interface for iterating over various types of collections, allowing the client to traverse the elements of a collection without needing to know the specific details of its implementation. The Iterator Pattern helps decouple the client code from the internal structure of the collection, providing a way to iterate over elements without exposing the details of the collection's implementation. This promotes flexibility and allows different types of collections to be iterated in a uniform way.

```js
// Step 1: Iterator interface
interface Iterator<T> {
    boolean hasNext();
    T next();
}

// Step 2: Aggregate interface
interface Aggregate {
    Iterator<String> createIterator();
}

// Step 3: Concrete Iterator class
class ConcreteIterator implements Iterator<String> {
    private String[] elements;
    private int index = 0;

    public ConcreteIterator(String[] elements) {
        this.elements = elements;
    }

    @Override
    public boolean hasNext() {
        return index < elements.length;
    }

    @Override
    public String next() {
        if (hasNext()) {
            return elements[index++];
        }
        return null;
    }
}

// Step 4: Concrete Aggregate class
class ConcreteAggregate implements Aggregate {
    private String[] elements;

    public ConcreteAggregate(String[] elements) {
        this.elements = elements;
    }

    @Override
    public Iterator<String> createIterator() {
        return new ConcreteIterator(elements);
    }
}

// Step 5: Client Code
public class IteratorPatternExample {
    public static void main(String[] args) {
        // Creating an aggregate with elements
        String[] elements = {"Apple", "Banana", "Orange", "Grapes"};
        Aggregate aggregate = new ConcreteAggregate(elements);

        // Creating an iterator for the aggregate
        Iterator<String> iterator = aggregate.createIterator();

        // Using the iterator to traverse elements
        while (iterator.hasNext()) {
            String element = iterator.next();
            System.out.println("Element: " + element);
        }
    }
}

```
Iterator interface (Step 1):

Defines the interface for the iterator, including methods like hasNext() to check for the next element and next() to retrieve the next element.

Aggregate interface (Step 2):

Declares the method createIterator(), which creates an iterator for traversing elements of the aggregate.

Concrete Iterator class (Step 3):

Implements the iterator interface.
Maintains the position in the collection and provides methods to check for the next element and retrieve it.

Concrete Aggregate class (Step 4):

Implements the aggregate interface.
Provides a method to create an iterator for the specific collection.

Client Code (Step 5):

Creates an aggregate (ConcreteAggregate) with a set of elements.
Obtains an iterator from the aggregate using the createIterator() method.
Uses the iterator to traverse the elements of the aggregate without exposing its internal representation.

## Adaptor Design Pattern

The Adapter Pattern is a structural design pattern that allows incompatible interfaces to work together. It acts as a bridge between two incompatible interfaces by converting the interface of a class into another interface that a client expects. This pattern involves a single class called the Adapter, which is responsible for joining functionalities of independent or incompatible interfaces.

```js
// Step 1: Target Interface (the expected interface by the client)
interface Target {
    void request();
}

// Step 2: Adaptee (an existing class with a different interface)
class Adaptee {
    void specificRequest() {
        System.out.println("Adaptee's specific request");
    }
}

// Step 3: Adapter class implementing the Target interface
class Adapter implements Target {
    private Adaptee adaptee;

    public Adapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    @Override
    public void request() {
        adaptee.specificRequest();
    }
}

// Step 4: Client Code
public class AdapterPatternExample {
    public static void main(String[] args) {
        // Creating an instance of the Adaptee
        Adaptee adaptee = new Adaptee();

        // Creating an instance of the Adapter, passing the Adaptee to it
        Target adapter = new Adapter(adaptee);

        // Using the Adapter to make a request (compatible with Target interface)
        adapter.request(); // Output: Adaptee's specific request
    }
}

```

Target Interface (Step 1):

Target is the interface expected by the client. In this example, it declares the request() method.

Adaptee (Step 2):

Adaptee is an existing class with a different interface. It has a method called specificRequest().

Adapter class (Step 3):

Adapter is a class that implements the Target interface and contains an instance of the Adaptee.
The request() method of the Adapter calls the specificRequest() method of the Adaptee, making it compatible with the Target interface.

Client Code (Step 4):

Creates an instance of the Adaptee.
Creates an instance of the Adapter, passing the Adaptee to it.
Uses the Adapter to make a request, which internally invokes the specificRequest() method of the Adaptee.



Design Patterns in Software Engineering



First of all I want to thank all of you. My previous article blew off thanks to all of you and I hope you will keep supporting me with your likeness for my articles in future. So now lets get to the article.

So you have learnt React Js basics. Now what next? Here are the three things, you should learn one of them after you had learnt React Js basics.

## 1. Auth0

![Create routes via your file + folder structure](2.png)

Auth0 is basically an authentication and authorization program for your React Js application. It provides all the tools necessary to build and run a secure identity infrastructure including authentication, data protection, and password management.

You will need to implement some type of authentication program in your application when a user logs in. Auth0 is very helpful in this case. You can easily download and implement it.

## 2. Axios or AJAX

![Create routes via your file + folder structure](3.jpg)

Axios is a library for React Js that is used to implement AJAX in your applications. AJAX is used to fetch or give data to APIs, Databases or any other data storing technologies.

You will need Axios to implement AJAX which you will need for sign up and login, displaying or using data from APIs. In short, you will need it in most of your projects or applications.

## 3. React Router

![Create routes via your file + folder structure](4.png)

React Router is a powerful library that helps to implement routing in React Js applications. In normal JavaScript we can go to a webpage by using anchor ( <a> ) tag. However, because JavaScript is not written inside HTML instead HTML is written inside JavaScript in React Js, we need another way of travelling between webpages or Components in React Js

Here comes the React Router to rescue. It provides a way to travel or redirect from one Component to another Component in React Js. It will be important to learn if you want to make a website ( website is the collection of webpages linked together ) with React Js.


What after react basics


##  [React-i18next](https://react.i18next.com/).


![Create routes via your file + folder structure](first.png)

React-i18next is another popular internationalization library that uses **components to render or re-render the translated content of your application** once users request a change of language in your app. Can be done in multiple languages!

##  [React-Hook-Form](https://react-hook-form.com/get-started/).

![Create routes via your file + folder structure](second.png)

It helps you validate forms in React. It is a minimal library without any other dependencies, while being performant and straightforward to use, it helps developers to use fewer lines of code with great validation and error handling!

##  [Recharts](https://recharts.org/en-US/).

This library helps you build charts smooth and easy without any pain. these dynamic charts are composable as quickly build and also reusable, reliable as light as we feather and powerful you can customize your chart easily.

##  [React-beautiful-dnd](https://react-beautiful-dnd.netlify.app/?path=/story/single-vertical-list--within-a-larger-scroll-container).

![Create routes via your file + folder structure](third.png)

Has various drag-and-drop features for your app which makes your app interactive and beautiful!

##  [Framer-motion](https://www.framer.com/motion/).

![Create routes via your file + folder structure](fourth.png)

Production-ready declarative animations. A simple declarative syntax means you write less code. Less code means your codebase is easier to read and maintain.

That’s all for today will be making more amazing content! Clap if this article helped you get started! Thanks!

Amazing React Libraries


## 1. useState-

store the state and change it with setState()

![Create routes via your file + folder structure](usestate.png)

## 2. useReducer

For more complex state logic, the alternative way for useState is useReducer

setup the state with useReducer with reduce function which is a switch…case


****const [state,dispatch]=useReducer(reducer,{count:0,text:showText})****


reducer is the function to change state with conditions

initial the count and text after it

when dispatching the state, means the state changes, then we look for the reducer function.

![Create routes via your file + folder structure](useReducer.png)

The action type decides how the state turns.

When clicking, we can trigger onClick with dispatch according to different types.

![Create routes via your file + folder structure](useReducer2.png)

## 3. useEffect-

the action will call when rendering

Such as fetching the API when the page renders

****useEffect(()=>{…}) Call every time rendering****

****useEffect(()=>{…},[])Call with the condition applied****

For example, Whenever the [?] changes, call.If empty [ ], call once.

![Create routes via your file + folder structure](useEffect.png)

## 4. useRef-

easy to access DOM and manipulate it

return a ‘ref’ object

Value is persisted in the refContainer.current property

![Create routes via your file + folder structure](useRef.png)

useRef(null) set a ref initially

remember to call the ref in the input tag to connect them.

When clicking the button, return the ref value with .current.value

## 7. useContext

![Create routes via your file + folder structure](useContext.png)


**createContext** in the parent component and run with **Provider**

pass the **value** in parent component to child component in attr

![Create routes via your file + folder structure](useContext2.png)

import in the **AppContext** to get the setUsername

**useContext** in the child component and manipulate the state in the parent







React Hooks: All You Need 

## Using React Portals-

To show you how portals work, consider we have the following basic React code inside our App.js file. Here, we want the modal to appear on top of everything else. As such, we've created a div called #modal-container. This is ultimately where we want all of our modals to go into:


import logo from './logo.svg';
import './App.css';
import { useState } from 'react'
import Modal from './components/Modal.js';

```js

function App() {
    const [isModalOpen, setIsModalOpen] = useState(false);
    return (
        <div className="App">
            <header className="App-header">
                <img src={logo} className="App-logo" alt="logo" />
                <p>
                Edit <code>src/App.js</code> and save to reload.
                </p>

                <button onClick={() => setIsModalOpen(!isModalOpen)}>
                    Click to Open Modal
                </button>
                <Modal modalState={isModalOpen} onClickEvent={() => setIsModalOpen(!isModalOpen)}>
                    This is Modal Content!
                </Modal>
            </header>
            <div id="modal-container"></div>
        </div>
    );
}

export default App;
```

Inside App.js, I've imported a component called Modal. This is our Modal component, which will pop up any time the user clicks the button. Whenever isModalOpen is set to true using setIsModalOpen(), the modal should appear. Otherwise, it'll disappear.

I've also got a bit of CSS to ensure our modals do indeed appear on top of everything else:

```css
#modal-container {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    z-index: 9999;
    height: 100%;
    pointer-events: none;
}

.modal {
    position: absolute;
    top: 200px;
    background: white;
    border-radius: 4px;
    left: calc(50% - 100px);
    width: 200px;
}
```

## Creating our portal-

Creating a potal is pretty easy - there is one function, createPortal(). Instead of returning some DOM in React, we return the Portal instead. createPortal() accepts two arguments - the DOM element we want to return - in this case, the modal - and the DOM element we want to teleport our DOM element to. So our second argument is document.getElementById('modal-container'), since we want to put all of our modals into #modal-container:

```js
import { createPortal } from 'react-dom';

function Modal({modalState, onClickEvent}) {

    if(!modalState) return null;

    return (
        createPortal(
            <div className="modal">
                <button onClick={onClickEvent}>Close Modal</button>
                <div className="modal-content">Modal Content goes here</div>
            </div>, 
            document.getElementById('modal-container')
        )
    );
};

export default Modal;
```
Although we teleported our DOM element to modal-container, it still behaves like a normal React child. Since the Portal still exists in the React tree, features like the context the element is in still work the same.

It should also be noted that although we have modal-container and Modal in the same file, the place you teleport your DOM element to can be anywhere in your React code. So you could teleport it to a completely different sub component, element, or parent anywhere in the DOM. It's pretty powerful, and useful - so use it wisely.

Let's look back at our App.js HTML:

```js
    
    <button onClick={() => setIsModalOpen(!isModalOpen)}>
        Click to Open Modal
    </button>
    <Modal modalState={isModalOpen} onClickEvent={() => setIsModalOpen(!isModalOpen)}>
        This is Modal Content!
    </Modal>
</header>
<div id="modal-container"></div>
```
Now, even though Modal sits in our header, it will appear in #modal-container whenever we open the modal using the button:

![Create routes via your file + folder structure](final.png)

Using React Portals



## Props Drilling-

Prop drilling occurs when a component must receive props from its parent component, and then pass them down to its child components.

This can create a deeply nested structure that is difficult to understand and maintain. In addition, it can make it difficult to reuse components, since they may be tightly coupled to their parents.

Therefore, it is best to avoid prop drilling by refactoring your code to reduce the depth of nesting. This will make your code more readable and maintainable and will make it easier to reuse components in the future.

To refactor the code one can use state management libraries like redux, however redux is heavy work, so sometimes context API can be a better suitable option.

## Nested Components

In ReactJS, modularization is accomplished through the use of components. It is common to use nested inline components. For example

```js
import React from 'react';
const NestedComponent= props => {
    const ChildComponent = () => {
        return <div>Child Component</div>;
    }
    return (
        <div>
            <ChildComponent />
        </div>
    );
};
export default NestedComponent;
```

However, it is generally considered bad practice to nest these components too deeply.

Nested components can make the code difficult to read and understand, and they can also lead to performance issues.

Whenever the parent component will be called, the inline component will be recreated, even when the component will rerender, it will still be created, and again and again, it will leave you with a performance hole. So it is always better to create your child component separately.

So instead of writing components like the above example, a simple refactor may help in this case.

```js
import React from 'react';const ChildComponent = () => {
   return <div>Child Component</div>;
}const NestedComponent= props => {
    return (
        <div>
            <ChildComponent />
        </div>
    );
};
export default NestedComponent;
```

## Avoid Huge Components-

In Reactjs you can create almost a whole application in one component, there is absolutely nothing that stops you from doing that.

Any experienced software engineer will tell you that one of the worst things you can do is create a huge, monolithic component.


## Index as a key prop-

Many of the ReactJS developers do not understand why a key prop is needed, so when even they write a loop and Reactjs will give them a warning. So they tend to use index and key prop.

## Never do it again, but why?

Keys help React identify which items have changed, are added, or are removed. Keys should be given to the elements inside the array to give the elements a stable identity.

The best way to pick a key is to use a string that uniquely identifies a list item among its siblings.

## Not Memorizing Complex Calculations-

Sometimes developers may need to do heavy calculations in a Reactjs component. It is might take good computing power and slow down the component a little bit, which is ok.

For example 

```js
const ComplexComponent = props => {
    const complexOutput = complexCalculationFunction(props);
    return (
        <div>
            Do Something
        </div>
    );
};
export default ComplexComponent;
```

But as we know component re-renders whenever there is a change in state and prop. so every time this calculation will be done again.

So what if the component can remember the calculation that was done when the factors which determine the calculation have not changed, that will be really good.

The good news is, there is useMemo present, it can be used for Memorizing the calculations.

```js
const ComplexComponent = props => {
    const complexOutput = useMemo(() => complexCalculationFunction(props.a, props.b), [props.a, props.b]);
    return (
        <div>
            Do Something
        </div>
    );
};
export default ComplexComponent;
```

![Create routes via your file + folder structure](inComp.jpeg)

5 Common Reactjs Anti patterns


NextJS is a **framework for ReactJS**.

Wait a second ... a "framework" for React? Isn't React itself already a framework for JavaScript?

Well ... first of all, React is a "library" for JavaScript. That seems to be important for some people.

Not for me, but still, there is a valid point: React already is a framework / library for JavaScript. So it's already an extra layer on top of JS.

## Why would we then need NextJS?

Because NextJS makes building React apps easier - especially React apps that should have server-side rendering (though it does way more than just take care of that).

In this article, we'll dive into the core concepts and features NextJS has to offer:

- File-based Routing
- Built-in Page Pre-rendering
- Rich Data Fetching Capabilities
- Image Optimization
- Much More

## File-based Routing

![Create routes via your file + folder structure](nextjs-file-based-routing.png)



Getting Started with NextJS


JavaScript powers the web - it's **the** most important programming language you need to know as a web developer.

For example, you should understand code like this:

```js
const basics = 'Okay, that should not be too difficult actually';
function printBasics() {
  console.log(basics):
}
printBasics();
```



All Posts