The world is buzzing with AI, but are we truly understanding it?

In this article, we break down generative AI and how it is different from traditional AI, models, and the mindset needed to thrive in this era of rapid transformation.

Let’s break it down:

Traditional AI vs Generative AI

1. Purpose

• Traditional AI: Designed to analyze data, recognize patterns, and make predictions or classifications.

• Generative AI: Designed to create new content like text, images, audio, or even code.

2. Input & Output

• Traditional AI: Takes structured data → gives answers, labels, or scores.

• Generative AI: Takes prompts (text, image, etc.) → generates original outputs like a paragraph, image, or video.

3. Use Cases

• Traditional AI: Spam detection, fraud analysis, recommendation systems, forecasting.

• Generative AI: Writing emails, designing visuals, coding assistants, chatbots, storytelling.

4. Data Requirements

• Traditional AI: Needs labeled datasets (e.g., thousands of images labeled "cat" or "not cat").

• Generative AI: Trained on massive, unstructured data (books, web pages, images, audio) to learn how to generate.

5. Examples

• Traditional AI: Logistic Regression, Decision Trees, SVMs, Random Forests.

• Generative AI: GPT, Claude, DALL·E, Midjourney, Copilot, Gemini.

6. Flexibility

• Traditional AI: Narrow, task-specific models.

• Generative AI: Broad, multi-purpose models with emergent capabilities.

7. Interaction

• Traditional AI: One-way interaction – input → output.

• Generative AI: Conversational and dynamic – context evolves over time.

Traditional AI is like a calculator—fast, precise, but rigid.
Generative AI is like a creative partner—flexible, surprising, and increasingly capable.

Popular LLMs You Should Know

Large Language Models (LLMs) are trained on vast text datasets and learn to predict and generate coherent sequences. Here are the frontrunners:

• GPT-4 / GPT-3.5 (OpenAI) – Versatile, good reasoning, great API ecosystem.

• Claude (Anthropic) – Safer, longer memory, context-aware.

• Gemini (Google) – Strong multimodal capabilities.

• LLaMA (Meta) – Open-source research foundation.

• Command R+ (Cohere) – Focused on retrieval-augmented generation (RAG).

• Mistral / Mixtral – Lightweight, open models with high performance.

Most of these are evolving rapidly and being fine-tuned for speed, safety, and specific domains like legal, medical, or customer service.

What Are Multimodal Models?

Multimodal models process multiple types of input/output:

• Text + Image (e.g., GPT-4 Vision, Gemini)

• Text + Audio (e.g., Whisper, AudioCraft)

• Text + Video (e.g., Sora by OpenAI)

• Text + Code + Graphs (e.g., Claude, Copilot)

They can:

• Analyze images with text prompts

• Describe visuals

• Transcribe speech to text

• Create videos from descriptions

Use case: Ask GPT-4 Vision to explain a chart, identify design flaws, or write code from a screenshot.

Prompt Engineering: The New Literacy

Getting better results isn’t about magic—it’s about precision and context.

Key Techniques:

1. Be explicit
   “Write a 100-word summary of this article in a casual tone.”

2. Give examples
   “Here’s a good intro: ‘In today’s fast-paced world...’ — write something similar.”

3. Set constraints
   “Avoid buzzwords. Use plain English. No more than 3 paragraphs.”

4. Iterate & refine
   “Now make it more persuasive.” → “Add a quote.” → “Simplify language.”

5. Use roles
   “Act as a product manager. Give a roadmap for an MVP.”

Common Prompt Patterns in Prompt Engineering

1. Persona Prompt

Let the AI act like a specific character or expert.

Purpose: Set tone, style, or context.

Prompt Example:

"You are a senior software engineer with 10 years of experience. Explain caching to a junior developer."

Why it works: Gives the AI a role, shaping its language and depth.

2. Few-shot Prompt

Show a few examples before asking a new question.

Purpose: Teach the AI by example, especially when tasks aren’t well-defined.

Prompt Example:

Q: What is the capital of France?
A: Paris
Q: What is the capital of Germany?
A: Berlin
Q: What is the capital of Italy?
A:

Why it works: Helps guide the model’s pattern recognition.

3. Zero-shot Prompt

Ask directly, without examples.

Purpose: Simple tasks where examples aren’t needed.

Prompt Example:

"Translate ‘Good morning’ to Spanish."

Why it works: Large models like GPT are capable of many zero-shot tasks thanks to broad training data.

4. Chain-of-Thought (CoT) Prompt

Ask the model to “think step by step.”

Purpose: Improve reasoning, math, logic tasks.

Prompt Example:

"If I have 3 apples and buy 2 more, how many do I have? Let's think step by step."

Why it works: Encourages the model to break down reasoning before jumping to the answer.

5. Instruction Prompt

Clearly tell the model what to do.

Purpose: Guide the model with commands.

Prompt Example:

"Summarize the following text in 3 bullet points."

Why it works: Reduces ambiguity—crystal-clear instructions improve output quality.

6. Reflexive Prompt

Ask the model to critique or improve its own answer.

Purpose: Refine or validate output.

Prompt Example:

"Rewrite your answer to be more concise and professional."

Why it works: Encourages iterative improvement.

7. Multi-turn Prompt (Contextual Prompting)

Build context across a conversation.

Purpose: Complex tasks like coaching, tutoring, or ongoing chats.

Prompt Example:

1. "Can you explain recursion?"

2. "Now, can you show me how it works in Python?"

Why it works: Maintains context over time for personalized interaction.

Tips for Effective Prompting

• Use clear instructions

• Set context with roles/personas

• Provide examples where possible

• Ask for step-by-step reasoning for complex tasks

• Use feedback loops for refinement

How to Use LLMs in Real Life

For Developers:

• Code suggestions, debugging, API docs summarization.

• ChatOps bots, CLI tools, GitHub Copilot.

For Designers:

• Image generation, UX copywriting, Figma plugins with AI.

For Business Professionals:

• Email drafting, meeting summarization, pitch polishing.

For Data Folks:

• SQL generation, data cleaning scripts, insight explanation.

For Content Creators:

• LinkedIn post ideas, blog outlines, video scripts, newsletter automation.

Building vs Using Generative AI

You don’t have to build your own model. Instead:

• Use OpenAI API, Anthropic Claude, HuggingFace Spaces, LangChain, or Flowise to integrate LLMs into apps.

• Build custom apps for internal tools, customer support, automation, or ideation.

The Only Limit: Your Imagination

Whether you’re a developer, marketer, analyst, or student—generative AI is a toolset that levels the playing field. The challenge isn’t learning the tool. It’s learning how to ask the right questions.

Bottom Line:

• Traditional AI predicts. Generative AI creates.

• Use multimodal AI to combine text, image, video, and more.

• Learn prompt engineering like a skill — it pays off.

• Pick the right LLM for your task.

• The best AI is the one you know how to use effectively.

Thanks a reading, I hope this was helpful.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

1. Relational Databases

Relational databases are structured, reliable, and perfect for scenarios where relationships between data are important.

Key Features:

• SQL Joins

  • Joins allow you to combine data across multiple tables.

  • Caution: They can become major performance bottlenecks, especially at scale. Use wisely!

• Indexes

  • Indexes speed up queries by organizing data using B-Trees or Hash Tables.

  • Common types:

    • Multi-column indexes

    • Geospatial indexes

    • Full-text indexes

  • Trade-off: More indexes = Faster reads but slower writes.

• Transactions

  • Transactions group multiple operations into a single atomic unit.

  • Locking Models:

    • Pessimistic Locking: Prioritizes accuracy (good for critical financial systems).

    • Optimistic Locking: Prioritizes performance (good for high-concurrency environments).

Examples:

• PostgreSQL

• MySQL

2. NoSQL Databases

NoSQL databases offer flexibility, scalability, and are ideal for dynamic, high-velocity data.

Key Features:

• Data Models

  • NoSQL comes in different flavors:

    • Key-Value Stores (e.g., Redis, DynamoDB)

    • Document Stores (e.g., MongoDB)

    • Column-Family Stores (e.g., Cassandra)

    • Graph Databases (e.g., Neo4j)

• Consistency Models
  Understand different types of consistency guarantees:

  • Strong Consistency: Always the latest data.

  • Causal Consistency: Cause-effect order maintained.

  • Sequential Consistency: Same order for all users.

  • Read-Your-Writes Consistency: You see your changes immediately.

  • Eventual Consistency: Data will become consistent... eventually.

• Indexing

  • NoSQL also supports indexes (B-Trees, Hash Indexes) to speed up queries.

• Scalability

  • Designed for horizontal scaling.

  • Techniques:

    • Consistent Hashing

    • Sharding (splitting data across nodes)

Examples:

• DynamoDB

• Cassandra

• MongoDB

3. Blob Storage

Blob = Binary Large Object — Think images, videos, backups.

Key Features:

• Designed to store large, unstructured files efficiently.

• Supports versioning, lifecycle management, and access control.

Use Cases:

• Storing user-uploaded media (profile pictures, videos).

• System backups and archival.

Examples:

• Amazon S3

• Google Cloud Storage

• Azure Blob Storage

4. Search Optimized Storage

When you need fast and flexible querying over large datasets.

Key Features:

• Full-text search

• Faceted search (filtering, sorting)

• Distributed indexing and querying.

Use Cases:

• Building search bars, product catalogs, document retrieval.

Examples:

• Elasticsearch

• Apache Solr

• OpenSearch

5. API Gateway

Acts as the single entry point for external clients.

Key Features:

• Request routing and load distribution.

• Authentication and authorization.

• Rate limiting and throttling.

• API version management.

Use Cases:

• Managing access to microservices.

• Centralized security enforcement.

Examples:

• AWS API Gateway

• Kong

• Apigee

6. Load Balancer

Distributes traffic across multiple servers for scalability and high availability.

Key Features:

• Health checks and failover

• SSL termination

• Sticky sessions (session affinity)

Use Cases:

• Handling millions of concurrent users.

• Redundancy and uptime guarantees.

Examples:

• AWS Elastic Load Balancer (ELB)

• Nginx

• HAProxy

7. Queue

Enables asynchronous communication between services.

Key Features:

• Message durability

• Message acknowledgment and retries

• Dead-letter queues (handling failed messages)

Use Cases:

• Email sending

• Background job processing

• Task offloading

Examples:

• RabbitMQ

• Amazon SQS

• ActiveMQ

8. Stream

Handles real-time, high-throughput data processing.

Key Features:

• Ordered, replayable event logs

• Partitioning for horizontal scaling

• Consumer groups for parallel processing

Use Cases:

• Analytics pipelines

• Monitoring systems

