DEV Community: Khafido Ilzam

Singleton Pattern

Khafido Ilzam — Mon, 11 May 2026 07:38:49 +0000

In the world of software architecture, we often encounter objects that should only exist once. Whether it’s a configuration manager, a print spooler, or a database connection pool, having multiple instances floating around can lead to unpredictable behavior, resource exhaustion, or data inconsistency.

This is where the Singleton Pattern comes in. As a senior developer, I view the Singleton as a "utility" pattern—it’s incredibly powerful when used correctly, but it can be a double-edged sword if misapplied.

What is a Singleton?

At its core, the Singleton is a creational design pattern that ensures a class has only one instance while providing a global point of access to that instance.

Think of it like the pilot of a commercial airplane. There might be hundreds of passengers and several flight attendants, but there is only one person (or one specific role) in charge of the flight deck at any given time. You wouldn’t want two different pilots trying to steer the plane in two different directions!

Anatomy of a Singleton

To create a Singleton, a class must follow three strict rules:

Private Constructor: This prevents other classes from using the new keyword to create instances.
Static Field: A private variable within the class to hold the single instance.
Static Method: A public method (usually called getInstance()) that returns the instance, creating it first if it doesn't already exist.

Real-World Example: The Global Logger

Logging is the quintessential use case for a Singleton. You want every part of your application—from the login logic to the payment processing—to send messages to the same log file or console.

Here is how we implement a robust, thread-safe (in concept) Logger in TypeScript:

class Logger {
    private static instance: Logger;
    private logs: string[] = [];

    // 1. Private constructor prevents 'new Logger()'
    private constructor() {
        console.log("Logger Initialized.");
    }

    // 2. The static method that controls access
    public static getInstance(): Logger {
        if (!Logger.instance) {
            Logger.instance = new Logger();
        }
        return Logger.instance;
    }

    // A simple business method
    public log(message: string): void {
        const timestamp = new Date().toISOString();
        const fullMessage = `[${timestamp}] ${message}`;
        this.logs.push(fullMessage);
        console.log(fullMessage);
    }

    public getLogCount(): number {
        return this.logs.length;
    }
}

// --- Usage ---

// const logger = new Logger(); // Error: Constructor of class 'Logger' is private.

const loggerA = Logger.getInstance();
const loggerB = Logger.getInstance();

loggerA.log("User logged in.");
loggerB.log("Order processed.");

console.log(loggerA === loggerB); // true - both variables point to the exact same memory

The Pros: Why We Use It

Controlled Access: You have total control over how and when the instance is accessed.
Reduced Memory Footprint: Instead of creating 100 objects for 100 different modules, you keep just one in memory.
Lazy Initialization: The instance is only created when it’s actually needed. If your app never calls getInstance(), the object is never born.
Global State Management: It provides a synchronized place to store data that needs to be shared across the entire system.

The Trade-offs: The "Hidden" Costs

Every senior dev will tell you: Singletons are controversial. Here’s why:

The "Global Variable" Problem: Singletons are essentially glorified global variables. They can make code harder to debug because any part of the app can change the state of the Singleton at any time.
Testing Hurdles: Since Singletons persist state between tests, they can cause "leaky" tests. If Test A changes the Logger's state, Test B might fail unexpectedly because it’s still using that same modified instance.
Violation of Single Responsibility: The class is responsible for two things: its actual job (e.g., logging) and managing its own lifecycle/uniqueness.
Tight Coupling: Classes that use the Singleton become tightly coupled to that specific implementation, making it harder to swap out for a different version later.

Final Verdict

The Singleton Pattern is a tool, not a rule.

Use it when you have a shared resource that absolutely must be unique to maintain consistency (like a file system driver or a central state store).

Avoid it if you’re just using it as a convenient way to access variables from anywhere. In modern development, we often prefer Dependency Injection to pass instances around, which gives us the "one instance" benefit without the testing headaches of a hard-coded Singleton.

Result Pattern

Khafido Ilzam — Mon, 11 May 2026 06:54:46 +0000

In modern software engineering, how we handle "failure" defines the resilience and readability of our systems. For years, the default mechanism has been Exceptions. However, as systems grow in complexity, many senior architects are shifting toward the Result Pattern.

