DEV Community: Nishchya Verma

Designing a UI That AI Can Actually Understand (DOMGlyph Deep Dive)

Nishchya Verma — Fri, 03 Apr 2026 15:35:42 +0000

DOMGlyph (formerly llcortex/CortexUI) is an AI-native interface system that turns UI into a contract for intelligent agents. You can explore the source on GitHub and browse the docs and demos at domglyph.llcortex.ai.

If you want AI to operate a UI reliably, you have to stop making it guess.

That is the shortest possible explanation of DOMGlyph.

The longer explanation is more interesting.

Most web automation today works by inference. The system looks at the DOM, searches for a likely button, reads labels, tracks layout, maybe uses screenshots, and tries to decide what to do next. It works until the interface changes. Then the guessing starts to fall apart.

DOMGlyph fixes that by giving the UI its own explicit machine-readable layer.

Here is the simplest example:

<button
  data-ai-id="save-profile"
  data-ai-role="action"
  data-ai-action="save-profile"
  data-ai-state="idle"
>
  Save Profile
</button>

This looks almost trivial.

It is not.

Those four attributes turn a generic button into a deterministic action contract.

data-ai-id="save-profile" gives the element a stable identity.

This is how agents, tests, and runtime tools refer to the exact element across renders and redesigns.

data-ai-role="action" tells the system what kind of thing this is.

Not just “an element.” An action trigger.

data-ai-action="save-profile" declares intent.

This is the operation being performed, independent of the visible button label.

data-ai-state="idle" exposes the current machine state.

If it becomes loading, an agent knows to wait. If it becomes error, an agent knows the operation failed. If it becomes success, it knows the action completed.

That is the contract layer in miniature.

Once a page is annotated like this, DOMGlyph’s runtime can read those attributes and expose a structured API in the browser.

The basic idea looks like this:

window.__DOMGLYPH__.getAvailableActions()

And the result is not a raw element tree. It is a usable representation of what the UI can do right now.

Something like:

[
  {
    id: "save-profile",
    action: "save-profile",
    state: "idle",
    section: "profile-form"
  }
]

That changes the interaction model completely.

Instead of asking:
“Can I find a button that probably means save?”

An agent can ask:
“What actions are currently available?”
“Is save-profile one of them?”
“What state is it in?”
“What screen am I on?”
“What form fields are required before I trigger it?”

That is the difference between heuristic automation and deterministic automation.

A More Realistic Example

DOMGlyph gets more useful as soon as you move beyond a single button.

Imagine a profile editing flow.

You have:

a form with fields
a save action
a status banner
a table of related records
a confirmation dialog for destructive actions

A DOMGlyph-style screen can declare all of that.

A form might look like this:

<form data-ai-role="form" data-ai-id="edit-profile-form">
  <input
    data-ai-role="field"
    data-ai-id="profile-name"
    data-ai-field-type="text"
    data-ai-required="true"
  />

  <input
    data-ai-role="field"
    data-ai-id="profile-email"
    data-ai-field-type="email"
    data-ai-required="true"
  />

  <button
    data-ai-role="action"
    data-ai-id="save-profile"
    data-ai-action="save-profile"
    data-ai-state="idle"
  >
    Save Profile
  </button>
</form>

Now the runtime can return the form schema directly:

window.__DOMGLYPH__.getFormSchema("edit-profile-form")

Which means an agent can learn:

which fields exist
what type each field expects
which fields are required
what action submits the form

No label scraping. No input guessing. No hardcoded selectors.

That is especially important because forms are where AI often fails in production. A human can see that one field is for billing zip code and another is for email. An agent looking at generic markup often cannot do that reliably. DOMGlyph removes that ambiguity by encoding the schema directly into the interface.

Runtime: The Missing Bridge

The runtime is one of the most practical parts of the system.

DOMGlyph installs a browser API that acts like an inspection layer over the UI:

window.__DOMGLYPH__.getScreenContext()
window.__DOMGLYPH__.getAvailableActions()
window.__DOMGLYPH__.getFormSchema("edit-profile-form")
window.__DOMGLYPH__.getVisibleEntities()
window.__DOMGLYPH__.getRecentEvents()

That gives an agent a real operating loop.

Orient itself with getScreenContext()
Discover available operations with getAvailableActions()
Read form structure with getFormSchema()
Inspect visible business objects with getVisibleEntities()
Verify outcomes with getRecentEvents()

This matters because AI agents do not just need to act. They need to know whether acting worked.

A typical sequence might look like this:

agent sees it is on settings
finds save-profile
notices the button is idle
fills required fields from getFormSchema()
triggers the action
observes state move to loading
waits for an action_completed event
confirms success instead of assuming it

That is how you remove guesswork.

Demo Scenario: Form, Table, Dialog

A useful way to picture DOMGlyph is to imagine a realistic admin screen.

At the top is a user form.

In the middle is a table of related entities.

At the bottom is a destructive action that opens a confirm dialog.

In traditional UI automation, each of those pieces would require different heuristics. The form would be inferred from labels. The table rows would be identified by structure. The dialog would be detected visually. Success and failure would be inferred from DOM changes.

In DOMGlyph, all three pieces can expose the same kind of contract.

The table can declare entity type and row identity:

<table data-ai-role="table" data-ai-id="users-table">
  <tr data-ai-entity="user" data-ai-entity-id="user-42">
    ...
  </tr>
</table>

That means an agent can reason about the row as a real user, not just “the second row in a table.”

A confirm dialog can declare that it is a modal and that it is expanded:

<div
  data-ai-role="modal"
  data-ai-id="delete-user-dialog"
  data-ai-state="expanded"
>
  ...
</div>

That means the system knows it is in a confirmation state. It does not have to infer that from a darkened backdrop and a centered box.

Once you start seeing UI this way, the benefit compounds quickly. The same interface becomes understandable to developers, test suites, runtime tooling, and AI agents using the same contract vocabulary.

What the Developer Experience Looks Like

The practical developer story is straightforward.

You can install the packages:

pnpm add @domglyph/components @domglyph/runtime @domglyph/ai-contract

Use DOMGlyph components such as ActionButton, FormField, DataTable, StatusBanner, and ConfirmDialog.