• Real-time feed updates

Examples:

• Apache Kafka

• Amazon Kinesis

9. Distributed Lock

Ensures exclusive access to a resource across a distributed system.

Key Features:

• Prevents race conditions and data corruption.

• Lease expiration to avoid deadlocks.

Use Cases:

• Cron job scheduling across multiple servers.

• Single-writer guarantees in distributed systems.

Examples:

• Redlock algorithm (using Redis)

• Zookeeper locks

• etcd locks

10. Distributed Cache

Ultra-fast, low-latency data access layer.

Key Features:

• Data replication and partitioning.

• TTL (Time-to-Live) for cache expiry.

• Cache invalidation strategies.

Use Cases:

• Session storage

• Caching database query results

• Leaderboard generation

Examples:

• Redis

• Memcached

• Hazelcast

11. Content Delivery Network (CDN)

Globally distributes static content to users.

Key Features:

• Edge caching

• DDoS protection

• TLS termination

Use Cases:

• Faster webpage load times.

• Video streaming.

• Static assets (JS, CSS, Images).

Examples:

• Cloudflare

• AWS CloudFront

• Akamai

Summary

• Databases manage structured data.

• Blob Storage manages large unstructured files.

• Queues and Streams handle async and real-time processing.

• Load Balancers and API Gateways manage traffic and entry points.

• Distributed Caches and Locks ensure speed and consistency.

• CDNs push content closer to your users.

By deeply understanding these components, you can design scalable, efficient, and production-ready systems — no matter how big the challenge.

Thanks a reading, I hope this was helpful.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

What is Refactoring?

Refactoring is the process of improving the internal structure of code without altering its external behavior.

Why Refactoring is important?

• Makes code easier to read and maintain.

• Reduce Technical debt

• Improves collaboration in teams.

• Helps in scaling applications efficiently.

When to Refactor?

• Before adding new features.

• After identifying code smells.

• During regular maintenance.

What are Code Smells?

These are the indicators of bad code. Some common ones:

1. Duplicated Code 

   Duplicated code is one of the worst smells, whenever a change is made, one needs to check if this should have happened to just one or all of the existing copies of code, wherever they are.

2. Long Method 

   A method is doing too much. Like the Hotel California, something is always being added to a method but nothing is ever taken out. Since it’s easier to write code than to read it, this “smell” remains unnoticed until the method turns into an ugly, oversized beast.

3. Large Class 

   A class has too many responsibilities. It violates the single responsibility principle which states that a class should have only one reason to change. Many long-form methods and an abundant number of parameters that can be passed to a class cause Large Class problems.

4. Divergent Change

   Multiple reasons to change a single class. If adding a simple feature makes the developer change many seemingly unrelated methods inside a class, that indicates the Divergent Change code smell.

5. Shotgun Surgery 

   A single change requires modifications in multiple places. Similar to Divergent Change, but with a broader spectrum, the smell symptom of the Shotgun Surgery code is detected by the unnecessary requirement of changing multiple different classes to introduce a single modification.

6. Feature Envy 

   A method uses more data from another class than its own.If a method inside a class manipulates more features (be it fields or methods) of another class more than from its own, then this method has a Feature Envy.

   In Object-Oriented Programming, developers should tie the functionality and behavior close to the data it uses. Coupled objects have to be used together.

7. Data Clumps 

   Groups of variables that always appear together. Data Clumps refer to a situation in which a few variables are passed around many times in the codebase instead of being packed into a separate object. Think of it as having to hold different groceries in a grocery store by hand instead of putting them into a basket.

8. Primitive Obsession 

   Primitive Obsession is a code smell where primitive data types (e.g., int, string, boolean) are overused instead of creating domain-specific objects. This often leads to:

   • Scattered logic across the codebase

   • Lack of encapsulation

   • High risk of errors

9. Switch Statements 

   Long `if-else` or `switch` statements that could be replaced by polymorphism. It violates the Open Closed Principle, which states “Software entities (classes, modules, functions) should be open for extension, but closed for modification.”

Refactoring Techniques

Code is a must-read for developers aiming to write better code. Here are the key refactoring techniques to fix the above code smells:

1. Extract Method

Move a block of code into a separate method.

Extract Method comes under the category of Composing Methods (Improving Readability and Modularity) and this technique solves the problem of Duplicated Code and Long Method code smell.

Problem

You have a code fragment that can be grouped together. The more lines found in a method, the harder it’s to figure out what the method does.