The Result Pattern treats errors not as "exceptional" interruptions to the program flow, but as first-class data. It forces the developer to acknowledge the possibility of failure at compile-time, leading to safer, more predictable codebases.

What is the Result Pattern?

At its core, the Result Pattern is a design pattern that wraps the output of a function in a container. This container represents one of two states:

Success: Contains the expected data.
Failure: Contains an error object or message explaining what went wrong.

Instead of a function potentially "exploding" with a thrown exception, it returns a value that says, "I might have worked, or I might have failed—here is the result for you to inspect."

The Core Advantages

1. Explicit Intent

With standard exceptions, a function signature like getUser(id: string): User is a lie. It doesn't always return a User; it might throw a 404 or a DatabaseError. The Result Pattern makes this honest: getUser(id: string): Result<User, Error>.

2. Type Safety & Exhaustive Checking

In languages like TypeScript, the compiler can force you to check if the result is a success before accessing the data. This eliminates the "forgot to catch" bugs that haunt production logs.

3. Better Control Flow

Exceptions are essentially goto statements in disguise—they jump across the call stack, making logic hard to follow. Results keep the execution local and linear.

Trade-offs and Considerations

No pattern is a silver bullet. Here is the "senior" perspective on the downsides:

Boilerplate: You will find yourself writing more if (result.isFailure) checks. While this is safer, it can feel verbose compared to a single try-catch block wrapping ten lines of code.
Learning Curve: Team members used to traditional OOP might find the functional nature of Result objects (and the lack of "bubbling" errors) counterintuitive at first.
Performance: In highly high-frequency loops, creating a new object for every single operation (even successful ones) can add a negligible but measurable overhead compared to raw values.

Implementation in TypeScript

Here is a robust, production-ready implementation of the Result Pattern.

type Success<T> = {
  readonly isSuccess: true;
  readonly isFailure: false;
  readonly value: T;
};

type Failure<E> = {
  readonly isSuccess: false;
  readonly isFailure: true;
  readonly error: E;
};

export type Result<T, E = Error> = Success<T> | Failure<E>;

/**
 * Functional helpers to create Result instances
 */
export const ok = <T>(value: T): Success<T> => ({
  isSuccess: true,
  isFailure: false,
  value,
});

export const fail = <E>(error: E): Failure<E> => ({
  isSuccess: false,
  isFailure: true,
  error,
});

Real-World Usage Example

Let’s look at a service that fetches a user. Notice how the type system protects us from accessing result.value until we verify success.

interface User {
  id: string;
  username: string;
}

async function findUser(id: string): Promise<Result<User, string>> {
  const user = await db.users.findOne(id);

  if (!user) {
    return fail("User not found in database.");
  }

  return ok(user);
}

// Consuming the Result
async function userController(userId: string) {
  const result = await findUser(userId);

  if (result.isFailure) {
    // TypeScript knows 'error' exists here, but 'value' does not
    return console.error(`Error: ${result.error}`);
  }

  // TypeScript now safely allows access to 'value'
  console.log(`Hello, ${result.value.username}`);
}

When to use it?

Use the Result Pattern when...	Use Exceptions when...
The error is expected (e.g., validation, user not found).	The error is catastrophic (e.g., out of memory, lost DB connection).
You are writing Domain Logic.	You are in the Infrastructure layer.
You want to ensure the caller handles the error.	You want the error to bubble up to a global handler.

Final Verdict

The Result Pattern is about moving from defensive programming (hoping nothing breaks) to offensive programming (designing for failure). By making errors a part of your type system, you create a codebase that is self-documenting and significantly more robust. For any serious TypeScript project, it is a pattern worth adopting.

Execution Context in JavaScript

Khafido Ilzam — Thu, 05 Mar 2026 03:47:24 +0000

Execution context is one of the most fundamental concepts in JavaScript — it's the environment in which JavaScript code is evaluated and executed.

What Is an Execution Context?

Every time JavaScript runs code, it creates an execution context — a wrapper that holds information about the current code being run: what variables are available, what this refers to, and the outer environment it has access to.

There are three types:
Global Execution Context (GEC) — created once when the script first runs
Function Execution Context (FEC) — created every time a function is invoked
Eval Execution Context — created inside eval() calls (rarely used, mostly avoided)

Every execution context goes through two distinct phases:

Phase 1: Creation Phase (Memory / Hoisting Phase)
Before any code runs, the JavaScript engine scans the code and:

Creates the Variable Environment (stores var declarations, initialized to undefined)
Creates the Lexical Environment (stores let/const declarations in the Temporal Dead Zone)
Stores function declarations in memory in their entirety (fully hoisted)
Determines the value of this
Creates a reference to the outer environment (the scope chain)

This is why hoisting happens — variables and functions are placed into memory before code executes line by line.

Phase 2: Execution Phase
The engine runs the code line by line, assigns values, calls functions (which create new FECs), and so on.

The Call Stack

To keep track of all the contexts, including global and functional, the JavaScript engine uses a call stack. A call stack is also known as an 'Execution Context Stack', 'Runtime Stack', or 'Machine Stack'.

JavaScript is single-threaded, so it processes one execution context at a time using a call stack (a LIFO data structure). The GEC sits at the bottom; each function call pushes a new FEC on top; when a function returns, its context is popped off.

Implement OOP using TypeScript

Khafido Ilzam — Mon, 08 Dec 2025 09:02:34 +0000

Let’s learn how to implement all OOP principles in TypeScript.

Classes & Objects
Encapsulation
Abstraction & Interface
Inheritance
Polymorphism

Class and Object

A class is a blueprint, and objects are instances of the class.

Encapsulation

Encapsulation = hide internal data, expose only what is needed.
Use private, protected, and public.

Abstraction

Abstraction = hide complexity and expose only what the user needs.
Use abstract classes or interfaces. Interfaces define shape, and classes can implement them.

You cannot create an object from it, but it can have abstract methods (no body) and normal methods. The child must implement (override) the abstract method.

A class can implement multiple interfaces. But a class can extend only one class

Interfaces do NOT contain implementation. Classes must provide the implementation

Inheritance

A class can inherit methods or data from another class.

Polymorphism

Polymorphism = same method name, different behavior.

Full Example Code:
https://snipsave.com/view-snippet?user=khafidoilzam&snippet_id=Fp13KgLloQpTnToegf

REST vs RESTful API

Khafido Ilzam — Tue, 18 Nov 2025 03:48:57 +0000

The distinction between "REST API" and "RESTful API" lies in their adherence to the principles of Representational State Transfer (REST) architectural style.

REST API: This term generally refers to any API that utilizes HTTP and incorporates some, but not necessarily all, of the principles of REST. It may use clear URLs for resources and standard HTTP methods, such as GET and POST, but it may not strictly adhere to all the constraints defined by the REST architectural style.

RESTful API: This term specifically denotes an API that fully conforms to all the constraints and principles of the REST architectural style.

Key principles of REST:

Client-Server: Separation of concerns between the client and server.
Stateless: Each request from the client to the server must contain all the information needed to understand the request, and the server must not store any client context between requests.
Cacheable: Responses must explicitly or implicitly indicate whether they are cacheable or non-cacheable to prevent clients from reusing stale or inappropriate data.
Uniform Interface: A standardized way for clients to interact with resources, including resource identification, resource manipulation through representations, self-descriptive messages, and Hypermedia as the Engine of Application State (HATEOAS).
Layered System: An architecture composed of hierarchical layers, where each layer can communicate only with its immediate neighbors.
Code on Demand (optional): Servers can temporarily extend or customize client functionality by transferring executable code.

In essence, while all RESTful APIs are a type of REST API, not all REST APIs are truly RESTful. A RESTful API is a specific implementation that rigorously adheres to the full set of REST constraints, ensuring greater consistency, scalability, and maintainability for large-scale web applications.

JavaScript Memory Behavior

Khafido Ilzam — Mon, 17 Nov 2025 08:56:16 +0000

JavaScript uses two main memory spaces to store variables:

Call Stack → where execution happens, stores variable references (pointers)
Memory Heap → where objects, arrays, and functions live

What is the Stack?

Stack is a data structure that obeys the Last In First Out (LIFO) principle. This implies that the last item to enter the stack goes out first.

Imagine a pile of books stacked up on a shelf. The last book ends up being the first to be removed. Data stored inside the stack can still be accessed easily.

What is the Heap?

Reference data are stored inside the heap. When reference data is created, the variable of the data is placed on the stack, but the actual value is placed on the heap.