Or, if you need lower-level control, use the primitives and add the contract manually.

The important shift is that state is no longer just visual. If a save operation is loading, your component should expose that in aiState. If a dialog is open, it should say so. If a field is required, the contract should say so. The UI becomes self-describing by design.

That ends up helping more than just AI.

Tests get more stable because they can target semantic identifiers instead of class names.

Debugging gets easier because the runtime can tell you what the page believes is currently true.

Automation gets less fragile because the meaning of the interface survives restyles and refactors.

And AI systems stop operating your app like a tourist reading street signs in a language they barely know.

Why This Is Powerful

The deepest value of DOMGlyph is not that it adds new components.

It changes the role of the interface.

Instead of being a surface that must be interpreted, the UI becomes a system that can declare itself.

That matters for AI today because the current alternative is a pile of heuristics.

But it matters even more in the long run because software is clearly moving toward a world where interfaces are used by multiple kinds of operators: humans, copilots, agents, tests, automations, and devtools.

Those operators need more than visuals.

They need a contract.

DOMGlyph treats that contract as a first-class part of interface design.

And once you see the browser that way, it becomes hard to go back.

To explore the system in detail, visit the DOMGlyph project on GitHub and the website at domglyph.llcortex.ai.

For a quick DEMO of DOMGlyph in ACTION click-here .

UI Is Not a View Layer. It’s an Interface Contract.

Nishchya Verma — Tue, 31 Mar 2026 17:04:11 +0000

DOMGlyph (formerly llcortex/CortexUI) is an AI-native interface system built on this exact idea: UI should be operable by humans visually and by intelligent agents programmatically. The project lives on GitHub, and the full docs are available at domglyph.llcortex.ai.

Frontend developers have spent years talking about UI as a view layer.

That framing is too small.

A serious interface is not just something that looks good and responds to clicks. It is the operational boundary between a system and whoever is trying to use it. For years, that “whoever” was assumed to be a human. Now it is increasingly a human and a machine.

Once you accept that, the way we talk about UI starts to feel outdated.

Backend engineers have been trained to think in contracts for decades. A good API is explicit. It names its endpoints. It declares its inputs. It specifies success and failure modes. It gives clients something stable to build against.

We treat API contracts as real architecture.

But on the frontend, we routinely ship interfaces where the semantics are implied rather than declared. A button has a label, not an identity. A form has fields, but no machine-readable schema. A loading state exists visually, but there is no explicit contract that says, “this action is in progress, do not trigger it again.”

Humans cope with this because humans are excellent at inference.

Machines are not.

That is the philosophical core of CortexUI: UI should be designed with the same contractual rigor we expect from APIs.

Not because we want to make frontend feel like backend.

Because modern software now has non-human operators.

The DOMGlyph worldview is built on a few strong ideas.

First: UI is an interface, not decoration.

The visual layer matters. A lot. Good typography, spacing, accessibility, hierarchy, and motion are part of how humans understand software. DOMGlyph does not reject any of that.

But visual design is only one half of the job.

The second half is semantic clarity. What is this element? What action does it trigger? What state is it in? What entity does it belong to? What section of the workflow am I looking at?

If those answers only exist in a human’s head, the UI is incomplete.

Second: interfaces should be deterministic.

An agent should not need to infer whether a button is a destructive action, a primary action, or a navigation affordance based on color and placement. It should not need to guess whether a spinner means “loading” or whether a quiet layout change means the action succeeded.

Determinism means the interface declares what is true right now.

A DOMGlyph element carries explicit identity and state:

data-ai-id for stable identity
data-ai-role for semantic type
data-ai-action for executable intent
data-ai-state for current condition
data-ai-screen and data-ai-section for context
data-ai-entity and data-ai-entity-id for domain anchoring

This is not metadata as decoration. It is metadata as architecture.

Third: actions should be first-class.

Traditional UI often treats actions as the byproduct of components. There is a button. The button has some text. Somewhere in code there is an onClick. The action is hidden inside implementation.

DOMGlyph flips that. The action becomes the thing you design around.

What is the action called? When is it available? What does success look like? What does failure look like? What state transitions can it go through? What entity does it operate on?

That is a better design discipline even before AI enters the picture.

Once you are forced to name an action explicitly, ambiguity gets harder to hide.

Fourth: interfaces should have a dual layer.

This is one of the most useful ways to think about CortexUI.

There is a human layer:
the visible UI, layout, style, interaction polish, accessibility affordances, responsive behavior.

And there is a machine layer:
the contract that exposes identity, meaning, state, and available operations to agents, tests, and runtime tooling.

These layers are not in conflict. They coexist.

A human still sees a clean form and a clear primary button. An agent sees a form schema, field types, required flags, and a stable action identifier.

Same interface. Two consumers. One contract.

That dual-layer model matters because the current alternative is terrible. Without an explicit machine layer, AI systems end up reading interfaces the same way a human with blurred vision might: making guesses from incomplete evidence. That produces brittle automation, unreliable copilots, fragile end-to-end tests, and endless maintenance every time a UI changes.

A contract layer changes that.

Stable identity means an action remains targetable even if the copy changes from “Save” to “Update profile.”

Observability means an agent can inspect current state instead of deducing it from pixels.

Explicit state means a system can know that an action is loading, a field is in error, or a modal is expanded without guessing.

This is why DOMGlyph is not just another component library.

A component library helps you render UI.

A contract system helps you make UI operable.

That distinction will matter more every year.

The future of software is not just people clicking around inside browsers. It is people, agents, automations, test runners, copilots, and monitoring systems all interacting with the same interfaces. The teams that win in that world will not be the ones with the prettiest buttons alone. They will be the ones whose interfaces are explicit, stable, observable, and trustworthy.

The frontend world spent years optimizing for how software looks.

The next frontier is optimizing for how software declares itself.

That is the deeper idea behind DOMGlyph.

Not prettier components.

Interfaces that can be understood.

If that model resonates, explore DOMGlyph on GitHub and read more at domglyph.llcortex.ai.

The Web Was Built for Humans. AI Is Struggling Because of It.

Nishchya Verma — Tue, 31 Mar 2026 17:01:43 +0000