void printOwing() {
  printBanner();
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

Solution

Move this code to a separate new method (or function) and replace the old code with a call to the method.

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

void printDetails(double outstanding) {
  System.out.println("name: " + name);
  System.out.println("amount: " + outstanding);
}

Break large methods into smaller, well-named methods to improve readability, maintainability, and reusability!

2. Extract Class

Split a class into multiple classes when it has too many responsibilities.

Extract Class comes under the category of Moving Features Between Objects.This technique solves the problem of Duplicated Code, Long Class, Divergent Change and Data Clumps code smell.

This refactoring technique will help maintain adherence to the Single Responsibility Principle. The code of your classes will be more obvious and understandable.

Single-responsibility classes are more reliable and tolerant of changes. For example, say that you have a class responsible for ten different things. When you change this class to make it better for one thing, you risk breaking it for the nine others.

Problem

When one class does the work of two, awkwardness results.

class Person {
   String name;
   String officeAreaCode;
   String officeNumber;

   getTelephoneNumber() {}
}  

Solution

Instead, create a new class and place the fields and methods responsible for the relevant functionality in it.

class Person {
   String name;
   TelephoneNumber telephoneNumber;
}  

class TelephoneNumber {
   String officeAreaCode;
   String officeNumber;

   getTelephoneNumber() {}
}

Break large classes into smaller, well-defined classes to improve modularity, readability, and maintainability!

3. Move Method

Shift a method to a more relevant class to improve cohesion.

Move method comes under the category of Moving Features Between Objects and this technique solves the problem of Shotgun Surgery and Feature Envy code smell.

Problem

Here, the BankService class is calculating the account balance, even though BankAccount has all the data.

class BankAccount {
    private double balance;
    private double interestRate;

    public BankAccount(double balance, double interestRate) {
        this.balance = balance;
        this.interestRate = interestRate;
    }

    public double getBalance() {
        return balance;
    }

    public double getInterestRate() {
        return interestRate;
    }
}

class BankService {
    public double calculateInterest(BankAccount account) {
        return account.getBalance() * account.getInterestRate();
    }
}

Solution

We move calculateInterest() to BankAccount so it encapsulates its own behavior.

class BankAccount {
    private double balance;
    private double interestRate;

    public BankAccount(double balance, double interestRate) {
        this.balance = balance;
        this.interestRate = interestRate;
    }

    public double calculateInterest() { 
        return balance * interestRate;
    }
}

class BankService {
    public void printInterest(BankAccount account) {
        System.out.println("Interest: " + account.calculateInterest()); 
    }
}

Always place behavior where the data lives to improve encapsulation and maintainability.

4. Replace Conditional with Polymorphism

Use object-oriented principles to eliminate long if-else or switch statements.

It comes under the category of Simplifying Conditional Expressions and this technique solves the problem of switch or if-else statements code smell.

Problem

The Employee class uses a switch statement to determine salary calculations based on employee type.

class Employee {
    private String type;

    public Employee(String type) {
        this.type = type;
    }

    public double calculateSalary(double baseSalary) {
        switch (type) {
            case "Manager":
                return baseSalary + 5000;
            case "Developer":
                return baseSalary + 2000;
            case "Intern":
                return baseSalary;
            default:
                throw new IllegalArgumentException("Unknown employee type");
        }
    }
}

Solution

We replace the switch statement with inheritance and polymorphism.

// Step 1: Create an abstract base class
abstract class Employee {
    public abstract double calculateSalary(double baseSalary);
}

// Step 2: Implement specific employee types
class Manager extends Employee {
    public double calculateSalary(double baseSalary) {
        return baseSalary + 5000;
    }
}

class Developer extends Employee {
    public double calculateSalary(double baseSalary) {
        return baseSalary + 2000;
    }
}

class Intern extends Employee {
    public double calculateSalary(double baseSalary) {
        return baseSalary;
    }
}

// Step 3: Use polymorphism in the main program
class Payroll {
    public static void main(String[] args) {
        Employee manager = new Manager();
        Employee developer = new Developer();
        Employee intern = new Intern();

        System.out.println("Manager Salary: " + manager.calculateSalary(50000));
        System.out.println("Developer Salary: " + developer.calculateSalary(50000));
        System.out.println("Intern Salary: " + intern.calculateSalary(50000));
    }
}

Use polymorphism - Replace conditionals (switch or if-else) statements with object-oriented design patterns like Strategy or Factory Patterns to make code scalable, maintainable, and extensible.

4. Value Objects

A Value Object (VO) is an immutable object that represents a concept without identity (e.g., money, coordinates, dates). Unlike entities, two Value Objects are considered equal if their values match.

It falls under the category of "Composing Methods" and "Simplifying Conditional Expressions" and this technique solves the problem of Primitive Obsession code smell.

Problem - Using Primitives Directly

class Order {
    private String currency;
    private double amount;

    public Order(String currency, double amount) {
        this.currency = currency;
        this.amount = amount;
    }
}

Solution - Use Value Object

final class Money {
    private final double amount;
    private final String currency;

    public Money(double amount, String currency) {
        if (amount < 0) throw new IllegalArgumentException("Amount cannot be negative");
        if (!currency.matches("USD|EUR|INR")) throw new IllegalArgumentException("Invalid currency");
        this.amount = amount;
        this.currency = currency;
    }
}

class Order {
    private Money totalPrice;

    public Order(Money totalPrice) {
        this.totalPrice = totalPrice;
    }
}

Encapsulation : Money handles validation.
Eliminates primitive obsession : No raw strings for currency.

Stop using primitives for domain concepts! Use Value Objects & Encapsulation to make code robust & maintainable.

Thanks a lot, I hope this was helpful.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

In my earlier post, I have discussed the main differences between useCallback and useMemo and both are used for optimizing the performance of the React application. Similarly to that, React.memo is another component that is also used for improving the performance of the React application.

What is Memoization?

Memoization is not the new concept in computer science, it is used in various context, mainly in dynamic programming to cache the result for the same input in the recursion, so we don’t need to call the expensive recursive method again to calculate the same value that we have encountered earlier and it will helps us to reduce the time complexity of the function and improve the overall performance of the system.

Memoization ensures that a method doesn't run for the same inputs more than once by keeping a record of the results for the given inputs (usually in a hash map).

In React functional components, when props within a component change, the entire component re-renders by calling updateDOM function( Refer - What will happen when you call the setState function ). In other words, if any value within a component updates, the entire component will re-render, including functions/components that have not had their values/props altered.

Now, with the new version of React 19, we don’t need to do memoization anymore in our code, React will take care of optimizations using React Compiler, a new feature introduced in React 19.

React.memo

memo lets you skip re-rendering a component when its props are unchanged.

const MemoizedComponent = memo(SomeComponent, arePropsEqual?)

Parameters

• The first parameter is the component that you want to memoize. The memo does not modify this component, but returns a new, memoized component instead. Any valid React component, including functions and forwardRef components, is accepted.

• The second parameter is optional : A function that accepts two arguments: the component’s previous props, and its new props. It should return true if the old and new props are equal: that is, if the component will render the same output and behave in the same way with the new props as with the old. Otherwise it should return false. Usually, you will not specify this function. By default, React will compare each prop with Object.is.

Returns

memo returns a new React component. It behaves the same as the component provided to memo except that React will not always re-render it when its parent is being re-rendered unless its props have changed.

Example - MemoizedProduct Component

import { ProductType } from "../context/ProductsProvider"
import { ReducerActionType, ReducerAction } from "../context/CartProvider"
import { ReactElement, memo } from "react"

type ProductProps = {
    product : ProductType,
    dispatch : React.Dispatch<ReducerAction>,
    REDUCER_ACTIONS : ReducerActionType
}

const Product = ({product, dispatch, REDUCER_ACTIONS} : ProductProps) : ReactElement => {
   const relativePath = "../images/" + product.sku + '.jpg';
   const img: string = new URL(relativePath, import.meta.url).href

   const onAddToCart = () => dispatch({type : REDUCER_ACTIONS.ADD , payload : {...product , qty : 1}});

   const itemInCart = inCart ? ' Item in Cart ': null

   const content = <article className="product">
        <h3>{product.name}</h3>
        <img src={img} alt={product.name} className="product__img"/>
        <p>{new Intl.NumberFormat('en-US', { style : 'currency', currency : 'USD' }).format(product.price)}
        {itemInCart}</p>
        <button onClick={onAddToCart}>Add to Cart</button>
   </article>

    return content;
}

function areProductsEqual({product : prevProduct} : ProductProps,{product : nextProduct} : ProductProps) {
    return Object.keys(prevProduct).every(key => {
        return prevProduct[key as keyof ProductType] === nextProduct[key as keyof ProductType]
    }) 
}

const MemoizedProduct = memo<typeof Product>(Product, areProductsEqual)

export default MemoizedProduct

useMemo

useMemo is a React Hook that lets you cache the result of a calculation between re-renders.

Same as useCallback, we should define the useMemo at the top level of the component.

const memoizedValue = useMemo(() => expensiveFunction(), [dependency]);

Parameters:

• The first argument is the function calculating the value that you want to cache. It should be pure, should take no arguments, and should return a value of any type. React will call your function during the initial render.

• The second argument is an array of dependencies that determines when the value should be recalculated. React will return the same value again if the dependencies have not changed since the last render. Otherwise, it will call the function, return its result, and store it so it can be reused later. React will compare each dependency with its previous value using the Object.is comparison.

Example 1: useMemo without dependency.

import React, { useState, useMemo } from 'react';

const ExpensiveComponent = () => {
    const [count, setCount] = useState(0);

    const computedValue = useMemo(() => {
        console.log("Computing expensive value...");
        return count * 2;
    }, []); 

    return (
        <div>
            <h1>Computed Value: {computedValue}</h1>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>Increment   Count</button>
      </div>
    );
};

export default ExpensiveComponent;

In this example, we are passing dependencies as an empty array, that means caching a value that should only be computed once.

Example 2: useMemo with dependency.

import React, { useState, useMemo } from 'react';

const ExpensiveComponent = () => {
    const [count, setCount] = useState(0);
    const [items, setItems] = useState([1, 2, 3, 4, 5]);

    const expensiveCalculation = (items) => {
        console.log("Calculating...");
        return items.reduce((sum, item) => sum + item, 0);
    };

    const memoizedCalculation = useMemo(() => expensiveCalculation(items), [items]);

    return (
        <div>
            <h1>Expensive Calculation Example</h1>
            <p>Sum of items: {memoizedCalculation}</p>
            <button onClick={() => setCount(count + 1)}>Increment Count</button>
            <button onClick={() => setItems([...items, Math.random()])}>Add Random Item</button>
        </div>
    );
};

export default ExpensiveComponent;

In this example, dependency is on items, so function will be called again to calculate a new value when items state updates.

Differences between useMemo and memo.

Let's summarize the differences between the two:

• Purpose : useMemo caches the return value of a function whereas memo caches the component.

• When to use : useMemo is used when you have an expensive calculation you want to avoid on every render. memo is used to cache the component to avoid re-rendering.

• Dependencies : useMemo makes sure that an expensive function should only be called for changed dependencies. memo re-renders the component when the dependencies change.

• Common use case : useMemo hook cache results of expensive calculations or data processing. Wrap a component in memo to get a memoized version of that component.

Memoization is a performance optimization, not a guarantee. React may still re-render the memoized version of your component.

Summary:

• useMemo memoizes the result of an expensive computation and only recomputes it when the dependencies change.

• memo memoizes the component usually child component and only re-renders the component when the dependencies change.

• useMemo is useful for avoiding expensive recalculations on every render.

• memo is useful for avoiding re-rendering the component on every render.

• You should only use useMemo and memo it for performance optimizations when you notice performance bottlenecks.

• Using memo is not a guarantee, React may still re-render the memoized version of your component.

In the upcoming post, we will discuss more about new features of React 19 like useFormStatus hook and React compiler.

Stay tuned! Thanks for reading.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

Subscribe now

In this post, we are going to discuss useCallback and useMemo hooks and the differences between them.

The useCallback Hook

useCallback is a React Hook that lets you cache a function definition between re-renders.

Like every hook, we need to define at the top level of the component, you should define the useCallback at the top level of your component.

const memoizedCallback = useCallback(() => {
    // callback logic here
}, [dependencies]);

Parameters:

• The first argument is the function value that you want to cache. It can take any arguments and return any values. React will return (not call!) your function back to you during the initial render. The function is returned to you so you can decide when and whether to call it.

• The second argument is an array of dependencies that determines when the function should be recreated. React will give you the same function again if the dependencies have not changed since the last render. Otherwise, it will recreate the function and store it in case it can be reused later.

Example 1: useCallback without dependency.

import React, { useState, useCallback } from 'react';

const Counter = () => {
    const [count, setCount] = useState(0);

    const increment = useCallback(() => {
        setCount(prevCount => prevCount + 1);
    }, []);

    return (
        <div>
            <p>Count: {count}</p>
            <button onClick={increment}>Increment</button>
        </div>
    );
};

In this example, we are passing dependencies as an empty array, that means the function is only created once.

Example 2: useCallback with dependencies.

import React, { useState, useCallback } from 'react';

const Counter = () => {
    const [count, setCount] = useState(0);
    const [name, setName] = useState("React");

    const increment = useCallback(() => {
        setCount(prevCount => prevCount + 1);
        console.log(`Count updated: ${count}`);
    }, [count]); 

    const changeName = () => {
        setName(name === "React" ? "Vite" : "React");
    };

    return (
        <div>
            <h1>{name} Counter</h1>
            <p>Current Count: {count}</p>
            <button onClick={increment}>Increment</button>
            <button onClick={changeName}>Change Name</button>
       </div>
    );
};

export default Counter;

In this example, dependency is on count, so function will only recreates when count updates.

The useMemo Hook

useMemo is a React Hook that lets you cache the result of a calculation between re-renders.

Same as useCallback, we should define the useMemo at the top level of the component.

const memoizedValue = useMemo(() => expensiveFunction(), [dependency]);

Parameters:

• The first argument is the function calculating the value that you want to cache. It should be pure, should take no arguments, and should return a value of any type. React will call your function during the initial render.

• The second argument is an array of dependencies that determines when the value should be recalculated. React will return the same value again if the dependencies have not changed since the last render. Otherwise, it will call the function, return its result, and store it so it can be reused later. React will compare each dependency with its previous value using the Object.is comparison.

Example 1: useMemo without dependency.

import React, { useState, useMemo } from 'react';

const ExpensiveComponent = () => {
    const [count, setCount] = useState(0);

    const computedValue = useMemo(() => {
        console.log("Computing expensive value...");
        return count * 2;
    }, []); 

    return (
        <div>
            <h1>Computed Value: {computedValue}</h1>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>Increment   Count</button>
      </div>
    );
};

export default ExpensiveComponent;

In this example, we are passing dependencies as an empty array, that means caching a value that should only be computed once.

Example 2: useMemo with dependency.

import React, { useState, useMemo } from 'react';

const ExpensiveComponent = () => {
    const [count, setCount] = useState(0);
    const [items, setItems] = useState([1, 2, 3, 4, 5]);

    const expensiveCalculation = (items) => {
        console.log("Calculating...");
        return items.reduce((sum, item) => sum + item, 0);
    };

    const memoizedCalculation = useMemo(() => expensiveCalculation(items), [items]);

    return (
        <div>
            <h1>Expensive Calculation Example</h1>
            <p>Sum of items: {memoizedCalculation}</p>
            <button onClick={() => setCount(count + 1)}>Increment Count</button>
            <button onClick={() => setItems([...items, Math.random()])}>Add Random Item</button>
        </div>
    );
};

export default ExpensiveComponent;

In this example, dependency is on items, so function will be called again to calculate a new value when items state updates.

Differences Between useMemo and useCallback

Let's summarize the differences between the two hooks:

• Purpose : useMemo caches the return value of a function whereas useCallback caches the function definition itself.

• When to use : useMemo is used when you have an expensive calculation you want to avoid on every render. useCallback is used to cache a function to avoid re-creating it on every re-render.

• Dependencies : useMemo makes sure that an expensive function should only be called for changed dependencies. useCallback re-creates function when the dependencies change.

• Common use case : useMemo hook cache results of expensive calculations or data processing. useCallback passing memoized functions to child components.

Summary:

• useMemo memoizes the result of an expensive computation and only recomputes it when the dependencies change.

• useCallback memoizes the function definition and only recreates the function when the dependencies change.

• useMemo is useful for avoiding expensive recalculations on every render.

• useCallback is useful for avoiding recreating the function on every render.

• You should only use useMemo and useCallback it for performance optimizations when you notice performance bottlenecks.

Thanks a lot, I hope this was helpful.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

Let’s first try to understand some basic concepts before going into the depth of hook.

Hooks in React

In React, useState, as well as any other function starting with “use”, is called a Hook.

There are some limitations, where we need to use hook in our component.

1. Hooks can only be called at the top level of your components or your custom hooks.

function MyButton() {
    const [count, setCount] = useState(0);
    // ...

2. Don’t call Hooks inside loops, conditions, nested functions or inside a map call.

<ul>
    {items.map((item) => {
        // Doesn't work!
        const ref = useRef(null);
        return <li ref={ref} />;
    })} 
</ul>;

You should use React features at the top of your component similar to how you import modules at the top of your file.

useState Hook

What is state in React and why do we need state in our component?

Components often need to change what’s on the screen as a result of an interaction. Typing into the form should update the input field, clicking next on an image carousel should change which image is displayed, clicking buy should put a product in the shopping cart.

To update a component with new data, two things need to happen:

1. Retain the data between renders.

2. Trigger React to render the component with new data (re-rendering).

The useState Hook provides those two things:

1. A state variable to retain the data between renders.

2. A state setter function to update the variable and trigger React to render the component again.

const [index, setIndex] = useState(0);

In this case, you want React to remember index.

The convention is to name this pair like const [something, setSomething]. You could name it anything you like, but conventions make things easier to understand across projects.

The only argument to useState is the initial value of your state variable. In this example, the index’s initial value is set to 0 with useState(0).

What happens when you update the state?

Let’s take the same index example to understand.

1. Your component renders the first time. Because you passed 0 to useState as the initial value for index, it will return [0, setIndex]. React remembers 0 is the latest state value.

2. You update the state. When a user clicks the button, it calls setIndex(index + 1). index is 0, so it’s setIndex(1). This tells React to remember index is 1 now and triggers another render.

3. Your component’s second render. React still sees useState(0), but because React remembers that you set index to 1, it returns [1, setIndex] instead.

4. And so on!

Let’s dive into deeper concept of how useState works under the hood.

How does React know which state to return? 

There is no identifier that is passed to useState, so how does it know which of the state variables to return?

Internally, React holds an array of state pairs for every component. It also maintains the current pair index, which is set to 0 before rendering. Each time you call useState, React gives you the next state pair and increments the index.

Note - It’s just gives an idea of how react useState hook works internally, real implementation may differ.

useState function

let componentHooks = [];
let currentHookIndex = 0;

function useState(initialState) {
    let pair = componentHooks[currentHookIndex];
    if (pair) {
        currentHookIndex++;
        return pair;
    }
    pair = [initialState, setState];
    function setState(nextState) {
        pair[0] = nextState;
        updateDOM();
    }    
    componentHooks[currentHookIndex] = pair;
    currentHookIndex++;
    return pair;
}

updateDom function

function updateDOM() {
    currentHookIndex = 0;
    let output = ArtistGallery();

    nextButton.onclick = output.onNextClick;
    header.textContent = output.header;
    image.src = output.imageSrc;
    image.alt = output.imageAlt;
}

ArtistGallery Component

function ArtistGallery() {
    const [index, setIndex] = useState(0);
    function handleNextClick() {
        setIndex(index + 1);
    }   
    let image = imageList[index];
    return {
        onNextClick: handleNextClick,
        header: `${image.name} by ${image.artist}`,
        counter: `${index + 1} of ${imageList.length}`,
        imageSrc: imageList.url,
        imageAlt: imageList.alt
    };
}

demo.js file

let nextButton = document.getElementById('nextButton');
let header = document.getElementById('header');
let image = document.getElementById('image');

let imageList = [{
    name: 'Homenaje a la Neurocirugía',
    artist: 'Marta Colvin Andrade',
    url: 'https://i.imgur.com/Mx7dA2Y.jpg',
    alt: 'A bronze statue of two crossed hands delicately holding a human brain in their fingertips.'
    },{
    name: 'Floralis Genérica',
    artist: 'Eduardo Catalano',
    url: 'https://i.imgur.com/ZF6s192m.jpg',
    alt: 'A gigantic metallic flower sculpture with reflective mirror-like petals and strong stamens.'
    },{
    name: 'Eternal Presence',
    artist: 'John Woodrow Wilson',
    url: 'https://i.imgur.com/aTtVpES.jpg',
    alt: 'The sculpture depicting a human head seems ever-present and solemn. It radiates calm and serenity.'
    }];

updateDOM();

Let’s try to understand this code step by step.

useState function

1. As component can use multiple hooks so, it creates an array of component hooks and the current hook index variable and set the initial value to 0.

let componentHooks = [];
let currentHookIndex = 0;

2. React checks if this is not the first render, it returns the existing state pair and prepare for the next hook call.

let pair = componentHooks[currentHookIndex];
if (pair) {
    currentHookIndex++;
    return pair;
}

3. If this is the first time we’re rendering react create a new state pair and store the pair for future renders and prepare for the next hook call.

pair = [initialState, setState];
componentHooks[currentHookIndex] = pair;
currentHookIndex++;
return pair;

4. Updating the state using set state function. When the user requests a state change, react put the new value into the pair.

function setState(nextState) { 
    pair[0] = nextState;
    updateDOM();
}

5. When the user requests for state change, it also triggers the updateDOM() function. The updateDOM function resets the value of the currentHookIndex to 0 and assign the new values which is returned from the component.

currentHookIndex = 0;
let output = ArtistGallery();
nextButton.onclick = output.onNextClick;
header.textContent = output.header;
image.src = output.imageSrc;
image.alt = output.imageAlt;

ArtistGallery Component

ArtistGallery component using the useState function and initializing the index value to 0. In this example we’re not using React so, this component returns object as the output instead of JSX.

return {     
    onNextClick: handleNextClick,
    header: `${image.name} by ${image.artist}`,
    counter: `${index + 1} of ${imageList.length}`,
    imageSrc: imageList.url,   
    imageAlt: imageList.alt
};

demo.js file

This file is created to make the UI match with the initial state by calling the updateDOM() function initially.

let nextButton = document.getElementById('nextButton');
let header = document.getElementById('header');
let image = document.getElementById('image');

let imageList = [{
    name: 'Homenaje a la Neurocirugía',
    artist: 'Marta Colvin Andrade',
    url: 'https://i.imgur.com/Mx7dA2Y.jpg',
    alt: 'A bronze statue of two crossed hands delicately holding a human brain in their fingertips.'
    },{
    name: 'Floralis Genérica',
    artist: 'Eduardo Catalano',
    url: 'https://i.imgur.com/ZF6s192m.jpg',
    alt: 'A gigantic metallic flower sculpture with reflective mirror-like petals and strong stamens.'
    },{
    name: 'Eternal Presence',
    artist: 'John Woodrow Wilson',
    url: 'https://i.imgur.com/aTtVpES.jpg',
    alt: 'The sculpture depicting a human head seems ever-present and solemn. It radiates calm and serenity.'
    }];

updateDOM();

Summary

• If you want your component to remember some information between renders use state.

• Hooks are special functions that start with use.

• The useState Hook returns a pair of values: the current state and the function to update it.

• You can have more than one state variable. Internally, React matches them up by their order.

Thanks a lot, I hope this was helpful.

👋 Let’s connect

You can find me on LinkedIn.

If you like my content don’t forget to subscribe and hit the like ❤️ button at the bottom to help support me or share this with a friend. It keeps me motivated to share more content and help people to learn more. 🙏

Subscribe now

A reliable distributed system is composed of reliable applications.

Reliable applications have several positive properties, and these properties help us when we’re building distributed systems, but they’re also good just on their own. Some of these properties are idempotence, immutability, location independence, and versioning.

Idempotence

Idempotence is a property that helps us to tolerate unreliable networks.

When the network is unreliable, the client might have to retry, and an idempotent application won’t duplicate the effect if it receives a duplicate message.

Problems with CRUD

CRUD stands for create, read, update, and delete. These are four operations that you can use in order to create and modify entities within your system. The default position for mapping these four operations onto a RESTful API is to map create to POST, read to GET, update to PUT, and delete, of course, to DELETE.

Now the problem with that default mapping has to do with idempotence. In REST, the PUT and DELETE verbs are specified to be idempotent, but POST is not idempotent. An idempotent operation is one that will have no effect if it is received a second time. So, for example, if you were to PUT some contents to a resource and then repeat that PUT, the second one wouldn’t change the contents. POST, however, is not guaranteed to be idempotent by default. That means if you were to POST to a resource twice, you would end up with two different entities.

Remember, the network is unreliable. Let’s see what happens with a typical API when the client has to retry. Let’s say that the client wants to create a new employee, and so they’re going to POST to the /employees resource. The first time the server is going to insert into the Employee table and then come up with the new unique ID of 37. This is an auto‑incrementing ID that the database generates upon INSERT. The server then responds with a 201 Created and the URL /employees/37. But remember, the network is unreliable. So what if the client never hears about this 201? The client has no choice but to try again. Now whether that’s the user clicking submit twice or something within the application performing a retry, it doesn’t matter. The application is going to end up sending another POST to /employees. On that second POST, the server is also going to do an INSERT into the Employee table, but this time it’s going to come back with the ID of 38. So the second time we return a 201 CREATED /employees/38. This operation is not idempotent because upon the second receipt of the same message, the server duplicated the effect. It ends up inserted two rows.

In order to behave in an idempotent manner, it needs to determine whether the client intended to create a second employee or if that was just a duplicate message. But in this particular API, every creation looks exactly the same. And so the server can’t tell the difference between an intentional creation of a second object and a retry.

The solution is to introduce a client‑side ID. You see, if the client knows the ID of the object before it’s created, then the server can tell the difference between the creation of a new object and a duplicate message. Duplicate messages will carry the same IDs as the original. And now if the client is supposed to know the ID before creation, we can’t wait for the server to run an INSERT on the database in order to generate the ID. And so we have to use a different ID than the auto incrementing key in the database. In this case, we chooses to use a GUID as the ID of a employee. we’ll represent this as an alternate key in the database. And then, we’ll redesign the API to look like this. To create a new employee, the client will POST to /employees/abc‑123, the GUID of the employee that they intend to create. Upon first receipt of this message, the server will see that that alternate key does not exist within the Employee table. It will therefore insert the row and then return a 201 CREATED /employees/abc‑123. The table still has a primary key, which is an auto‑incrementing ID, but that ID is never returned through the API. But let’s suppose that our unreliable network has dropped that 201 response message, and so the client retries. The client still has the ID that it intends to create, and so it sends a POST to /employees/abc‑123. This time when the server sees that message, it can tell that that alternate key already exists within the Employee table. It therefore does not insert an additional row, but it still returns 201 CREATED /employees/abc‑123. And so with these two changes to the API design and to the database design, we will be able to implement idempotence on the server side.

Immutability

Immutability is good because that means that we keep a record of everything that happened within the system. And a beautiful application won’t destroy data by overwriting it or deleting it.

Immutability as a default has several different advantages, some technical and some business advantages. One business advantage is that immutability gives you a reliable audit log. If you can’t change or delete the information that’s in the database, then every decision becomes an insert. Every row is an entry in your audit log, capturing the intent of the user. Another advantage on both the business and the technical side is that immutable systems do not destroy data. Immutable records cannot be deleted, and they cannot be updated where updates would replace or destroy the information that used to be in that record. But the most important technical advantage of immutability is that it preserves metadata. Preserving metadata is especially important in a distributed system. Metadata reveals which information a certain node has received in the past and therefore can control how it reacts to new information in the future. Metadata allows remote peers to converge and become eventually consistent.

Immutability is a great default for distributed systems. we will choose two very simple patterns to begin with. The first one is snapshots. Rather than keeping the mutable state of an employees within the Employee table, we are going to keep a separate snapshot table, and this will be called Employee Description table. Every time a user wants to change the description of a employee, they will end up inserting a row into the snapshot table. That will simulate updates, but what about deletes? Well for that, we will use the tombstone pattern. Instead of actually deleting the employee record, we’ll insert a new record into the Employee Removed table. The presence of this employee removed child record indicates that the employee has been deleted. Both Employee Description and Employee Removed table have a employeeID foreign key, and they also contain a date. All tables in this system have an alternate key, and these two are no exception. The alternate keys of these two tables are the EmployeeID and either the date modified or the date removed.

Location Independence

Distributed systems are made up of different applications that are deployed to different locations. If the behavior of an application is dependent upon where it’s deployed, its location, then that causes problems while composing it into a distributed system.

The third property that we want in a reliable application is location independence. Location independence implies that an application’s behavior does not depend upon its location. In other words, if you were to deploy an application to multiple locations and then send the same message to each instance, they would all produce the same behavior. This might seem like a property that we get almost for free, but we’ve already seen one example of an application design pattern that is not location independent, and that is the use of auto‑incrementing IDs. An auto‑incrementing ID generated on one database is only good at that one database. As an identifier for a row, it’s dependent upon that location. If we were to insert the same object into databases at different locations, they would each come up with different identifiers. Where still, databases in different locations will come up with the same identifier for different objects.

The solution to the above problem is to use hash, which is great location independent identifier. When hashes are used as identifiers, the pattern is known as content‑addressed storage. Content‑address storage means that you’re using the content to identify itself. It works by computing the hash of the content that you want to store and then storing that in a location addressed by that hash. Now if somebody wants to refer to that object, they simply reference it by its hash. Unlike an auto‑incremented ID, content‑addressed storage is location independent. Every single instance of the application will compute the same hash for a given object. The hash depends only upon the content and not upon anything else that might happen to be stored at that location. Furthermore, different locations storing different objects are very unlikely to produce the same hash. Hash collisions are vanishingly rare.

Now, if you’re thinking, that’s a really strange way to identify an object, well, you’re probably already familiar with an existing implementation of content‑addressed storage. Docker, for example, uses content‑addressed storage in order to identify images. The identity of a Docker image is the hash of the steps that it took to produce it. You might also be familiar with Git. Git uses the SHA‑1 hash of the commit as its identity.

Versioning

Things change over time, and a well‑versioned application will tolerate those changes over time.

The final property that we wants to ensure that our reliable application has is proper versioning. we know that the network is not homogenous, and that means that different versions or applications are going to be deployed across different locations at different times. As this happens, we wants to make sure that we maintains the contract across those changes, and so we are going to want to make sure that we puts a good versioning strategy in place from the beginning.

To consider how to version an application, we are going to break it down into three large components. An application consists of code, data, and an API. The code is by far the easiest of these three to version. We can use tools like source control and continuous integration and continuous delivery pipelines in order to make sure that we’re delivering a consistent set of application code. And when the code is downloaded in pieces to the browser, we can use content‑addressed storage in order to make sure that all of the artifacts are consistent with one another. While code versioning is easy, data versioning is a little bit more tricky. Data will be stored on each of the different nodes, and we’ll have to migrate that data to the next version in order to evolve the application. Since we are going to favor creating new tables, rather than adding columns to existing tables and finally, while data might be tricky, API versioning is downright difficult. Here, we consider the API of an application to be the endpoints that you can call, as well as the messages that you send and receive. API management is really application lifecycle management, because application interfaces evolve over time. There is no agreed‑upon best practice for evolving an API.

We can use the URL strategy in order to indicate the version of the API. As the API evolves, the path changes to include a new version number. Another strategy would be to use content types in order to version APIs. A client would use an application‑defined Accept header, and the server supply an application‑defined Content‑Type. While this is more in keeping with the design philosophy of REST, it’s a bit more difficult to implement. And the final versioning strategy is to simply avoid versioning, and while this might at first seem like an irresponsible strategy, it’s precisely the strategy that GraphQL uses. GraphQL favors version-less APIs and allows the client to choose what the structure of their response.

Summary

These four properties are not the default. They don’t come with any application template. It requires a bit more effort and buy‑in from application development teams, but the results are well worth it. By having these practices in place ahead of time, we know that each of the applications that our team builds are going to be good citizens of a distributed system. If you don’t need to build distributed systems, then stop right here. Apply these principles, and your applications will be more reliable.

1. ArrayList subList() method

As many of us know the subList() method of java.util.ArrayList class is used to return the portion of this list between the specified fromIndex, inclusive, and toIndex, exclusive. (If fromIndex and toIndex are equal, the returned list is empty.)

But, it not only returns the portion of the list, but it also returns a view of the portion of the list. Let’s understand better with the help of code!

List<String> namesList = new ArrayList<>();

namesList.add("David");
namesList.add("George");
namesList.add("Anne");
namesList.add("Bailey");
namesList.add("Carol");

System.out.println("Original State of namesList : "+namesList);

# Output of original List
Original State of namesList : [David, George, Anne, Bailey, Carol]

# Get a view of list from index 1 to 3
List<String> subList = namesList.subList(1, 4);

# Sort the elements in reverse order
subList.sort(Comparator.reverseOrder());

System.out.println("Original State of namesList after sorting subList : "+namesList);

# Output of original List
Original State of namesList after sorting subList : [David, George, Bailey, Anne, Carol]

The returned list is backed by the original list, so non-structural changes in the returned list are reflected in the original list, and vice-versa. The returned list supports all of the optional list operations.

So, if you try to make any structural changes in the returned list by using methods like add and clear. you will get UnsupportedOperationException.

2. Arrays asList() method

The List returned using Arrays.asList() method is a fixed-size List, we can’t add/remove elements.

String[] flowers = { "Ageratum", "Allium", "Poppy", "Catmint" };  List<String> flowerList = Arrays.asList(flowers);  

flowerList.add("Celosia"); // throws UnsupportedOperationException

The root of this Exception is that the returned object doesn’t implement the add() operation since it isn’t the same as java.util.ArrayList.

There are ways by which we can get the mutable list from Arrays.asList method.

For instance, we can pass the return object of Arrays.asList method in the constructor of ArrayList, which will support the add and remove operations.

String[] flowers = { "Ageratum", "Allium", "Poppy", "Catmint" };  List<String> flowerList = new ArrayList<>(Arrays.asList(flowers));

3. Double Brace Initialization

Double braces can be used for creating and initializing objects in a single Java expression.

Standard Approach:

Normally we initialize and populate a set as follows:

Set<String> countries = new HashSet<String>();                     countries.add("India");     
countries.add("USA");
countries.add("USSR");

As you can see in the above code

1. Create an instance of HashSet

2. Add countries to the HashSet

Using Double Brace:

We can actually combine the creation and initialization in a single statement; this is where we make use of double braces:

Set<String> countries = new HashSet<String>() {{ 
           
add("India");            
add("USSR");            
add("USA");        
       
}};

As you can see in the above code:

1. Creating an anonymous inner class that extends HashSet

2. Providing an instance initialization block that invokes the add method and adds the country name to the HashSet

Advantages of using Double Brace:

• Fewer lines of code compared to the native way of creation and initialization.

• The code is more readable.

• Creation initialization is done in the same expression.

Thank you, for reading this post, hope you liked it please give applause.

A Subject is like an Observable, but can multicast to many Observers. Subjects are like EventEmitters: they maintain a registry of many listeners.

Every Subject is an Observable. You can subscribe to a Subject, providing an Observer, which will start receiving values normally. From the perspective of the Observer, it cannot tell whether the Observable execution is coming from a plain unicast Observable or a Subject.

Every Subject is an Observer. It is an object with the methods next(v), error(e), and complete(). To feed a new value to the Subject, just call next(value), and it will be multicasted to the Observers registered to listen to the Subject.

Let’s see the example below for a better understanding:

import { Subject } from 'rxjs';

const subject = new Subject<number>();

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});
subject.subscribe({
  next: (v) => console.log(`observerB: ${v}`)
});