In JavaScript, different data types have different behaviors and locations in memory. So to reduce the chances of having bugs in your code, you need to understand the concept of mutability and immutability in JavaScript.

But the real difference between var, let, and const is how they are handled inside the Call Stack during creation and access, especially during hoisting.

var, let, and const control whether you can reassign the variable. Mutability controls whether the value itself can be changed. These are two different things.

Mutability

Mutability refers to data types that can be accessed and changed after they've been created and stored in memory. If a data type is mutable, that means that you can change it. Mutability allows you to modify existing values without creating new ones.

const staff = {
    name: "Strengthened",
    age: 43,
    hobbies: ["reading", "Swimming"]
}

const staff2 = staff;
staff2.age = 53;
console.log(staff.age); // 53
console.log(staff2.age); // 53

Reference data does not copy values, but rather pointers.

Changing the age of staff2 updates the age of the staff object. Now you know it is because both point to the same object.

How to Clone Object Properly?

Immutability

Immutability refers to data types that you can't change after creating them, but that you can still access in memory. A value is immutable when altering it is impossible. Primitive data types are immutable, as we discussed above.

let student1 = "Halina";
let student2 = student1;
student1 = "Brookes"

console.log(student1); // Brookes
console.log(student2); // Halina

Source: https://www.freecodecamp.org/news/mutability-vs-immutability-in-javascript/

How to Clone Object Properly?

Khafido Ilzam — Mon, 17 Nov 2025 08:54:21 +0000

You can clone the properties of an object using the Object. assign() method and the spread operator. With these, you can change the properties of the cloned object without changing the properties of the object from which it was cloned.

How the `Object.assign()` method Works

The object.assign() method copies properties from an object (the source) into another object (the target) and returns the modified target object.

Here's the syntax:
Object.assign(target, source)

const staff = {
    name: "Strengthened",
    age: 43,
    hobbies: ["reading", "Swimming"]
}

const staff2 = Object.assign({}, staff);
staff2.age = 53;

console.log(staff.age); // 43
console.log(staff2.age); // 53

How the Spread Operator Works

Here's the syntax of the spread operator:
const newObj = {...obj}

Using the spread operator is quite simple. You need to place three dots ... before the name of the object whose properties you intend to clone:

const staff = {
    name: "Strengthened",
    age: 43,
    hobbies: ["reading", "Swimming"]
}

const staff2 = { ...staff };
staff2.age = 53;

console.log(staff.age); // 43
console.log(staff2.age); // 53

JavaScript Data Types

Khafido Ilzam — Mon, 17 Nov 2025 06:43:56 +0000

Variables hold values, and every value has a specific data type that defines the kind of information it holds. These data types are broadly categorized into two groups: Primitive Data Types and Non-Primitive Data Types.

Data types are categorized into Primitive and Non-Primitive (Reference) types in JavaScript.

Primitive

When you assign a primitive value:

It is stored directly in memory
Copying the value creates a new independent value

They are immutable, meaning you cannot change the value itself—only replace it.

JavaScript has 7 primitive types:

1. Number

All numbers (integer or floating point).

let x = 10;
let y = 11.5;

2. String

Text data.

let name = "Hello World!";

3. Boolean

True or False.

let isOnline = true;

4. Null

Intentional empty value.

let data = null;

5. Undefined

A variable declared but not assigned a value.

let a; // undefined

6. Symbol

Symbol data type is used to create objects that will always be unique. These objects can be created using Symbol constructor.

let sym = Symbol("Hello")
console.log(typeof(sym)); // Symbol
console.log(sym); // Hello

7. BigInt

For very large integers beyond Number’s limit.

let big = 12345678901234567890n;

Non-Primitive (Reference)

This data type is mutable, which means you can change/modify it. Allows you to modify existing values without creating new ones.

Non-primitive values are stored by reference. When you assign an object to another variable, JavaScript copies the reference, not the value.

These are objects—more complex data structures. The main non-primitive types:

Object
Array (actually a special type of object)
Function (also an object)
Date
Map, Set, etc. (still objects)

let obj1 = { age: 27 };
let obj2 = obj1;

obj2.age = 30;

console.log(obj1.age); // 30 (obj1 also changed)

Why? Because both variables point to the same memory address.