AI is getting better at reasoning.

It is still surprisingly bad at using software.

That gap is not because the models are weak. It is because the web was never designed to be legible to machines in the first place.

Most modern interfaces are optimized for human perception. We use typography, spacing, button placement, color, and copy to communicate meaning. A person can glance at a checkout screen and understand where they are, what fields matter, what the primary action is, and what will probably happen next.

An AI agent does not get that for free.

When an agent lands on a page, it usually has to reverse-engineer the interface from unstable clues. It scrapes the DOM. It follows brittle selectors. It guesses that the button labeled “Save” is probably the one it wants. It hopes the gray button is disabled and not just styled that way. It infers structure from wrappers, classes, and visible text that product teams change every week.

That is not intelligence. That is survival.

And it breaks constantly.

A small redesign can move one button, rename one label, or insert one extra wrapper div and suddenly the entire automation flow starts failing. A CSS selector that worked yesterday stops working today. A form field the agent identified by label text is now ambiguous. A modal opens with no explicit contract that says, “you are in a confirmation step now.”

This is why so much AI-powered UI automation feels flaky in production. The model is being asked to operate an interface that only humans were ever meant to understand.

That is the real problem.

We act like the browser is a universal interface. It is not. It is a universal visual interface.

For humans.

If AI is going to become a real operator of software, there is a missing layer we need to add between the rendered UI and the agent trying to use it. Not another prompt. Not better XPath. Not smarter screenshot parsing.

A contract.

That is the idea behind DOMGlyph (formerly llcortex/CortexUI).

DOMGlyph starts from a simple but important premise: a modern interface has two audiences now. The first is the human using it visually. The second is the machine trying to interact with it programmatically.

Most design systems only serve the first audience.

DOMGlyph is built for both.

A DOMGlyph component does not just render a button, a field, or a table. It also emits a machine-readable contract alongside the visual layer. Identity, role, action, state, screen context, section context, entity context. The UI stops being a pile of elements and starts being self-describing.

A button stops being “something blue near the bottom of the form.”

It becomes this:

<button
  data-ai-id="save-profile"
  data-ai-role="action"
  data-ai-action="save-profile"
  data-ai-state="idle"
>
  Save Profile
</button>

That difference is bigger than it looks.

Now an agent does not need to guess. It can ask: what actions are available right now? Which one is save-profile? Is it idle, loading, disabled, or finished? Which screen am I on? What entity is this form editing?

In DOMGlyph, the interface can answer those questions directly.

That changes the architecture of AI interaction completely. Instead of DOM scraping and heuristics, you get deterministic access to the meaning of the page. The UI becomes less like a screenshot the model has to interpret and more like an API the model can query.

That is the shift.

Not “AI in the UI.”

UI built so AI can actually use it.

The web was built for humans. That was the right decision for the last era.

But the next era includes operators without eyes.

If we keep building interfaces that only humans can truly understand, AI will remain trapped in a layer of brittle guesswork.

If we build interfaces that declare what they mean, what they do, and what state they are in, something more interesting happens.

The UI stops being a visual artifact.

It becomes a contract.

And that is where DOMGlyph begins.

If you want to dig deeper, explore DOMGlyph on GitHub or read the docs at domglyph.llcortex.ai.

System Design - Twitter X

Nishchya Verma — Wed, 25 Jun 2025 15:03:13 +0000

Ever wondered how social platforms like Twitter manage millions of tweets, likes, and comments in real time? I did too—so I decided to design one from scratch. In this post, I’ll take you through the architecture, APIs, and decisions involved in creating a scalable microservices-based Twitter clone.

Functional Requirements:

Create an account and login,
Create edit delete tweets
Follow other users
View a timeline of tweets for following
Like or reply to tweets
Search for tweets

Non functional Requirements:

availability - system should be available
scalability - should be able to handle users as users, tweets created, etc increases
durability - Tweets created should not be lost

Core Entities:

User : {user_id. user_name, user_metadata, password}
Tweet: {tweet_id, user_id. content, created_at, edited_at, edited, orignal_content}
Comment: {tweet_id, comment_content, user_id, timestamp}
Followers: {user_id, following_user_id}
Likes: {tweet_id, user_id}

APIs:

SignIn/SignUP

- [GET] /auth/username-availability?username=<value>    -check if user already exist
- [POST] /auth/user/signup {user_name, user_metatData, user_credetials, email}
- [POST] /auth/login {user_name, email, credentails} 
- [POST] /auth/verify-otp {user_name, otp}

Tweets

- [GET] /tweets?sort=latest ----Return top recent tweets
- [GET] /tweets/following?sort=latest&page=1&limit=10 ----Return top recent tweets by following
- [GET] /users/{user_id}/tweets?page=1&limit=10 ---- Return all recent tweets by user [support pagination] if some users userid
 passed it return for that user otherwise for the user himself. 
- [POST] /tweets/search {keywords []}
- [GET] /tweets/{tweet_id} – fetch tweet by ID
- [DELETE] /tweets/{tweet_id} – for user delete

Comments/Likes

-[POST] /tweets/{tweet_id}/comments {user_id, content, tweet_id}
-[GET] /tweets/{tweet_id}/comments
-[GET] /tweets/{tweet_id}/likes
-[POST] /tweets/{tweet_id}/likes
-[DELETE] /tweets/{tweet_id}/likes

Search

- [POST] /search/tweets { keywords: [], tags: [] }
- [GET] /tags/trending – trending topics

Follow

[POST] /users/{user_id}/follow
[DELETE] /users/{user_id}/follow
[GET] /users/{user_id}/followers
[GET] /users/{user_id}/following

DIAGRAM:

Suggestions for Further Enhancement

1. Timeline Service: Push vs Pull Strategy

Push Model (Fan-out-on-write): Pre-generate user timelines when someone posts a tweet.
Pull Model: Fetch tweets in real-time from users a person follows. You can start with Pull (easier), and switch to Push for high-scale active users (e.g., celebrities).

2. Likes & Comments as Microservices
Not required now, but eventually split LikesService, CommentService to handle independent scaling.
Add rate limiting on likes/comments to avoid spam or abuse.