subject.next(1);
subject.next(2);

// Logs:
// observerA: 1
// observerB: 1
// observerA: 2
// observerB: 2

Since a Subject is an Observer, this also means you may provide a Subject as the argument to the subscribe of any Observable.

import { Subject, from } from 'rxjs';

const subject = new Subject<number>();

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});
subject.subscribe({
  next: (v) => console.log(`observerB: ${v}`)
});

const observable = from([1, 2, 3]);

observable.subscribe(subject); // You can subscribe providing a Subject

// Logs:
// observerA: 1
// observerB: 1
// observerA: 2
// observerB: 2
// observerA: 3
// observerB: 3

Few Specializations of the Subject type

1. BehaviorSubject

2. ReplaySubject

3. AsyncSubject

BehaviorSubject

BehaviorSubject, which has a notion of "the current value". It stores the latest value emitted to its consumers, and whenever a new Observer subscribes, it will immediately receive the "current value" from the BehaviorSubject.

In the below example, the BehaviorSubject is initialized with the value 0 which the first Observer receives when it subscribes. The second Observer receives the value 2 even though it subscribed after the value 2 was sent.

import { BehaviorSubject } from 'rxjs';
const subject = new BehaviorSubject(0); // 0 is the initial value

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});

subject.next(1);
subject.next(2);