JavaScript Declaration Variable

Khafido Ilzam — Mon, 17 Nov 2025 05:35:02 +0000

In JavaScript, variables are declared using one of three keywords: var, let, or const. These keywords differ in their scope, hoisting behavior, and re-assignment rules.

1. `var` – the old way (avoid using it)

Function-scoped → only respects function boundaries.
Can be re-declared.
Can be updated.
Hoisted → moved to the top of the scope, but initialized as undefined.

It can cause weird bugs because it ignores block scope.

var x = 1;
if (true) {
  var x = 2;  // same variable!
}
console.log(x); // 2

2. `let` – recommended for variables that change

Block-scoped → respects { } blocks.
Can be updated, but not re-declared in the same scope.
Also hoisted, but not usable before declared (“temporal dead zone”).

Use let when the value needs to change.

let count = 1;
count = 2; // OK
// let count = 3; // ❌ Error (same scope)

3. `const` – recommended default

Block-scoped
Cannot be updated or re-declared
Best for values that should not change

Objects and arrays can still be modified, but the variable reference cannot change.

const PI = 3.14;
// PI = 4; // ❌ Error

const user = { name: "Khaf" };
user.name = "Fido"; // ✔ OK
// user = {} // ❌ Not allowed

Summary

Feature	var	let	const
Scope	Function	Block	Block
Re-declare	✔ Yes	❌ No	❌ No
Update value	✔ Yes	✔ Yes	❌ No
Hoisted	Yes (weird)	Yes (safer)	Yes (safer)
When to use	Avoid	Value changes	Value doesn't change

How do Interfaces connect with OOP and SOLID?

Khafido Ilzam — Wed, 12 Nov 2025 08:42:30 +0000

First, what’s an Interface again?

An interface defines a contract — a list of methods or properties that a class must implement.
It tells you what should exist, but not how it works.

Now, let’s see how interfaces relate to the 4 pillars of OOP.

Abstraction

Interfaces are a tool to achieve abstraction.

Abstraction means showing only what’s necessary and hiding the details.
An interface only describes behavior (what methods exist) — not how they’re done. So, interface = pure abstraction layer.

Encapsulation

Encapsulation is about hiding internal data and logic, while interfaces define public behavior.

The interface tells others what’s accessible publicly (the methods).
The actual implementation inside the class (private variables, logic) remains encapsulated. The interface exposes what can be done, not how it’s done. Encapsulation keeps the hidden details safe inside.

Inheritance

While inheritance lets a class inherit code and behavior,
Interfaces let a class promise to follow a certain shape or behavior.
You can also extend interfaces — similar to class inheritance.

This allows structured hierarchies without code duplication — similar to inheritance but purely behavioral.

Polymorphism

Interfaces are the foundation of polymorphism.

Polymorphism allows you to treat different objects in the same way if they share a common interface.

Interfaces are the backbone of Abstraction and Polymorphism,
while also supporting Encapsulation and flexible Inheritance.

They define how objects should look — not how they work.

Interfaces are at the core of two SOLID principles (ISP & DSP):

I — Interface Segregation

Clients should not be forced to depend on interfaces they do not use.
In simple terms, don’t make a big “God interface” that includes methods unrelated to certain classes.
Instead, split it into smaller, more specific interfaces.

OOP Connection: Interfaces define abstraction.
ISP ensures that abstraction stays clean and specific.
Each interface represents a single responsibility for behavior.

D - Dependency Inversion Principle (DIP)

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

Don’t make your main logic depend on specific classes — depend on interfaces instead.

This allows you to swap implementations easily (for example, switching from MySQL to MongoDB) without breaking your main business logic.

OOP Connection: Interface provides abstraction between classes.
DIP enforces that both high-level and low-level modules depend on that abstraction, not on each other directly.
Promotes loose coupling, flexibility, and testability.

What is an Interface?

Khafido Ilzam — Wed, 12 Nov 2025 07:57:32 +0000

In simple terms, an interface is like a contract or blueprint that says,

“If you want to be part of this system, you must have these methods.”

It doesn’t contain any actual code, only the rules — the names of functions or properties that a class must have.

An interface is a contract that defines what methods or properties a class must have,
but leaves the implementation details to the class itself.

Example (TypeScript or Java-style syntax):