3. Notifications Service (Future)
For follows, likes, replies.
Async (Kafka-based) + push (WebSocket or polling)

4. Moderation / Flagging
Add a moderation flag or queue to enable content reporting.
Optional ML service for spam/inappropriate content.

5 Must-Know Design Patterns Every Developer Should Master

Nishchya Verma — Tue, 24 Jun 2025 15:50:59 +0000

At some point in our careers we’ve all been tangled in if-else nests and duct-taped functions just trying to make things work. But what if I told you there’s a better way? A way used by seasoned developers to write cleaner, smarter, and more maintainable code?

We’ve all heard the term “design patterns” thrown around — usually by that one senior dev who speaks fluent Lorem ipsum.
Maybe you’ve even noticed how certain built-in functions or framework methods just make sense — like they were crafted with some secret blueprint. Well, spoiler alert: they were. That blueprint is what we call a design pattern — a time-tested solution to a common software design problem. In this article, I'll break down the Top 5 Design Patterns you’ve probably seen in the wild (even if you didn’t know their names), and show you how to use them like a pro.

1. Strategy Pattern

Intent: Define a family of algorithms, encapsulate each one, and make them interchangeable.

Use When:

You have multiple ways of doing something (e.g., sorting, payment, compression).
You want to switch algorithms at runtime.

Structure:

Strategy Interface
Concrete Strategies
Context (uses Strategy)

Sample Code

// Strategy
interface PaymentStrategy {
    void pay(int amount);
}

// Concrete Strategy
class CreditCardPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " using credit card");
    }
}

class PayPalPayment implements PaymentStrategy {
    public void pay(int amount) {
        System.out.println("Paid " + amount + " using PayPal");
    }
}

// Context
class ShoppingCart {
    private PaymentStrategy strategy;

    public void setPaymentStrategy(PaymentStrategy strategy) {
        this.strategy = strategy;
    }

    public void checkout(int amount) {
        strategy.pay(amount);
    }
}

2. Observer Pattern

Intent: Define a one-to-many dependency so when one object (subject) changes state, all its dependents (observers) are notified.

Use When:

An object changes state and others need to know.
For event-driven systems (e.g., UI, stock price updates).

Structure:

Subject
Observer Interface
Concrete Observers

Sample Code

interface Observer {
    void update(String message);
}

class EmailSubscriber implements Observer {
    public void update(String message) {
        System.out.println("Email received: " + message);
    }
}

class Publisher {
    private List<Observer> observers = new ArrayList<>();

    public void subscribe(Observer obs) {
        observers.add(obs);
    }

    public void notifyObservers(String message) {
        for (Observer obs : observers) {
            obs.update(message);
        }
    }
}

3. Decorator Pattern

Intent: Attach additional responsibilities to an object dynamically. It’s like wrapping an object with extra behavior.

Use When:

You want to add features without changing the base class.
Avoid subclass explosion.

Structure:

Component Interface
Concrete Component
Decorator (implements component and wraps another)

Sample Code

interface Coffee {
    String getDescription();
    int cost();
}

class BasicCoffee implements Coffee {
    public String getDescription() { return "Basic Coffee"; }
    public int cost() { return 50; }
}

class MilkDecorator implements Coffee {
    private Coffee coffee;
    public MilkDecorator(Coffee coffee) { this.coffee = coffee; }

    public String getDescription() {
        return coffee.getDescription() + ", Milk";
    }
    public int cost() {
        return coffee.cost() + 10;
    }
}

4. Factory Pattern

Intent: Create objects without exposing the instantiation logic to the client. Use a method to create the object.

Use When:

You want to delegate object creation to a separate method/class.
Need to avoid tight coupling.

Structure:

Interface or Superclass
Factory method to create instances

Sample Code

interface Animal {
    void speak();
}

class Dog implements Animal {
    public void speak() {
        System.out.println("Woof!");
    }
}

class AnimalFactory {
    public static Animal getAnimal(String type) {
        if (type.equals("dog")) return new Dog();
        throw new IllegalArgumentException("Unknown type");
    }
}

5. Singleton Pattern

Intent: Ensure a class has only one instance and provide a global access point to it.

Use When:

You need only one instance (e.g., DB connection, config).
To coordinate actions across the system.

Structure:

Private constructor
Static instance variable
Public static getter method

Sample Code

class ConfigManager {
    private static ConfigManager instance;

    private ConfigManager() {}

    public static ConfigManager getInstance() {
        if (instance == null) {
            instance = new ConfigManager();
        }
        return instance;
    }
}

Thread Safe Version:

public class ThreadSafeSingleton {
    private static final ThreadSafeSingleton instance = new ThreadSafeSingleton();

    private ThreadSafeSingleton() {}

    public static ThreadSafeSingleton getInstance() {
        return instance;
    }
}

Here’s a quick table to help you map the purpose of each pattern to its core concept.

Pattern	Purpose	Key Concept
Strategy	Swap behavior like changing themes	Algorithms packed neatly in separate boxes
Observer	Alert everyone when something changes	One-to-many notification chain
Decorator	Add features without changing the original object	Wrap it, stack it, reuse it
Factory	Don’t `new` up stuff everywhere	One method to create them all
Singleton	Only one allowed in the club	One instance, globally accessed

So whether you’re building a game, an API, or the next unicorn startup from your garage, these patterns will save you time, headaches, and therapy bills.

Backtracking : Master it like a pro

Nishchya Verma — Tue, 10 Jun 2025 06:02:42 +0000

Core Idea:

"I do, I fail, I go back and try something else." - Nishchya Verma

Let's break it down:
"I do"
→ You make a choice or decision (e.g. placing a queen on a chessboard, choosing a number in Sudoku, picking a path in a maze).

"I fail"
→ You reach an invalid state — maybe a constraint is violated or no further progress is possible.

"I go back"
→ You undo the last decision — this is the "backtrack" part.

"Try something else"
→ Explore a different path by making another valid choice and continuing.

Backtracking = Try > Fail > Undo > Try Something Else

Think of it like a smart brute force approach where you:

Choose - Pick an option from a set.
Explore - Go deeper with that option.
Unchoose (Backtrack) - If it doesn’t lead to a solution, undo and try the next.