subject.subscribe({
  next: (v) => console.log(`observerB: ${v}`)
});

subject.next(3);

// Logs
// observerA: 0
// observerA: 1
// observerA: 2
// observerB: 2
// observerA: 3
// observerB: 3

ReplaySubject

A ReplaySubject records multiple values from the Observable execution and replays them to new subscribers.

When creating a ReplaySubject, you can specify how many values to replay:

import { ReplaySubject } from 'rxjs';
const subject = new ReplaySubject(3); // buffer 3 values for new subscribers

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});

subject.next(1);
subject.next(2);
subject.next(3);
subject.next(4);

subject.subscribe({
  next: (v) => console.log(`observerB: ${v}`)
});

subject.next(5);

// Logs:
// observerA: 1
// observerA: 2
// observerA: 3
// observerA: 4
// observerB: 2
// observerB: 3
// observerB: 4
// observerA: 5
// observerB: 5

As you can see last 3 values are stored for the new subscriber which is 2, 3, and 4.

Window time in ReplaySubject

ReplaySubject takes one more argument which specifies a window time in milliseconds.

Besides the buffer size, to determine how old the recorded values can be we can specify window time.

Let’s see the example below, we use a large buffer size of 100, but a window time parameter of just 500 milliseconds.

import { ReplaySubject } from 'rxjs';
const subject = new ReplaySubject(100, 500 /* windowTime */);

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});