interface PaymentProcessor {
  processPayment(amount: number): void;
}

Now, any class that implements this interface must define that method:

class CreditCardPayment implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via credit card`);
  }
}

class PayPalPayment implements PaymentProcessor {
  processPayment(amount: number) {
    console.log(`Processing $${amount} via PayPal`);
  }
}

SOLID and its relationship with OOP

Khafido Ilzam — Wed, 12 Nov 2025 07:38:25 +0000

SOLID is like the “5 rules” to write good OOP code. Not just working code, but clean and maintainable code.

S — Single Responsibility Principle (SRP)

A class should have only one reason to change. Each class, module, or function should handle only one responsibility. When a class has multiple reasons to change, it becomes fragile and tightly coupled.

O — Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification. You should be able to add new functionality without changing existing tested code.

L — Liskov Substitution Principle (LSP)

Objects of a subclass should be replaceable with objects of the superclass without altering the correctness of the program. A child class should fully replace its parent without breaking anything.

I — Interface Segregation Principle (ISP)

Don’t force classes to depend on things they don’t use. It’s better to have many small, specific interfaces than one large, general one.

D — Dependency Inversion Principle (DIP)

High-level modules (business logic) should not depend on low-level modules (e.g., database drivers).
Both should depend on abstractions (interfaces or abstract classes).

SOLID Principle	What it Means	Relation to OOP
S — Single Responsibility	One class = one job only.	Keeps objects focused and simple (Encapsulation).
O — Open/Closed	Open for extension, closed for modification.	Add new features without changing old code (Inheritance & Polymorphism).
L — Liskov Substitution	A child class should fully replace its parent without breaking anything.	Keeps Inheritance safe and logical.
I — Interface Segregation	Specific interfaces rather than one large, general one.	Encourages cleaner Abstraction.
D — Dependency Inversion	Depend on abstractions, not concrete implementations.	Promotes flexible and testable design (Abstraction & Encapsulation).

SOLID is how you design those objects so the system stays clean, scalable, and easy to change.

SRP keeps classes focused and easy to reason about. OCP lets your system grow without breaking what works. LSP ensures inheritance is trustworthy and substitutable. ISP keeps interfaces lean so implementors aren't burdened. DIP decouples layers so you can swap implementations freely — making your code testable, flexible, and future-proof.

DEV Community: Khafido Ilzam

Singleton Pattern

What is a Singleton?

Anatomy of a Singleton

Real-World Example: The Global Logger

The Pros: Why We Use It

The Trade-offs: The "Hidden" Costs

Final Verdict

Result Pattern

What is the Result Pattern?

The Core Advantages

1. Explicit Intent

2. Type Safety & Exhaustive Checking

3. Better Control Flow

Trade-offs and Considerations

Implementation in TypeScript

Real-World Usage Example

When to use it?

Final Verdict

Execution Context in JavaScript

What Is an Execution Context?

The Call Stack

Implement OOP using TypeScript

Class and Object

Encapsulation

Abstraction

Inheritance

Polymorphism

REST vs RESTful API

Key principles of REST:

JavaScript Memory Behavior

What is the Stack?

What is the Heap?

Mutability

Immutability

How to Clone Object Properly?

How the Object.assign() method Works

How the Spread Operator Works

JavaScript Data Types

Primitive

1. Number

2. String

3. Boolean

4. Null

5. Undefined

6. Symbol

7. BigInt

Non-Primitive (Reference)

JavaScript Declaration Variable

1. var – the old way (avoid using it)

2. let – recommended for variables that change

3. const – recommended default

Summary

How do Interfaces connect with OOP and SOLID?

First, what’s an Interface again?

Abstraction

Encapsulation

Inheritance

Polymorphism

Interfaces are at the core of two SOLID principles (ISP & DSP):

I — Interface Segregation

D - Dependency Inversion Principle (DIP)

What is an Interface?

SOLID and its relationship with OOP

S — Single Responsibility Principle (SRP)

O — Open/Closed Principle (OCP)

L — Liskov Substitution Principle (LSP)

I — Interface Segregation Principle (ISP)

D — Dependency Inversion Principle (DIP)

How the `Object.assign()` method Works

1. `var` – the old way (avoid using it)

2. `let` – recommended for variables that change

3. `const` – recommended default