It’s used when:

You need all possible combinations/permutations/subsets.
You make decisions step by step, and some decisions may lead to dead ends.

How To Recognize a Backtracking Problem:

"Find all..."
"Count the number of ways..."
"Return possible arrangements..."
You’re asked to explore all combinations, permutations, paths, or valid configurations.
Constraints must be obeyed (e.g. Sudoku, N-Queens).

Template

function backtrack(path, options) {
    if (isGoal(path)) {
        result.push([...path]); // or return true if only one solution is needed
        return;
    }

    for (let option of options) {
        if (isValid(option, path)) {
            path.push(option);             // Choose
            backtrack(path, updatedOptions); // Explore
            path.pop();                   // Unchoose (Backtrack)
        }
    }
}

Let’s Learn by Examples

Let’s dive into two famous problems where backtracking is not just helpful — it’s essential for solving them.

We’ll start with an easier problem to build confidence, then move on to a slightly more challenging one.

1. Permutations [Leetcode #43]

Given an array nums of distinct integers, return all the possible . You can return the answer in any order.

Example 1:
Input: nums = [1,2,3] Output: [[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]

Example 2:
Input: nums = [0,1] Output: [[0,1],[1,0]]

Example 3:
Input: nums = [1] Output: [[1]]

Constraints:

1 <= nums.length <= 6
-10 <= nums[i] <= 10
All the integers of nums are unique.

Lets try to address it,

What are we doing here?
You're trying every possible arrangement of the numbers.
This is a backtracking problem:

    "Try, fail, go back, try something else."

Lets understand it visually for example
Input: nums = [1,2,3]
Output: [[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]

Each level:

Chooses a number not already used
Adds it to the current path
Backtracks when needed (removes the last added number)

Lets write the backtrack code for above actions
Python

def permute(nums):
    result = []

    def backtrack(path):
        if len(path) == len(nums):       # base case: full permutation
            result.append(path[:])       # make a copy of path
            return

        for num in nums:
            if num in path:              # skip already used numbers
                continue
            path.append(num)             # make a choice
            backtrack(path)              # explore
            path.pop()                   # undo choice (backtrack)

    backtrack([])
    return result

Java

class Solution {
    List<List<Integer>> permutations = new ArrayList<>();
    int[] used;
    private void backtrack(int[] nums, ArrayList<Integer> temp) {
        if(temp.size() == nums.length) {
            permutations.add(new ArrayList<>(temp));
            return;
        }
        for(int i=0;i<nums.length;i++) {
            if(used[i] != 1) {
                temp.add(nums[i]);
                used[i] = 1;
                backtrack(nums, temp);
                used[i] = 0;
                temp.remove(temp.size()-1);
            }  
        }
    }
    public List<List<Integer>> permute(int[] nums) {
        used = new int[nums.length];
        backtrack(nums, new ArrayList<Integer>());
        return permutations;
    }
}

Lets understand what is happening

Start: []
Choose 1 → [1]
- Choose 2 → [1, 2]
  - Choose 3 → [1, 2, 3] ✅
  - Backtrack → [1, 2]
- Backtrack → [1]
- Choose 3 → [1, 3]
  - Choose 2 → [1, 3, 2] ✅
  - Backtrack → [1, 3]
- Backtrack → [1]
Backtrack → []
Choose 2 → [2]
- Choose 1 → [2, 1]
  - Choose 3 → [2, 1, 3] ✅
  - Backtrack → [2, 1]
- Backtrack → [2]
- Choose 3 → [2, 3]
  - Choose 1 → [2, 3, 1] ✅
  - Backtrack → [2, 3]
- Backtrack → [2]
Backtrack → []
Choose 3 → [3]
- Choose 1 → [3, 1]
  - Choose 2 → [3, 1, 2] ✅
  - Backtrack → [3, 1]
- Backtrack → [3]
- Choose 2 → [3, 2]
  - Choose 1 → [3, 2, 1] ✅
  - Backtrack → [3, 2]
- Backtrack → [3]

Output: [[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]

Lets take another example, a little complex this time.

2. Combinations [Leetcode #77]

Given two integers n and k, return all possible combinations of k numbers chosen from the range [1, n].

You may return the answer in any order.

Example 1:
Input: n = 4, k = 2 Output: [[1,2],[1,3],[1,4],[2,3],[2,4],[3,4]]

Example 2:
Input: n = 1, k = 1 Output: [[1]]

Constraints:

1 <= n <= 20
1 <= k <= n

Note - This is combinatorics, not permutations → Order doesn’t matter.
So [1, 2] and [2, 1] are same combination (we only want one of them).

Lets understand it visually for example
Input: n = 4, k = 2
Output: [[1,2],[1,3],[1,4],[2,3],[2,4],[3,4]]

We start with an empty list, and at each level:

Pick the next number from start to n
Recurse deeper with one more number in the path
Stop when path size reaches k

Lets write the backtrack code for above actions
Python

def combine(n, k):
    result = []

    def backtrack(start, path):
        if len(path) == k:           # base case
            result.append(path[:])
            return

        for i in range(start, n + 1):
            path.append(i)           # make a choice
            backtrack(i + 1, path)   # explore next numbers
            path.pop()               # undo choice (backtrack)

    backtrack(1, [])
    return result

Java

class Solution {
    List<List<Integer>> solution;
    int size;
    private void backtrack(int n, int k, List<Integer> subset) {
        if(subset.size() == k) {
            solution.add(new ArrayList<>(subset));
            return;
        }
        for(int i = n;i<=size;i++) {
            subset.add(i);
            backtrack(i+1, k, subset);
            subset.remove(subset.size()-1);
        }

    }
    public List<List<Integer>> combine(int n, int k) {
        solution = new ArrayList<>();
        size = n;
        backtrack(1,k, new ArrayList<Integer>());
        return solution;
    }
}

Lets understand what is happening
Here, n=4 and k=2

[] → [1] → [1,2] ✅
Backtrack → [1] → [1,3] ✅
Backtrack → [1,4] ✅
Backtrack to [] → Try [2] → [2,3] ✅, [2,4] ✅
Try [3] → [3,4] ✅

Total: 6 combinations

I’ll be sharing two carefully chosen problems to help you master this concept.
Once you've solved them, share your experience and solutions in the comments — let’s learn together!

Practice Questions

1. Generate Parentheses [Leetcode #22]

2. N-Queens [Leetcode #51]

Blockchain - Simply Explained

Nishchya Verma — Wed, 04 Jan 2023 11:48:48 +0000

Intro

A blockchain is a digital record of transactions. Each transaction is recorded on a block, and multiple blocks are linked together to form a chain. This chain is distributed, meaning that copies of it are stored on multiple computers (also known as "nodes") around the world.

Features

One of the main features of a blockchain is that it is decentralized, meaning that it is not controlled by a single entity such as a bank or government. Instead, the network of computers that make up the blockchain is responsible for verifying and recording transactions. This makes it difficult for any one person or group to manipulate the record of transactions.

Another important feature of a blockchain is that it is transparent and secure. All transactions are recorded on the chain and can be viewed by anyone, but they are also encrypted, making it difficult for anyone to alter or tamper with the record of transactions.

Blockchain behind the scenes

A blockchain is a decentralized, distributed database that stores a growing list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp, and transaction data. By design, a blockchain is resistant to modification of the data.

Here's an example of how a blockchain works:

Imagine that Alice wants to send Bob some money over the internet. Alice initiates the transaction by sending a message to the network indicating that she wants to transfer a certain amount of money to Bob. This message, called a transaction, is broadcast to all the nodes in the network.

The nodes, or computers, in the network verify the transaction by checking that Alice has the necessary funds and that she has not already sent the money to someone else. Once the transaction is verified, it is added to a block, along with other transactions that have been verified around the same time.

The block is then cryptographically hashed, and the hash is added to the previous block in the chain, forming a chain of blocks, hence the name "blockchain." This chain of blocks is then distributed to all the nodes in the network.

The transaction is now complete and the money has been transferred from Alice to Bob. Because the transaction is recorded on multiple blocks in the chain and the chain is distributed across the network, it is very difficult to alter the transaction retroactively without the consensus of the network. This makes a blockchain an secure and transparent way to record transactions.

Conclusion

Overall, a blockchain is a way of securely and transparently recording transactions digitally, without the need for a central authority.

Kubernetes/: Introduction

Nishchya Verma — Fri, 28 Oct 2022 18:31:55 +0000

👀 What is Kubernetes?

Kubernetes or K8s is container orchestration system on "steroids". It takes care of automatic deployment of containerized applications across different servers.
It scale the system up and down automatically and also takes care of the distribution of load across multiple servers automatically. It will also take care of monitor and perform health checks of containers, replacing the failed ones.
It also provide many more features that you'll be learning throughout the course.

📝 Important Terminology

Lets cover some of the important terms and concepts that you'll be listening throughout the course.

- Cluster:

A Kubernetes cluster (or cluster) is a grouping of nodes that run containerized applications in an efficient, automated, efficient and scalable manner.
It consists of master nodes(or control plane) and worker nodes. Every cluster has at least one worker node. Worker nodes are the nodes where your containerized application is running. The control plane manages the worker nodes and the Pods in the cluster. The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a deployment's replicas field is unsatisfied).

- Pod:

Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers, such as Docker containers. When a Pod runs multiple containers, the containers are managed as a single entity and share the Pod's resources.
Pods also contain shared networking and storage resources for their containers.

- Control Plane:

Control plane is responsible for making the decisions about the cluster as well as detecting and responding to the events that occur within a cluster. Control plane components can run on any machine in the cluster however for simplicity they are usually on same machine. These components are kube-apiserver, etcd, kube-schedular, kube-controller-manager, cloud-controller-manager.

- Node:

A Node is a worker machine in kubernetes and maybe a virtual machine or physical machine, depending on the cluster. Each node is managed by the control plane. A node can hold multiple pods and control plane automatically handles the scheduling pods across the Nodes in the cluster.

⚙ Kubernetes Cluster Components

When you deploy Kubernetes, you get a cluster.

Lets discuss each component in details,

Control Plane components:

kube-apiserver The apiserver is the front-end to the K8s control plane that exposes the Kubernetes API. The Kubernetes API server validates and configures data for the api objects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster's shared state through which all other components interact.
etcd
It is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
More info on etcd etcd.io docs
kube-scheduler
kube-scheduler is the default scheduler for Kubernetes and runs as part of the control plane. kube-scheduler is designed so that, if you want and need to, you can write your own scheduling component and use that instead.
The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. The scheduler determines which Nodes are valid placements for each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. A scheduler watches for newly created Pods that have no Node assigned. For every Pod that the scheduler discovers, the scheduler becomes responsible for finding the best Node for that Pod to run on.
kube-controller-manager
The Kubernetes controller manager is a program that runs continuously as a background process and wakes up to handle periodic service requests, which often come from remote processes. It embeds the core control loops shipped with Kubernetes. In applications of robotics and automation, a control loop is a non-terminating loop that regulates the state of the system. In Kubernetes, a controller is a control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state.
cloud-controller-manager
Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds. Kubernetes believes in automated, API-driven infrastructure without tight coupling between components.
The cloud-controller-manager is a Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

Node components:

Every node in the cluster have dedicated node components running on them.

kubelet An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.
kube-proxy kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster. This reflects services as defined in the Kubernetes API on each node and can do simple TCP, UDP, and SCTP stream forwarding or round robin TCP, UDP, and SCTP forwarding across a set of backends.
container runtime The container runtime, also known as container engine, is the software that is responsible for running containers. You need to install a container runtime into each node in the cluster so that Pods can run there. Container runtime is responsible for loading container images from a repository, monitoring local system resources, isolating system resources for use of a container, and managing container lifecycle.

Upcoming Articles ✍🏻

Kubernetes/: Onboarding 

Kubernetes/: Scaling 

Kubernetes/: Dockerizing

Lets connect

Icons created by riajulislam

Creational Patterns : Factory Method

Nishchya Verma — Wed, 06 Oct 2021 08:14:31 +0000

Creational Patterns

Factory Method

Factory pattern encapsulates object creation letting the subclasses decide what object to create. It is the most used design pattern.

A framework needs to standardize the architectural model for a range of applications but allow for individual applications to define their own domain objects and provide for their instantiation. In simple words, In Factory Method a superclass specifies all standard and generic behavior, and then delegates the creation details to subclasses that are supplied by the client. This superclass is called a Factory. Factories handle the details of object creation. This way it makes the design more customizable.

Why do we need Factory Method?

The Factory Method defines an interface for creating objects, but let’s subclasses decide which classes to instantiate.

When we use new operator, we are instantiating a concrete class. There is a difference between requesting an object and creating one. The new operator always creates an object and fails to encapsulate object creation. A Factory Method enforces that encapsulation and allows an object to be requested without inextricable coupling to the act of creation.

Lets consider an example,

Pizza pizzaOrder;

if(margerita){
  pizzaOrder = new Margerita();
}
else if(country){
  pizzaOrder = new CountryFeast();
}
else if(corn){
 pizzaOrder = new CornCheese();
}

In above example Pizza is an interface that helps us keep code flexible. However, we must create an instance of a concrete class. And since we have a bunch of different Pizza classes, and we do not know until runtime which one we need to instantiate.

Now this is possible that above code snippet may exist in your code base at several locations in multiple classes, and when you are required to add or remove a type of Pizza Class it will make code update more difficult, time consuming and prone to errors.

To solve this issue, we use Factory Method pattern.

Lets explore Factory Method Pattern.

Note- The examples discussed will be in Java.
Suppose the client code needs a new product(object). Now client have two options, first is that it can use new operator to create the Product. However when implementing Factory Pattern our client code will instead ask the factory object for a new Product by providing it the information regarding the type of product it need.

Once the factory object will receive the necessary information regarding the Product type needed, factory will instantiate the new concrete Product and then return to the client the newly created Product(casted to abstract Product class). The client will use the products as abstract products without being aware about their concrete implementation.

Let's consider the following example for better understanding,
A coffee-outlet pos application works with different types of Coffee. Here the Menu Class is the client and different types of coffee in the menu are the Products. All coffee products like (Espresso, Latte, Mocha) are derived from an abstract Coffee class(or interface). The Coffee class(or interface) defined the withSugar and withMilk methods which must be implemented by all the 3 Product classes. Now suppose a Latte Coffee is selected from the Menu. the code recieves the type of coffee, ie. Latte as a String paramenter and it asks our Factory Object to create a new concrete Object ie. Latte. The factory creates a new Latte and returns it to the calling object casted to an abstract Coffee class. Then the code uses the object as casted to the abstract class without being aware of the concrete object type.

The core advantage of implementing Factory Pattern is that new coffee products can be added without changing a single line of code in the framework(the client code that uses the coffee from the factory).

Implementation

Lets discuss certain factory implementations that allow adding new products without even modifying the factory class.

Suppose you own a Logistic Business. You provide logistics solutions via trucks. In your application the bulk of your code lives inside the Truck class. Now you also want to manage logistics via Ships.

Since most of your code is coupled to the Truck class. Adding Ships into the app would require making changes to the entire codebase. Same apply if in future you want to add Airplane.

Your app’s will be filled with conditional statements that will switch the behavior of the application depending on the class of transportation objects (Ships, Trucks, etc).

Lets solve above issue by implementing Factory Method Pattern. Factory method suggest that you replace direct object construction calls (using the new operator) with calls to a special factory method. Now the objects are still created via the new operator, but it’s being called from within the factory method inside the factory object. Objects returned by a factory method are often referred to as products.

First we declare a Transport interface. This is the Product interface that we discussed earlier.

public interface Transport {
    public String deliverBy();
}

Now we will declare two concrete products ie, Ship and Truck which implements Transport interface.

public class Ship implements Transport {
    public String deliverBy(){
        return "Ship deliver logistics by Sea";
    }
}

public class Truck implements Transport{
    public String deliverBy(){
        return "Truck deliver logistics by Road.";
    }
}

Now once we have our concrete product classes and product interface now its time to setup our Factory in this example referred as Logistics.

public abstract class Logistics{
    public Transport createTransport(String type){

    }
    abstract Transport create(String type);
}

public class LandLogistics extends Logistics{
    public Transport create(String type){
        return new Truck();
    }
    public void deliveryBy(){
        System.out.println("Delivery by Road!");
    }
}

public class SeaLogistics extends Logistics{
    public Transport create(String type){
        return new Ship();
    }
    public void deliveryBy(){
        System.out.println("Delivery by Sea!");
    }
}

Once we have our abstract factory class (Logistics) along with the two concrete factory classes (SeaLogistics and LandLogistics) we can use the above in our calling code as,

...
    Logistics log=null;
    if(input=="Sea"){
        log = new SeaLogistics();
    }
    else if(input=="Land"){
        log = new LandLogistics();
    }
    Transport transport = log.create();
    transport.deliveryBy();
...

We will be discussing about other Creational patterns in the upcoming posts. Next will be Abstract Factory Pattern.

Stay tuned!

Note - Be part of the discussion and also leave a heart if you found it helpful.

Creational Patterns : Singleton

Nishchya Verma — Mon, 04 Oct 2021 13:46:29 +0000

Creational Patterns

Singleton Pattern

"One of a kind!!"

Singleton pattern is used when we want to create one-of-a-kind objects for which there is only one instance.

Often there are many objects which we just want at most one instance, for eg. Services, Objects that act as drivers or device drivers etc. And if more than one instance of these objects exist we might end up with more problems or weird program behavior.

Why do we need Singleton?

Now I know most of you will be thinking about Global objects, Right?

Well lets discuss why not use global. Suppose you use a global object instead. This global object will be instantiated at the start of your program. Now what if your application never ends up using it? What if we want our object (one of a kind) to be created only when its needed.

Interesting right?
So to conclude why not use global object, we want one-of-a-kind object to be instantiated only when its needed.

Lets get back to Singleton.

Note- The examples discussed will be in Java.

Generally, we create an object using new keyword in Java like new NotSingleton();. However another classes can also create new instances on NotSingleton class.

So how do we implement Singleton pattern?
Lets consider below example which demonstrate Singleton Pattern in action.

public class Singleton() {
  private static Singleton singletonInstance;
  //other variables here

  private Singleton() {}

  public static Singleton getInstance(){
    if(singletonInstance==null) {
      singletonInstance =  new Singleton();
    }
    return singletonInstance;
  }
  //other useful methods here
}

Now lets talk about the above example in details.
Firstly, we have declared a variable singletonInstance of class Singleton type. This static variable will hold one single instance of our Singleton.class.

Secondly, as you may have already noticed the constructor is declared private. Now you might ask well then how are we suppose to create an instance of Singleton class. Well if we think about it we only want Singleton class to be able to create an instance of itself. Since the constructor is private it cannot be accessed from outside the class however we still can access it from the inside.

Now the last part in above example is the answer to the question If Constructor is private how can we create an instance of Singleton class?. Method getInstance() return the only Singleton object ever created inside the Singleton class. If its not already created, it first create an instance, assign it to singletonInstance variable and then return our singletonInstance . And since method Singleton.getInstance() is static, it can be accessed from other parts of our code to get this unique instance of Singleton Class. Also since no public constructor exist we cannot create another instance of Singleton class anywhere else.

Mission: create one-of-a-kind objects: Done!.

Lets summarize what we have learn so far about Singleton. *Singleton pattern ensures that a class has only one instance, and provide a global point of access to it. In other words Singleton pattern is used when we want our object to be unique such that it only have one instance when needed and that unique instance is used throughout our code when required. To achieve this we declare the constructor of such class as private to prevent anyone from making new instance of our Class (ie. new object of same class). So we cannot instantiate a Singleton object we can just ask for its instance. We do that using the *getInstance() method, our global access point.
So if I put it in more simple words, we are taking a class and letting it manage a single instance of itself. We are also preventing any other class from creating a new instance on its own. And to get an instance, you have got to go through the class itself.

Note - I've demonstrated a classic example of singleton class, however if you'll further explore this topic (that I hope you will) you will find that above mentioned example will resemble the actual use case most of the times however when dealing with multithreading we might need to make some changes however the concept will remain the same.

That's all Folks!
Remember,

We will be discussing about other Creational patterns in the upcoming posts. Next will be Factory Pattern.

Stay tuned!

Note - Be part of the discussion and also leave a heart if you found it helpful.

Design Patterns : Creational Patterns

Nishchya Verma — Mon, 04 Oct 2021 11:15:07 +0000

Creational Patterns

"Provide object creation mechanism"

Creational Design Patterns are concerned with the way in which objects are created.

Why do we need Creational Patterns?

Creational Design Patterns address this issue by decoupling the client entirely from the actual initialization process.
Difficult to understand right?

In simpler terms, sometimes its important to be flexible with the nature of your object. When its required that the nature of the object must be changed according to the nature of the program. In such cases, creational design patterns come in handy to provide more general and flexible approach to object creation.
In other words, the general way of object creation could result in design problems or added complexity to the design and to prevent this we use Creational Design Patterns.

When to use Creational design Patterns?

Well if your aim resonates with any of the below scenario,

You want at most only one instance of an object available throughout the application. eg. Service classes should be stateless, and hence they don't need more than one instance.
If you want to create objects of several related different classes and you do not want to specify which object is created and also you do not want to coupled your code to use one class so that if later you introduce another class, this would require to make change in the entire codebase.

More such scenarios exist however the intake should be that if you want your code less coupled in terms on initialization and reduce complexities and instability by creating objects in a controlled manner, maybe creational pattern can come to the rescue.

What are the different Creational design Patterns?

We will be discussing about 5 of the commonly used Creational design Patterns namely,

Singleton Pattern
Factory Pattern
Abstract Factory Pattern
Builder Pattern
Prototype Pattern

We will be discussing about above mentioned patterns in the upcoming posts starting with Singleton Pattern.

Stay tuned!

Note - Be part of the discussion and also leave a heart if you found it helpful.

DEV Community: Nishchya Verma

Designing a UI That AI Can Actually Understand (DOMGlyph Deep Dive)

A More Realistic Example

Runtime: The Missing Bridge

Demo Scenario: Form, Table, Dialog

What the Developer Experience Looks Like

Why This Is Powerful

UI Is Not a View Layer. It’s an Interface Contract.

The Web Was Built for Humans. AI Is Struggling Because of It.

Top 20 Spring-boot questions for interview

Core Spring Boot & Configuration

REST API Design & Best Practices

Spring Boot + Data Layer

Security and Authentication

Spring Boot Advanced Concepts

Spring Boot + Messaging/Kafka

Testing & Observability

DevOps and Deployment Readiness

System Design - Twitter X

Functional Requirements:

Non functional Requirements:

Core Entities:

APIs:

DIAGRAM:

Suggestions for Further Enhancement

5 Must-Know Design Patterns Every Developer Should Master

1. Strategy Pattern

2. Observer Pattern

3. Decorator Pattern

4. Factory Pattern

5. Singleton Pattern

Backtracking : Master it like a pro

Core Idea:

How To Recognize a Backtracking Problem:

Template

Let’s Learn by Examples

1. Permutations [Leetcode #43]

2. Combinations [Leetcode #77]

Practice Questions

1. Generate Parentheses [Leetcode #22]

2. N-Queens [Leetcode #51]

Blockchain - Simply Explained

Intro

Features

Blockchain behind the scenes

Conclusion

Kubernetes/: Introduction

👀 What is Kubernetes?

📝 Important Terminology

- Cluster:

- Pod:

- Control Plane:

- Node:

⚙ Kubernetes Cluster Components

Control Plane components:

Node components:

Upcoming Articles ✍🏻

Lets connect

Creational Patterns : Factory Method

Creational Patterns

Factory Method

Why do we need Factory Method?

Lets explore Factory Method Pattern.

Implementation

Creational Patterns : Singleton

Creational Patterns

Singleton Pattern

Why do we need Singleton?

Lets get back to Singleton.

Design Patterns : Creational Patterns

Creational Patterns

Why do we need Creational Patterns?

When to use Creational design Patterns?

What are the different Creational design Patterns?