let i = 1;
setInterval(() => subject.next(i++), 200);

setTimeout(() => {
  subject.subscribe({
    next: (v) => console.log(`observerB: ${v}`)
  });
}, 1000);

// Logs
// observerA: 1
// observerA: 2
// observerA: 3
// observerA: 4
// observerA: 5
// observerB: 3
// observerB: 4
// observerB: 5
// observerA: 6
// observerB: 6
// ...

With the 500 milliseconds(0.5 second) windowTime the replay subject is only able to store the last 3 values under this time regardless of the buffer size.

AsyncSubject

The AsyncSubject is a variant where only the last value of the Observable execution is sent to its observers, and only when the execution completes.

import { AsyncSubject } from 'rxjs';
const subject = new AsyncSubject();

subject.subscribe({
  next: (v) => console.log(`observerA: ${v}`)
});

subject.next(1);
subject.next(2);
subject.next(3);
subject.next(4);

subject.subscribe({
  next: (v) => console.log(`observerB: ${v}`)
});

subject.next(5);
subject.complete();

// Logs:
// observerA: 5
// observerB: 5

In the above example, the last value observers will get only after calling subject.complete() without calling complete() method no value will be sent to observers.

Thank you, for reading this blog, hope you liked it please give applause and follow.

Introduction

In the simple term , Git is software you install on your computer to interact with Git repositories and GitHub is a very popular website (and free to use), which is used to host GitHub repositories.

Git is a free and open-source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Let’s understand what is Version Control System.

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

Daily life example: Imagine that your boss gave you a task to write an article on the paper in one hour. You are sure that you will finish perfectly but as we ,are human there are always possibilities, to make mistakes. After one hour, you just realized that made a mistake. Oh, no! Was there a way to fix it?

In real life, you can take precautions on time to avoid unwanted situations or if something has really happened before prevention, simply means that it happened. So, we cannot change things occurred in past in actual life. Fortunately, version control systems help us to go back in time without a magic wand. Besides, it has more benefits than undo steps. Let’s learn more.

Before understanding distributed version control system , let’s take a look at types of Version Control System.

There are many version control systems out there. Often they are divided into two groups: “centralized” and “distributed”.

• Centralized Version Control System

• Distributed Version Control System

Centralized Version Control System(CVCS)

Centralized version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Drawbacks of CVCS

• It is not locally available, which means we must connect to the network to perform operations.

• During the operations, if the central server gets crashed, there is a high chance of losing the data.

• For every command, CVCS connects the central server which impacts speed of operation

​The Distributed Version Control System is developed to overcome all these issues.

Distributed Version Control System(DVCS)

In distributed version control most of the mechanism or model applies the same as centralized. The only major difference you will find here is, instead of one single repository which is the server, here every single developer or client has their own server and they will have a copy of the entire history or version of the code and all of its branches in their local server or machine. Basically, every client or user can work locally and disconnected which is more convenient than centralized source control and that’s why it is called distributed.

It doesn’t follow the way of communicating or merging the code straight forward to the master repository after making changes. Firstly you commit all the changes in your own server or repository and then the ‘set of changes’ will merge to the master repository.

Some Basic Commands to use GIT

Getting a Git Repository

There are two ways to obtain a Git repository :

1. You can take a local directory that is currently not under version control, and turn it into a Git repository, or

2. You can clone an existing Git repository from elsewhere.

In either case, you end up with a Git repository on your local machine, ready for work.

Initializing a Repository in an Existing Directory

To create a new repo, you’ll use the git init command. git init is a one-time command you use during the initial setup of a new repo. Executing this command will create a new .git subdirectory in your current working directory. This will also create a new main branch.

$ git init

Cloning an Existing Repository

If a project has already been set up in a central repository, the clone command is the most common way for users to obtain a local development clone. Like git init, cloning is generally a one-time operation. Once a developer has obtained a working copy, all version control operations are managed through their local repository.

$ git clone <repo url>

Recording Changes to the Repository

Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about.

Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because Git just checked them out and you haven’t edited anything.

As you edit files, Git sees them as modified, because you’ve changed them since your last commit. As you work, you selectively stage these modified files and then commit all those staged changes, and the cycle repeats.

Checking the Status of Your Files

The git status command displays the state of the working directory and the staging area. It lets you see which changes have been staged, which haven’t, and which files aren’t being tracked by Git.

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

This means you have a clean working directory; in other words, none of your tracked files are modified. Git also doesn’t see any untracked files, or they would be listed here. Finally, the command tells you which branch you’re on.

Saving changes

• git add

• git commit

• git diff

• git stash

git add

The git add command adds a change in the working directory to the staging area. It tells Git that you want to include updates to a particular file in the next commit. However, git add doesn't really affect the repository in any significant way—changes are not actually recorded until you run git commit.

$ git add <file> 
// Stage all changes in <file> for the next commit.

$ git add <directory>
// Stage all changes in <directory> for the next commit.

git commit

The git commit command captures a snapshot of the project's currently staged changes. Committed snapshots can be thought of as “safe” versions of a project—Git will never change them unless you explicitly ask it to. Prior to the execution of git commit, The git add command is used to promote or 'stage' changes to the project that will be stored in a commit.

$ git commit -m "commit message"

git diff

git status command is too vague for you — you want to know exactly what you changed, not just which files were changed — you can use the git diff command. You’ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although git status answers those questions very generally by listing the file names, git diff shows you the exact lines added and removed — the patch, as it were.

To see what you’ve changed but not yet staged, type git diff with no other arguments:

$ git diff

That command compares what is in your working directory with what is in your staging area. The result tells you the changes you’ve made that you haven’t yet staged.

You can use git diff --staged. This command compares your staged changes to your last commit:

$ git diff --staged

git stash

Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later. The answer to this issue is the git stash command.

Stashing takes the dirty state of your working directory — that is, your modified tracked files and staged changes — and saves it on a stack of unfinished changes that you can reapply at any time (even on a different branch).

$ git stash
Saved working directory and index state \
  "WIP on master: 049d078 Create index file"
HEAD is now at 049d078 Create index file
(To restore them type "git stash apply")

You can reapply the one you just stashed by using the command : git stash apply

$ git stash apply
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   index.html
	modified:   lib/simplegit.rb

no changes added to commit (use "git add" and/or "git commit -a")

Thank you, for reading this post , hope you liked it please give an applause.

Introduction

SOLID is an acronym for the first five object-oriented design (OOD) principles by Robert C. Martin (also known as Uncle Bob).

SOLID stands for:

• S — Single Responsibility Principle

• O — Open-closed Principle

• L — Liskov Substitution Principle

• I — Interface Segregation Principle

• D — Dependency Inversion Principle

Why use the Solid Principles of OOP?

• Object Oriented Programming is a powerful concept.

• But, OOP doesn’t always lead to quality software.

• The five principles focus on dependency management.

• Poor Dependency Management leads to code that is brittle, fragile, and hard to change.

• Proper dependency management leads to quality code that is easy to maintain.

Single Responsibility Principle

Single Responsibility Principle states that

A class should have one and only one reason to change, meaning that a class should have only one job.

• Every class should have a single responsibility.

• Classes should be small. No more than a screen full of code.

• Avoid GOD classes

• Split big classes into smaller classes.

Let’s understand with the help of code.

public class SimpleCalculator{

  public int add(int a , int b){
      return a + b;
  }

  public int subtract(int a , int b){
      return a - b;
  }

  public int multiply(int a , int b){
      return a * b;
  }

  public int divide(int a , int b){
      return a/b;
  }
  
  public void printSum(int sum){
      System.out.println(s);
  }

}

The Simple calculator class violates the rule of SRP. As per the rule a class should have one job to do but the Simple calculator class have two responsibilities calculating and printing the value.

We should create another class ValuePrinter that handles only printing the value.

public class ValuePrinter{

public void printSum(int value){
      System.out.println(value);
  }

}

public class SimpleCalculator{

public int add(int a , int b){
      return a + b;
  }

public int subtract(int a , int b){
      return a - b;
  }

public int multiply(int a , int b){
      return a * b;
  }

public int divide(int a , int b){
      return a/b;
  }
}

That satisfies the single-responsibility principle.

Open-Closed Principal

Open-Closed principle states that

Objects or entities should be open for extension but closed for modification.

• Classes should be open for extension.

• But close for modification.

• You should be able to extend a classes behavior, without modifying it.

• Use private variables with getters and setters -ONLY when you need them.

• Use abstract base classes.

Consider an insurance system that validates health insurance claims before approving one. A HealthInsuranceSurveyor class responsible to validate claims and a ClaimApprovalManager class responsible to approve claims.

public class HealthInsuranceSurveyor{

public boolean isValidClaim(){
    System.out.println("HealthInsuranceSurveyor: Validating health insurance claim...");
  
   return true;

 }

public class ClaimApprovalManager{

public void processHeathClaim(HealthInsuranceSurveyor surveyor){
       if(surveyor.isValidClaim()){
           System.out.println("ClaimApprovalManager : Valid claim. 
Currently processing claim for approval....");

      }

  }

}

Both the HealthInsuranceSurveyor and ClaimApprovalManager classes work fine and the design for the insurance system appears perfect until a new requirement to process vehicle insurance claims arises.We now need to include a new VehicleInsuranceSurveyor class, and this should not create any problems. But, what we also need is to modify the ClaimApprovalManager class to process vehicle insurance claims. This is how the modified ClaimApprovalManager will be:

Modified ClaimApprovalManager.java

public class ClaimApprovalManager{

public void processHeathClaim(HealthInsuranceSurveyor surveyor){
       if(surveyor.isValidClaim()){
           System.out.println("ClaimApprovalManager : Valid claim. 
Currently processing claim for approval....");

}
}
public void processVehicleClaim(VehicleInsuranceSurveyor surveyor){
     if(surveyor.isValidClaim()){
           System.out.println("ClaimApprovalManager : Valid claim. 
Currently processing claim for approval....");
}
}
}

In the example above, we modified the ClaimApprovalManager class by adding a new processVehicleClaim( ) method to incorporate a new functionality (claim approval of vehicle insurance).This is a clear violation of the Open Closed Principle.

The ideal approach for the insurance claim example would have been to design the ClaimApprovalManager class in a way that it remains:

• Open to support more types of insurance claims.

• Closed for any modifications whenever support for a new type of claim is added.

To achieve this, let’s introduce a layer of abstraction by creating an abstract class to represent different claim validation behaviors. We will name the class InsuranceSurveyor.

InsuranceSurveyor.java

public abstract class InsuranceSurveyor{
  public abstract boolean isValidClaim();
}

HealthInsuranceSurveyor.java

public class HealthInsuranceSurveyor extends InsuranceSurveyor{

public boolean isValidClaim(){
    System.out.println("HealthInsuranceSurveyor: Validating health insurance claim...");
  
   return true;

}

VehicleInsuranceSurveyor.java

public class VehicleInsuranceSurveyor extends InsuranceSurveyor{

public boolean isValidClaim(){
    System.out.println("VehicleInsuranceSurveyor: Validating vehicle insurance claim...");
  
   return true;

}

ClaimApprovalManager.java

public class ClaimApprovalManager{

public void processHeathClaim(InsuranceSurveyor surveyor){
       if(surveyor.isValidClaim()){
           System.out.println("ClaimApprovalManager : Valid claim. 
Currently processing claim for approval....");
}
}
}

In the example above, we wrote a processClaim( ) method to accept a InsuranceSurveyor type instead of specifying a concrete type. In this way, any further addition of InsuranceSurveyor implementations will not affect the ClaimApprovalManager class. Our insurance system is now open to support more types of insurance claims, and closed for any modifications whenever a new claim type is added.

Liskov Substitution Principle

The principal defines that objects of a superclass shall be replaceable with object of its subclasses without breaking the application.

• That requires the objects of your subclasses to behave in the same way as the objects of your superclass.

• It means that we must make sure that new derived classes are extending the base classes without changing their behavior.

• It is an extension of Open Closed Principal.

• This principal helps you to implement OCP correctly.

Let’s take an example to understand it better

1. Calculate Area of Rectangle.

2. Calculate Area of Square as well

As we know, Square is a Rectangle and if we talk about inheritance it is also be read as “IS A” relationship.

So, we can create Rectangle as a base or super class and Square as sub class.

Rectangle.java

public class Rectangle {

 protected int width;
 protected int height;

public int getWidth(){
   return this.width;
 }

public int getHeight(){
   return this.height;
 }
 
public void setHeight(int height){
  this.height = height;
}

public void setWidth(int width){
  this.width = width;
}

public int getArea(){
 return this.height * this.width;
}
}

Square.java

public class Square extends Rectangle{ 
 
public void setHeight(int height){
  this.height = height;
  this.width = height;

}

public void setWidth(int width){
  this.width = width;
  this.height = width;
}
}

CalculateRectangleArea.java

public class CalculateRectangleArea{

public static void main(String[] args){
   
  Rectangle rect = new Rectangle();
  rect.setWidth(2);
  rect.setHeight(3);

  System.out.println("Area of rectangle : " + rect.getArea());

}
}

Output : 
Area of rectangle : 6

CalculateSquareArea.java

public class CalculateSquareArea{

public static void main(String[] args){
   
  Rectangle square = new Square();
  square.setWidth(2);
  square.setHeight(3);

System.out.println("Area of square: " + square.getArea());

}
}

Output : 
Area of square : 9

Now, if we change the order of setWidth and setHeight method

public class CalculateSquareArea{

public static void main(String[] args){
   
  Rectangle square = new Square();
  square.setHeight(3);
  square.setWidth(2);

System.out.println("Area of square is : " + square.getArea());

}
}

Output : 
Area of square is : 4

The output after changing the order of method is not same , so the above code violates the LSP principle i.e “ The objects of your subclasses to behave in the same way as the objects of your superclass”.

How to identify violation of LSP.

• A not implemented method in the subclass.

• Subclass function overrides the base class method to give it new meaning.

Let’s implement the LSP in the correct manner.

Shape.java

public abstract class Shape {
 abstract public int getArea();
}

Rectangle.java

public class Rectangle extends Shape{

protected int width;
 protected int height;

public int getWidth(){
   return this.width;
 }

public int getHeight(){
   return this.height;
 }
 
public void setHeight(int height){
  this.height = height;
}

public void setWidth(int width){
  this.width = width;
}

@Override
public int getArea(){
 return this.height * this.width;
}
}

Square.java

public class Square extends Shape{

int length;

public int getLength(){
   return this.length;
 }
 
public void setLength(int length){
  this.length = length;
}

@Override
public int getArea(){
 return this.length * this.length;
}
}

CalculateRectangleArea.java

public class CalculateRectangleArea{

public static void main(String[] args){
   
  Shape rect = new Rectangle();
  rect.setWidth(2);
  rect.setHeight(3);

System.out.println("Area of rectangle : " + rect.getArea());

}
}

Output : 
Area of rectangle : 6

CalculateSquareArea.java

public class CalculateSquareArea{

public static void main(String[] args){
   
  Shape square = new Square();
  square.setLength(2);

System.out.println("Area of square : " + square.getArea());

}
}

Output : 
Area of square : 4

Why we shouldn’t violate LSP.

• The use of using abstract base class is that, in future, you can write a new subclass and insert it into existing, working, tested code.

• The essence of the Open Closed Principal.

• However, when the subclasses don’t adhere properly to the behavior of the base class, you have to go through the existing code and modify the subclasses accordingly.

• This is a blatant violation of the Open Closed Principal.

Interface Segregation Principle

This principle states that “Clients should not be forced to depend on methods that they do not use”. Here, the term “Clients” refers to the implementing classes of an interface.

The Interface Segregation Principle advocates segregating a “fat interface” into smaller and highly cohesive interfaces, known as “role interfaces”. Each “role interface” declares one or more methods for a specific behavior. Thus clients, instead of implementing a “fat interface”, can implement only those “role interfaces” whose methods are relevant to them.

Interface Segregation Principle Violation (Bad Example):

Let’s consider an example, the Athlete interface is an interface with some actions of an athlete:

public interface Athlete {

void compete();

void swim();

void highJump();

void longJump();

}

We have added the method compete, but also there some extra methods like swim, highJump , and longJump.

Suppose that John Doe is a swimming athlete. By implementing the Athlete interface, we have to implement methods like highJump and longJump, which JohnDoe will never use.

public class JohnDoe implements Athlete {

@Override
    public void compete() {
        System.out.println("John Doe started competing");
    }

@Override
    public void swim() {
        System.out.println("John Doe started swimming");
    }

@Override
    public void highJump() {
    }

@Override
    public void longJump() {
    }
}

The same problem will occur for another athlete who might be a field Athlete competing in the high jump and long jump.

We will follow the interface segregation principle and refactor the original interface:

public interface Athlete {

void compete();
}

Then we will create two other interfaces — one for Jumping athletes and one for Swimming athletes.

public interface SwimmingAthlete extends Athlete {

void swim();

}

public interface JumpingAthlete extends Athlete {

void highJump();

void longJump();

}

And therefore John Doe will not have to implement actions that he is not capable of performing:

public class JohnDoe implements SwimmingAthlete {

@Override
    public void compete() {
        System.out.println("John Doe started competing");
    }

@Override
    public void swim() {
        System.out.println("John Doe started swimming");
    }

}

Summary of Interface Segregation Principle

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions.

High-level modules should not depend on low-level modules. Both should depend on abstractions.

• Entities must depend on abstractions, not on concretions.

• This principle allows for decoupling.

Here is an example of a PasswordReminder that connects to a MySQL database:

class MySQLConnection
{
    public Connection connect()
    {
        // handle the database connection
        return 'Database connection';
    }
}

class PasswordReminder
{
    private MySQLConnection dbConnection;

public void construct(MySQLConnection dbConnection)
    {
        this.dbConnection = dbConnection;
    }
}

First, the MySQLConnection is the low-level module while the PasswordReminder is high level, but according to the definition of D in SOLID, which states to Depend on abstraction, not on concretions. This snippet above violates this principle as the PasswordReminder class is being forced to depend on the MySQLConnection class.

Later, if you were to change the database engine, you would also have to edit the PasswordReminder class, and this would violate the open-close principle.

The PasswordReminder class should not care what database your application uses. To address these issues, you can code to an interface since high-level and low-level modules should depend on abstraction:

interface DBConnectionInterface
{
    public Connection connect();
}

The interface has a connect method and the MySQLConnection class implements this interface. Also, instead of directly type-hinting MySQLConnection class in the constructor of the PasswordReminder, you instead type-hint the DBConnectionInterface and no matter the type of database your application uses, the PasswordReminder class can connect to the database without any problems and open-close principle is not violated.

class MySQLConnection implements DBConnectionInterface
{
    public Connection connect()
    {
        // handle the database connection
        return 'Database connection';
    }
}

class PasswordReminder
{
    private DBConnectionInterface dbConnection;

public void construct(DBConnectionInterface dbConnection)
    {
        this.dbConnection = dbConnection;
    }
}

This code establishes that both the high-level and low-level modules depend on abstraction.

Conclusion

• The SOLID principals of OOP will lead you to better quality code which is more testable and easier to maintain.

• A key theme is avoiding tight coupling in your code.

Thanks for reading this blog. Happy Learning!!!

Modularity is a general concept which applies to the development of software in a fashion which allows individual modules to be developed, often with a standardized interface to allow modules to communicate. In fact, the kind of separation of concerns between objects in an OO language is much the same concept as for modules, except on a larger scale. Typically, partitioning a system into modules helps minimize coupling, which should lead to easier to maintain code.

Why do we need Java modularity?

The JDK before Java SE 9

1 . The JDK was huge and monolithic.

2. This resulted in increased…
 — Download Time
 — Startup Time
 — Memory Footprint

The Modular JDK

1. With Java SE 9 , the monolithic JDK was broken into 90 modules.

2. Every module is a well defined piece of functionality.
 — Similar packages and frameworks are grouped into their own modules.
 For example: Logging , Swing and Instrumentation.
 — Be aware of modules for significant API , not trivial ones.

3. Benefits Include:
 — Applications which are more scalable to small devices.
 — Improved application perfomance
 — Improved security and maintainability(for Java and your apps)

Listing the modules in Java 9

$java --list-modules

Java SE Modules

These Modules are classified into two categories:

1. Standard modules( java.* prefix for module names):
    — Part of the Java SE specification
    — For example: java.sql for database connectivity, java.xml for XML processing , and java.logging for logging

2. Modules not defined in the Java SE platform(jdk.* prefix for module names):
    — Are specific to the JDK
    — For example: jdk.jshell , jdk.policytool, jdk.httpserver

What’s Inside a Module?

• A module is a set of exported packages and concealed packages.

• public no longer means “accessible to everyone”.

• You may set up modules to encapsulate your own code.

Accessibility( JDK 9 and later)

• public to everyone

• public, but only to specific modules

• public only within a module

• protected

• <package>

• private

module-info.java

• A module is declared with a module-info.java file.

• Declarations begin with the keyword module, followed by a unique module name and a module body enclosed in braces.

• Add directives such as requires , exports to specify accessibility between modules.
   — What packages the module makes available to other modules?
   — Where a package is exported to?
   — What outside modules it’s dependent on?

module modulename {

}

Creating a Modular Project

• Name of the project

• Place module-info.java in the root directory of the packages that you want to group as a module.

• NetBeans marks this as the default package.

• One modular JAR is produced for every module.

— Modular JARs become the unit of release and reuse.

— They’re intended to contain a very specific set of functionality.

exports Module Directive

• Declares a package is accessible to code in all other modules.
   — Includes access to the package’s public classes , fields , and methods.
   — Excludes access to anything with private , protected, or package access.

• Use the exports statement judiciously.
   — You’ll never be certain how someone else wants to use your module.
   — Export only those packages that you feel are safe.
   — Modularity is about future-proofing

module A {
  exports pkgA;

}

exports…to Module Directive

• Declare a package is accessible to code in specific modules
   — Includes access to the package’s public classes, fields, and methods
   — Excludes access to anything with private, protected, or package access
   — Excludes access from any module not specified

• Use a specifies a comma-separated list to specify many modules to export to.

• This is known as a qualified export.

module A {
    exports pkgA to B, C;
}

requires Module Directive

• Declares the module is dependent on another module
   — Only exported packages are readable by the requiring module.
   — Packages that aren’t exported aren’t readable.
   — Anything nonpublic is not readable, even from exported packages.

• Classes within the current module may require a class, instance, or method written in another module.

module B {
    requires A;
}

Example

package pkgA;

public class ClassA{
  public int yearPublic = 2001;
  protected int yearProtected = 2002;
  int yearPackage = 2003;
  private int yearPrivate = 2004;
}

module A {
    exports pkgA;
}

module B {
   requires A;
}

package pkgB;

import pkgA.ClassA; 

public class NewMain{
  public static void main(String[] args){
    ClassA test = new ClassA();
     System.out.println(test.yearPublic); //Yes
     System.out.println(test.yearProtected); //No
     System.out.println(test.yearPackage); //No
     System.out.println(test.yearPrivate); //No
}}

requires transitive Module Directive

• Transitivity allows readability up the requirement chain.

• Anything requiring the current module has access to:
   — Packages exported by the current module
   — Packages exported by anything the current module requires transitively

• Known as “implied readability”

Example

module C{
  exports pkgC;
}

package pkgC;

public class ClassC {
   public static String transitiveVar;
   transitiveVar = "From C";
}

module A{
  requires transitive C;
  exports pkgA to B;
}

module B {
   requires A;
}

package pkgB;

import pkgA.ClassA;
import pkgC.ClassC;

public class NewMain{
  public static void main(String[] args){
    ClassA test = new ClassA();
    System.out.println(test.yearPublic);
    System.out.println(ClassC.transitiveVar);
}
}

The Base Module java.base

• The base module exports all of the platform’s core packages.

• Every module depends on java.base.

• java.base doesn’t depend on any other modules.

• The java.base module reference is implicitly included in all other modules.

// module-info.java

module java.base{
  exports java.lang;
  exports java.io;
  exports java.net;
  exports java.util;
}

module A{
  requires java.base;   // implied
  requires java.logging;
  requires transitive C;
  exports pkgA to B;
}

Summary of Keywords

Keywords and Syntax with Description

1. export <package>
    — Declares which package is eligible to be read.

2. export <package> to <module>
    — Declares which package is eligible to be read by a specific module

3. requires <module>
    — Specifies another module to read from

4. requires transitive <module>
    — Specifies another module to read from. The relationship is transitive where indirect. access is given to modules requiring the current module.

• These are restricted keywords

• Their creation won’t break existing code.

• They’re only available in the context of the module-info class.

If you have questions or comments about this let me know in the comments below. You can view the full code here:

GitHub - zsanjay/Java-9-Modules
Contribute to zsanjay/Java-9-Modules development by creating an account on GitHub.github.com

Thanks for reading this blog. Happy Learning!!!

There has been an on-going debate in the world of developers, and that is which is better: JavaScript Promises or RxJS Observables? Each one can bring so much value to different projects. It’s a good idea to have a good understanding of each and how it could benefit a project. But before we start looking at some comparisons, let’s do a quick overview of what each one is.

What is a Promise

A promise is an object that encapsulates the result of an asynchronous operation.

Each promise has state, which can have one of the following values:

• Pending

• Fulfilled with a value

• Rejected for a reason

The just created promise is in a pending state. The promise maintains the pending state as long as the asynchronous operation behind is in progress.

Then, depending on how the asynchronous operation completes, the promise state changes to either:

A) fulfilled (when the async operation completed successfully)

B) or rejected (when then async operation failed).

In JavaScript, you can create a promise object using a special constructor

const promise = new Promise((resolve, reject) => {
  // Async operation logic here....
  if (asyncOperationSuccess) {
    resolve(value); // async operation successful
  } else {
    reject(error);  // async operation error
  }
});

What is Observable

Observable are just that — things you wish to observe and take action on. Angular uses the Observer pattern which simply means — Observable objects are registered, and other objects observe (in Angular using the subscribe method) them and take action when the observable object is acted on in some way.

To use observable, Angular uses a third-party library called Reactive Extensions (RxJS).

Let’s take a look how can we use Observable in our Angular application.

import { Observable } from 'rxjs/Observable';

// Create simple observable that emits three values 
   const myObservable = Observable.of(1, 2, 3); 

// Create observer object 
   const myObserver = { 
next: x => console.log('Observer got a next value: ' + x),             error: err => console.error('Observer got an error: ' + err),          complete: () => console.log('Observer got a complete notification')
 };         

// Execute with the observer object    myObservable.subscribe(myObserver);  

  // Logs:   
 // Observer got a next value: 1   
 // Observer got a next value: 2    
// Observer got a next value: 3    
// Observer got a complete notification

Here are the main differences which is covered in this blog post:

Eager vs Lazy

Promise is eager , hence execute immediately, and just once. The computation of the result is initiated when the promise is created. There is no way to restart work. All then clauses (subscriptions) share the same computation.

const welcomePromise = new Promise(resolve => {  
console.log("In Promise executor fn"); 
 
 resolve("Welcome!");
}); 

console.log("Before calling the then method");
 
welcomePromise.then(console.log); 

// console output:
// In Promise executor fn
// Before calling the then method
// Welcome!

Observables is lazy , since not executed until a consumer subscribes. The subscribe() executes the defined behavior once, and it can be called again. Each subscription has its own computation. Resubscription causes recomputation of values.

import { Observable } from "rxjs";

const welcomeObservable$ = new Observable(observer => {   console.log("In Observable producer fn"); 

  observer.next("Welcome!"); 
  observer.complete();

}); 
console.log("Before calling the subscribe method"); welcomeObservable$.subscribe(console.log); 

// console output:
// Before calling the subscribe method
// In Observable producer fn
// Welcome!

Async vs Sync

Even if immediately resolved, the Promise is always asynchronous.

const welcomePromise = new Promise(resolve => {  
console.log("In Promise executor fn"); 
 
 resolve("Welcome!");
});

console.log("Before calling the then method");
 
welcomePromise.then(console.log);

console.log("After calling the then method"); 

// console output:
// In Promise executor fn
// Before calling the then method
// After calling the then method
// Welcome!

The Observables may be synchronous or asynchronous

Synchronous

import { Observable } from "rxjs";

const welcomeObservable = new Observable(observer => {   console.log("In Observable producer fn");

observer.next("Welcome!"); 
  observer.complete();

}); 
console.log("Before calling the subscribe method"); 

welcomeObservable.subscribe(console.log);

// console output:
// Before calling the subscribe method
// In Observable producer fn
// Welcome!

Asynchronous

import { Observable } from "rxjs";

const asyncObservable = new Observable(observer => {   console.log("In Observable producer fn");

setTimeout(() => {

observer.next("Async!"); 
  observer.complete();

} , 1000)

}); 
console.log("Before calling the subscribe method");

asyncObservable.subscribe(console.log);

console.log("After calling the subscribe method");

// console output:
// Before calling the subscribe method
// In Observable producer fn
// After calling the subscribe method
// Async!

Single vs Multiple values

Promises are most commonly used to handle HTTP requests. In this model, you make a request and then wait for a single response. You can be sure that there won’t be multiple responses to the same request.

const numberPromise = new Promise((resolve) => { 
resolve(5);
});

 numberPromise.then(value => console.log(value));
// will simply print 5

Promise is always resolved with the first value passed to the resolve function and ignores further calls to it:

const numberPromise = new Promise((resolve) => { 
resolve(5);
resolve(10);
});

numberPromise.then(value => console.log(value));
// still prints only 5

Observables allow you to resolve (or, as we say, “emit”) multiple values.

const numberObservable = new Observable((observer) => {    observer.next(5);   
observer.next(10);
});

numberObservable.subscribe(value => console.log(value));
// prints 5 and 10

Cancellation

Observable subscriptions are cancellable. Unsubscribing removes the listener from receiving further values, and notifies the subscriber function to cancel work.

const subscription = observable.subscribe(() => {

// observer handles notifications

});

subscription.unsubscribe();

Promises are not cancellable.

Conclusions

There are many differences between Observable and Promise. But the main differences are :

• The Observable is lazy whereas the Promise is eager

• The Promise is always asynchronous, while the Observable can be either asynchronous or synchronous

• The Promise can emit only a single value, whereas the Observable can emit single or multiple values.

• The Observable subscriptions are cancellable whereas Promises are not cancellable.

Thank you, for reading this post , hope you liked it please give an applause.