Creational design patterns govern how classes and objects are created in a systematic and scalable way. They provide blueprints for creating objects so you don't repeat code. They also keep your system consistent and makes your app easy to extend.

There are five major Creational Design patterns:

1. Singleton: Ensures a class has only one instance and provides a global point of access to it.

2. Factory Method: Provides an interface for creating objects but lets subclasses decide which class to instantiate.

3. Abstract Factory: Creates families of related objects without specifying their concrete classes.

4. Builder: Allows you to construct complex objects step by step, separating construction from representation.

5. Prototype: Creates new objects by cloning existing ones, rather than creating from scratch.

Each of these patterns solves specific problems around object creation, depending on the complexity and scale of your application.

In this tutorial, I'll explain what Creational Design Patterns are and how they work. We'll focus on two primary patterns: the Factory and Abstract Factory patterns.

Many people mix these two up, so here we'll explore:

1. How each pattern works

2. Practical examples in Flutter

3. Applications, best practices, and usage

By the end, you'll understand when to use Factory, when to switch to Abstract Factory, and how to structure your Flutter apps for scalability and maintainability.

Table of Contents

1. How the Factory Pattern Works in Flutter

   • Step 1: Define the Product and Abstract Creator

   • Step 2: Implement Concrete Products

   • Step 3: Create the Factory

   • Step 4: Use the Factory

2. Factory Pattern for Security Checks

3. How the Abstract Factory Pattern Works in Flutter

   • Step 1: Define Abstract Product Interfaces

   • Step 2: Implement Platform-Specific Products

   • Step 3: Define the Abstract Factory Interface

   • Step 4: Implement Platform Specific Factories

   • Step 5: Client Code Using Abstract Factory

4. Conclusion

Prerequisites

Before diving into this tutorial, you should have:

• a basic understanding of the Dart programming language

• familiarity with Object-Oriented Programming (OOP) concepts (particularly classes, inheritance, and abstract classes)

• basic knowledge of Flutter development (helpful but not required)

• an understanding of interfaces and polymorphism

• and experience creating and instantiating classes in Dart.

How the Factory Pattern Works in Flutter

You'll typically use the Factory Pattern when you want to manage data sets that might be related, but only for a single type of object.

Let's say you want to manage themes for Android and iOS. Using the Factory Pattern allows you to encapsulate object creation and keep your app modular. We'll build this step by step so you can see how the pattern works.

Step 1: Define the Product and Abstract Creator

class AppTheme {
  String? data;
  AppTheme({this.data});
}

abstract class ApplicationThemeData {
  Future<AppTheme> getApplicationTheme();
}

Here, AppTheme is a simple data class that holds theme information. This represents the product our factory will create. ApplicationThemeData serves as an abstract base class. This abstraction is crucial because it defines a contract that all concrete theme implementations must follow.

By requiring a getApplicationTheme() method, we ensure consistency across different platforms.

Step 2: Implement Concrete Products

Now we create platform-specific implementations that provide actual theme data.

class AndroidAppTheme extends ApplicationThemeData {
  @override
  Future<AppTheme> getApplicationTheme() async {
    return AppTheme(data: "Here is android theme");
  }
}

class IOSThemeData extends ApplicationThemeData {
  @override
  Future<AppTheme> getApplicationTheme() async {
    return AppTheme(data: "This is IOS theme data");
  }
}

The concrete implementations, AndroidAppTheme and IOSThemeData, extend the abstract class and provide platform-specific theme data. Each returns an AppTheme object with content tailored to its respective platform.

Step 3: Create the Factory

The factory encapsulates the object creation logic, so client code doesn't need to know which specific theme class it's working with.

class ThemeFactory {
  ThemeFactory({required this.theme});
  ApplicationThemeData theme;

  loadTheme() async {
    return await theme.getApplicationTheme();
  }
}

ThemeFactory acts as the factory itself. It accepts any ApplicationThemeData implementation and provides a unified loadTheme() method. This encapsulates the object creation logic cleanly.

Step 4: Use the Factory

Finally, we use the factory in our application code.

ThemeFactory(
  theme: Platform.isAndroid ? AndroidAppTheme() : IOSThemeData()
).loadTheme();

Here, you choose a theme (Android or iOS) and get the corresponding AppTheme. This approach is simple and effective when you only care about one functionality, like loading a theme.

The beauty of this pattern is that the client code remains clean and doesn't need to change if you add new platforms later.

Factory Pattern for Security Checks

Another excellent use case for the Factory Pattern is when implementing security checks during your application bootstrap.

For instance, Android and iOS require different logic for internal security. Android might check for developer mode or rooted devices, while iOS checks for jailbroken devices. This scenario is a perfect example of when to apply the Factory Pattern, as it allows you to encapsulate platform-specific security logic cleanly and maintainably. Let's implement this step by step.

Step 1: Define Security Check Result and Abstract Checker

First, we need a standardized way to communicate security check outcomes and a contract for performing security checks.

// Base security check result class
class SecurityCheckResult {
  final bool isSecure;
  final String message;

  SecurityCheckResult({required this.isSecure, required this.message});
}

// Abstract security checker
abstract class SecurityChecker {
  Future<SecurityCheckResult> performSecurityCheck();
}

The SecurityCheckResult class provides a standardized way to communicate security check outcomes across platforms.

It contains a boolean flag indicating security status and a descriptive message for the user. The abstract SecurityChecker class defines the contract that all platform-specific security implementations must follow.

This ensures that, regardless of the platform, we can always call performSecurityCheck() and receive a consistent result type.

Step 2: Implement Platform-Specific Security Checkers

Now we create the actual security checking implementations for each platform.

// Android-specific security implementation
class AndroidSecurityChecker extends SecurityChecker {
  @override
  Future<SecurityCheckResult> performSecurityCheck() async {
    bool isRooted = await checkIfDeviceIsRooted();
    if (isRooted) {
      return SecurityCheckResult(
        isSecure: false,
        message: "Device is rooted. App cannot run on rooted devices."
      );
    }

    bool isDeveloperMode = await checkDeveloperMode();
    if (isDeveloperMode) {
      return SecurityCheckResult(
        isSecure: false,
        message: "Developer mode is enabled. Please disable it to continue."
      );
    }

    return SecurityCheckResult(
      isSecure: true,
      message: "Device security check passed."
    );
  }

  Future<bool> checkIfDeviceIsRooted() async {
    return false; 
  }

  Future<bool> checkDeveloperMode() async {
    return false; // Placeholder
  }
}

// iOS-specific security implementation
class IOSSecurityChecker extends SecurityChecker {
  @override
  Future<SecurityCheckResult> performSecurityCheck() async {
    bool isJailbroken = await checkIfDeviceIsJailbroken();

    if (isJailbroken) {
      return SecurityCheckResult(
        isSecure: false,
        message: "Device is jailbroken. App cannot run on jailbroken devices."
      );
    }

    return SecurityCheckResult(
      isSecure: true,
      message: "Device security check passed."
    );
  }

  Future<bool> checkIfDeviceIsJailbroken() async {
    return false; 
  }
}

The Android implementation focuses on detecting rooted devices and developer mode, which are common security concerns on Android.

A rooted device has elevated permissions that could allow malicious apps to access sensitive data, while developer mode can expose debugging interfaces.

The iOS implementation checks for jailbroken devices, which is the iOS equivalent of rooting. Jailbroken devices bypass Apple's security restrictions and can pose similar security risks.

Step 3: Create the Security Factory

The factory wraps the chosen security checker and provides a clean interface for running checks.

// Security Factory
class SecurityCheckFactory {
  SecurityCheckFactory({required this.checker});
  SecurityChecker checker;

  Future<SecurityCheckResult> runSecurityCheck() async {
    return await checker.performSecurityCheck();
  }
}

The SecurityCheckFactory provides a simple interface that accepts any SecurityChecker implementation. This means your app initialization code doesn't need to know about platform-specific security details – it just calls runSecurityCheck() and handles the result.

Step 4: Use the Security Factory in App Bootstrap

Finally, we integrate the security factory into our app's initialization process.

// In your app's bootstrap/initialization
Future<void> initializeApp() async {
  final securityFactory = SecurityCheckFactory(
    checker: Platform.isAndroid 
      ? AndroidSecurityChecker() 
      : IOSSecurityChecker()
  );

  final result = await securityFactory.runSecurityCheck();

  if (!result.isSecure) {
    // Show error dialog and prevent app from continuing
    showSecurityErrorDialog(result.message);
    return;
  }

  // Continue with normal app initialization
  runApp(MyApp());
}

This usage example demonstrates how the Factory Pattern makes your app initialization code clean and maintainable.

The platform detection happens in one place, the factory handles the creation of the appropriate checker, and your code simply deals with the standardized result.

Key takeaway: Factory is great when you need one type of object, but you want to abstract away the creation logic.

How the Abstract Factory Pattern Works in Flutter

The Abstract Factory Pattern comes into play when you have more than two data sets for comparison, and each set includes multiple functionalities.

For example, imagine you now want to manage themes, widgets, and architecture for Android, iOS, and Linux. Managing this with just a Factory becomes messy, so Abstract Factory provides a structured way to handle multiple related objects for different platforms.

So let's see how you can handle this using the abstract factory method.

Step 1: Define Abstract Product Interfaces

Before we dive into this implementation, it's important to understand what abstract product interfaces are. An abstract product interface is essentially a contract that defines what methods a product must implement, without specifying how they're implemented.

Think of it as a blueprint that ensures all related products share a common structure. In our case, we're defining three core functionalities that every platform must provide:

1. Theme management

2. Widget handling

3. Architecture configuration.

By creating these abstract interfaces first, we establish a consistent API that all platform-specific implementations will follow.

abstract class ThemeManager {
  Future<String> getTheme();
}

abstract class WidgetHandler {
  Future<bool> getWidget();
}

abstract class ArchitechtureHandler {
  Future<String> getArchitechture();
}

Here, we’re defining three base functionalities that every platform will implement: theme, widgets, and architecture.

Each interface declares a single method that returns platform-specific information.

The ThemeManager retrieves theme data, WidgetHandler determines widget compatibility, and ArchitechtureHandler provides architecture details.

Step 2: Implement Platform-Specific Products

Now that we have our abstract interfaces defined, we need to create concrete implementations for each platform. This step is where we provide the actual, platform-specific behavior for each product type. Think of this as filling in the blueprint with real details.

While the abstract interfaces told us what methods we need, these concrete classes tell us how those methods behave on each specific platform. Each platform (Android, iOS, Linux) will have its own unique implementation of themes, widgets, and architecture.

Android:

class AndroidThemeManager extends ThemeManager {
  @override
  Future<String> getTheme() async {
    return "Android Theme";
  }
}

class AndroidWidgetHandler extends WidgetHandler {
  @override
  Future<bool> getWidget() async {
    return true;
  }
}

class AndroidArchitechtureHandler extends ArchitechtureHandler {
  @override
  Future<String> getArchitechture() async {
    return "Android Architecture";
  }
}

For Android, we're creating three specific product classes. The AndroidThemeManager returns Material Design theme data, the AndroidWidgetHandler returns true to indicate that Android supports home screen widgets, and the AndroidArchitechtureHandler provides information about Android's architecture (which could include details about ARM, x86, or other processor architectures).

iOS:

class IOSThemeManager extends ThemeManager {
  @override
  Future<String> getTheme() async {
    return "IOS Theme";
  }
}

class IOSWidgetHandler extends WidgetHandler {
  @override
  Future<bool> getWidget() async {
    return false;
  }
}

class IOSArchitechtureHandler extends ArchitechtureHandler {
  @override
  Future<String> getArchitechture() async {
    return "iOS Architecture";
  }
}

The iOS implementations follow the same structure but provide iOS-specific values. Notice that IOSWidgetHandler returns false, this could represent a scenario where certain widget features aren't available or behave differently on iOS compared to Android.

Linux:

class LinuxThemeManager extends ThemeManager {
  @override
  Future<String> getTheme() async {
    return "Linux Theme";
  }
}

class LinuxWidgetHandler extends WidgetHandler {
  @override
  Future<bool> getWidget() async {
    return true;
  }
}

class LinuxArchitechtureHandler extends ArchitechtureHandler {
  @override
  Future<String> getArchitechture() async {
    return "Linux Architecture";
  }
}

Similarly, Linux gets its own set of implementations, providing Linux-specific theme data and architecture information.

Step 3: Define the Abstract Factory Interface

With our product classes ready, we now need to create the factory that will produce them.

The abstract factory interface is the master blueprint that declares which products our factory must be able to create. This interface doesn't create anything itself, it simply declares that any concrete factory must provide methods to create all three product types (theme, widget, and architecture handlers). This ensures that, regardless of which platform factory we use, we can always access all three functionalities.

abstract class AppFactory {
  ThemeManager themeManager();
  WidgetHandler widgetManager();
  ArchitechtureHandler architechtureHandler();
}

Here, we define a factory blueprint. Any platform specific factory will have to implement all three functionalities. This guarantees consistency: every platform will have all three capabilities available.

Step 4: Implement Platform Specific Factories

This is where everything comes together. We're now creating the actual factories that will produce the platform-specific products we defined earlier. Each factory is responsible for creating all the related products for its platform. The key advantage here is encapsulation: the factory knows how to create all the related objects for a platform, and it ensures they're compatible with each other. For example, AndroidFactory creates Android-specific theme managers, widget handlers, and architecture handlers that all work together seamlessly.

class AndroidFactory extends AppFactory {
  @override
  ThemeManager themeManager() => AndroidThemeManager();

  @override
  WidgetHandler widgetManager() => AndroidWidgetHandler();

  @override
  ArchitechtureHandler architechtureHandler() => AndroidArchitechtureHandler();
}

class IOSFactory extends AppFactory {
  @override
  ThemeManager themeManager() => IOSThemeManager();

  @override
  WidgetHandler widgetManager() => IOSWidgetHandler();

  @override
  ArchitechtureHandler architechtureHandler() => IOSArchitechtureHandler();
}

class LinuxFactory extends AppFactory {
  @override
  ThemeManager themeManager() => LinuxThemeManager();

  @override
  WidgetHandler widgetManager() => LinuxWidgetHandler();

  @override
  ArchitechtureHandler architechtureHandler() => LinuxArchitechtureHandler();
}

Each concrete factory (AndroidFactory, IOSFactory, LinuxFactory) implements all three methods from the AppFactory interface. When you call themeManager() on AndroidFactory, you get an AndroidThemeManager. When you call it on IOSFactory, you get an IOSThemeManager. The same pattern applies to all products.

Step 5: Client Code Using Abstract Factory

Finally, we create the client code that uses our abstract factory. This is the layer that your application will actually interact with. The beauty of this pattern is that the client code doesn't need to know anything about the specific platform implementations, it just works with the abstract factory interface.

The AppBaseFactory class accepts any factory that implements AppFactory and provides a simple method to initialize all platform settings. The CheckDevice class determines which factory to use based on the current platform, completely abstracting this decision away from the rest of your application.

class AppBaseFactory {
  AppBaseFactory({required this.factory});
  AppFactory factory;

  getAppSettings() {
    factory
      ..architechtureHandler()
      ..themeManager()
      ..widgetManager();
  }
}

class CheckDevice {
  static get() {
    if (Platform.isAndroid) return AndroidFactory();
    if (Platform.isIOS) return IOSFactory();
    if (Platform.isLinux) return LinuxFactory();
    throw UnsupportedError("Platform not supported");
  }
}

// Usage
AppBaseFactory(factory: CheckDevice.get()).getAppSettings();

Here's what's happening in this code:

The AppBaseFactory class acts as a wrapper around any AppFactory implementation. It provides a convenient getAppSettings() method that initializes all three components (architecture handler, theme manager, and widget manager) using Dart's cascade notation.

The CheckDevice class contains the platform detection logic. Its static get() method checks the current platform and returns the appropriate factory. This centralizes all platform detection in one place. When you call AppBaseFactory(factory: CheckDevice.get()).getAppSettings(), the code automatically detects your platform, creates the right factory, and initializes all platform-specific components, all without the calling code needing to know any platform-specific details.

Each platform factory produces all related products. The client only interacts with AppBaseFactory, remaining unaware of the internal implementation. This ensures your code is scalable, maintainable, and consistent.

Real-World Application: Payment Provider Management

Another good use case for abstract factory is when you need to switch between multiple payment providers in your application and you only want to expose the necessary functionality to the client (presentation layer).

The abstract factory design pattern properly helps you manage this scenario in terms of concrete implementation, encapsulation, clean code, separation of concerns, and proper code structure and management. For example, you might support Stripe, PayPal, and Flutterwave in your application.

Each provider requires different initialization, transaction processing, and webhook handling. By using the Abstract Factory pattern, you can create a consistent interface for all payment operations while keeping provider-specific details encapsulated within their respective factory implementations.

Conclusion

You should now feel more comfortable deciding when to use the Factory design pattern vs the Abstract Factory design pattern.

Understanding the factory and abstract factory patterns and their usages properly will help with object creation based on the particular use case you are trying to implement.

The Factory Pattern is ideal when you need one product and want to encapsulate creation logic while the Abstract Factory Pattern works well when you have multiple related products across platforms, need consistency, and want scalability. Using these patterns will help you write clean, maintainable, and scalable Flutter apps.

They give you a systematic approach to object creation and prevent messy, hard-to-maintain code as your app grows.

The Singleton Design Pattern is a creational design pattern that solves this problem by ensuring that a class has exactly one instance and provides a global point of access to it.

This pattern is widely used in mobile apps, backend systems, and Flutter applications for managing shared resources such as:

• Database connections

• API clients

• Logging services

• Application configuration

• Security checks during app bootstrap

In this article, we'll explore what the Singleton pattern is, how to implement it in Flutter/Dart, its variations (eager, lazy, and factory), and physical examples. By the end, you'll understand the proper way to use this pattern effectively and avoid common pitfalls.

Table of Contents

1. Prerequisites

2. What is the Singleton Pattern?

   • When to Use the Singleton Pattern

3. How to Create a Singleton Class

   • Eager Singleton

   • Lazy Singleton

   • Choosing Between Eager and Lazy

4. Factory Constructors in the Singleton Pattern

   • What Are Factory Constructors?

   • Implementing Singleton with Factory Constructor

5. When Not to Use a Singleton

   • Why Singletons Can Be Problematic

   • Scenarios Where You Should Avoid Singletons

   • General Guidelines

6. Conclusion

Prerequisites

Before diving into this tutorial, you should have:

1. Basic understanding of the Dart programming language

2. Familiarity with Object-Oriented Programming (OOP) concepts, particularly classes and constructors

3. Basic knowledge of Flutter development (helpful but not required)

4. Understanding of static variables and methods in Dart

5. Familiarity with the concept of class instantiation

What is the Singleton Pattern?

The Singleton pattern is a creational design pattern that ensures a class has only one instance and that there is a global point of access to the instance.

Again, this is especially powerful when managing shared resources across an application.

When to Use the Singleton Pattern

You should use a Singleton when you are designing parts of your system that must exist once, such as:

1. Global app state (user session, auth token, app config)

2. Shared services (logger, API client, database connection)

3. Resource heavy logic (encryption handlers, ML models, cache manager)

4. Application boot security (run platform-specific root/jailbreak checks)

For example, in a Flutter app, Android may check developer mode or root status, while iOS checks jailbroken device state. A Singleton security class is a perfect way to enforce that these checks run once globally during app startup.

How to Create a Singleton Class

We have two major ways of creating a singleton class:

1. Eager Instantiation

2. Lazy Instantiation

Eager Singleton

This is where the Singleton is created at load time, whether it's used or not.

In this case, the instance of the singleton class as well as any initialization logic runs at load time, regardless of when this class is actually needed or used. Here's how it works:

class EagerSingleton {
  EagerSingleton._internal();
  static final EagerSingleton _instance = EagerSingleton._internal();

  static EagerSingleton get instance => _instance;

  void sayHello() => print("Hello from Eager Singleton");
}

//usage
void main() {
  // Accessing the singleton globally
  EagerSingleton.instance.sayHello();
}

How the Eager Singleton Works

Let's break down what's happening in this implementation:

First, EagerSingleton._internal() is a private named constructor (notice the underscore prefix). This prevents external code from creating new instances using EagerSingleton(). The only way to get an instance is through the controlled mechanism we're about to define.

Next, static final EagerSingleton _instance = EagerSingleton._internal(); is the key line. This creates the single instance immediately when the class is first loaded into memory. Because it's static final, it belongs to the class itself (not any particular instance) and can only be assigned once. The instance is created right here, at declaration time.

The static EagerSingleton get instance => _instance; getter provides global access to that single instance. Whenever you call EagerSingleton.instance anywhere in your code, you're getting the exact same object that was created when the class loaded.

Finally, sayHello() is just a regular method to demonstrate that the singleton works. You could replace this with any business logic your singleton needs to perform.

When you run the code in main(), the class loads, the instance is created immediately, and EagerSingleton.instance.sayHello() accesses that pre-created instance to call the method.

Pros:

1. This is simple and thread safe, meaning it's not affected by concurrency, especially when your app runs on multithreads.

2. It's ideal if the instance is lightweight and may be accessed frequently.

Cons:

1. If this instance is never used through the runtime, it results in wasted memory and could impact application performance.

Lazy Singleton

In this case, the singleton instance is only created when the class is called or needed in runtime. Here, a trigger needs to happen before the instance is created. Let's see an example:

class LazySingleton {
  LazySingleton._internal(); 
  static LazySingleton? _instance;

  static LazySingleton get instance {
    _instance ??= LazySingleton._internal();
    return _instance!;
  }

  void sayHello() => print("Hello from LazySingleton");
}

//usage 
void main() {
  // Accessing the singleton globally
  LazySingleton.instance.sayHello();
}

How the Lazy Singleton Works

The lazy implementation differs from eager in one crucial way: timing.

Again, LazySingleton._internal() is a private constructor that prevents external instantiation.

But notice that static LazySingleton? _instance; is declared as nullable and not initialized. Unlike the eager version, no instance is created at load time. The variable simply exists as null until it's needed.

The magic happens in the getter: _instance ??= LazySingleton._internal(); uses Dart's null-aware assignment operator. This line says "if _instance is null, create a new instance and assign it. Otherwise, keep the existing one." This is the lazy initialization: the instance is only created the first time someone accesses it.

The first time you call LazySingleton.instance, _instance is null, so a new instance is created. Every subsequent call finds that _instance already exists, so it just returns that same instance.

The return _instance!; uses the null assertion operator because we know _instance will never be null at this point (we just ensured it's not null in the previous line).

This approach saves memory because if you never call LazySingleton.instance in your app, the instance never gets created.

Pros:

1. Saves application memory, as it only creates what is needed in runtime.

2. Avoids memory leaks.

3. Is ideal for resource heavy objects while considering application performance.

Cons:

1. Could be difficult to manage in multithreaded environments, as you have to ensure thread safety while following this pattern.

Choosing Between Eager and Lazy

Now that we've broken down these two major types of singleton instantiation, it's worthy of note that you'll need to be intentional while deciding whether to create a singleton the eager or lazy way. Your use case/context should help you determine what singleton pattern you need to apply during object creation.

As an engineer, you need to ask yourself these questions when using a singleton for object creation:

1. Do I need this class instantiated when the app loads?

2. Based on the user journey, will this class always be needed during every session?

3. Can a user journey be completed without needing to call any logic in this class?

These three questions will determine what pattern (eager or lazy) you should use to fulfill best practices while maintaining scalability and high performance in your application.

Factory Constructors in the Singleton Pattern

Applying factory constructors in the Singleton pattern can be powerful if you use them properly. But first, let's understand what factory constructors are.

What Are Factory Constructors?

A factory constructor in Dart is a special type of constructor that doesn't always create a new instance of its class. Unlike regular constructors that must return a new instance, factory constructors can:

1. Return an existing instance (perfect for singletons)

2. Return a subclass instance

3. Apply logic before deciding what to return

4. Perform validation or initialization before returning an object

The factory keyword tells Dart that this constructor has the flexibility to return any instance of the class (or its subtypes), not necessarily a fresh one.

Implementing Singleton with Factory Constructor

This allows you to apply initialization logic while your class instance is being created before returning the instance.

class FactoryLazySingleton {
  FactoryLazySingleton._internal();
  static final FactoryLazySingleton _instance = FactoryLazySingleton._internal();

  static FactoryLazySingleton get instance => _instance;

  factory FactoryLazySingleton() {
    // Your logic runs here
    print("Factory constructor called");
    return _instance;
  }
}

How the Factory Constructor Singleton Works

This implementation combines aspects of both eager and lazy patterns with additional control.

The FactoryLazySingleton._internal() private constructor and static final _instance create an eager singleton. The instance is created immediately when the class loads.

The static get instance provides the traditional singleton access pattern we've seen before.

But the interesting part is the factory FactoryLazySingleton() constructor. This is a public constructor that looks like a normal constructor call, but behaves differently. When you call FactoryLazySingleton(), instead of creating a new instance, it runs whatever logic you've placed inside (in this case, a print statement), then returns the existing _instance.

This pattern is powerful because:

1. You can log when someone tries to create an instance

2. You can validate conditions before returning the instance

3. You can apply configuration based on parameters passed to the factory

4. You can choose to return different singleton instances based on conditions

For example, you might have different configuration singletons for development vs production:

factory FactoryLazySingleton({bool isProduction = false}) {
  if (isProduction) {
    // Apply production configuration
    _instance.configure(productionSettings);
  } else {
    // Apply development configuration
    _instance.configure(devSettings);
  }
  return _instance;
}

Pros

1. You can add logic before returning an instance

2. You can cache or reuse the same object

3. You can dynamically return a subtype if needed

4. You avoid unnecessary instantiation

5. You can inject configuration or environment logic

Cons

1. Adds slight complexity compared to simple getter access

2. The factory constructor syntax might confuse developers unfamiliar with the pattern

3. If overused with complex logic, it can make debugging harder

4. Can create misleading code where FactoryLazySingleton() looks like it creates a new instance but doesn't

When Not to Use a Singleton

While singletons are powerful, they're not always the right solution. Understanding when to avoid them is just as important as knowing when to use them.

Why Singletons Can Be Problematic

Singletons create global state, which can make your application harder to reason about and test. They introduce tight coupling between components that shouldn't necessarily know about each other, and they can make it difficult to isolate components for unit testing.

Scenarios Where You Should Avoid Singletons

Avoid using the Singleton pattern if:

You need multiple independent instances

If different parts of your app need their own separate configurations or states, singletons force you into a one-size-fits-all approach.

For example, if you're building a multi-tenant application where each tenant needs isolated data, a singleton would cause data to bleed between tenants.

Alternative: Use dependency injection to pass different instances to different parts of your app. Each component receives the specific instance it needs through its constructor or a service locator.

// Instead of singleton
class UserRepository {
  final DatabaseConnection db;
  UserRepository(this.db); 
}

// Usage
final dbForTenantA = DatabaseConnection(tenantId: 'A');
final dbForTenantB = DatabaseConnection(tenantId: 'B');
final repoA = UserRepository(dbForTenantA);
final repoB = UserRepository(dbForTenantB);

Your architecture avoids shared global state

Modern architectural patterns like BLoC, Provider, or Riverpod in Flutter specifically aim to avoid global mutable state. Singletons work against these patterns by reintroducing global state.

Alternative: Use state management solutions designed for Flutter. Provider, Riverpod, BLoC, or GetX offer better ways to share data across your app while maintaining testability and avoiding tight coupling.

// Using Provider instead of singleton
class AppConfig {
  final String apiUrl;
  AppConfig(this.apiUrl);
}

// Provide it at the top level
void main() {
  runApp(
    Provider<AppConfig>(
      create: (_) => AppConfig('https://api.example.com'),
      child: MyApp(),
    ),
  );
}

// Access it anywhere in the widget tree
class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final config = Provider.of<AppConfig>(context);

  }
}

It forces tight coupling between unrelated classes

When multiple unrelated classes depend on the same singleton, they become indirectly coupled. Changes to the singleton affect all these classes, making the codebase fragile and hard to refactor.

Alternative: Use interfaces and dependency injection. Define what behavior you need through an interface, then inject implementations. This way, classes depend on abstractions, not concrete singletons.

// Define an interface
abstract class Logger {
  void log(String message);
}

// Implementation
class ConsoleLogger implements Logger {
  @override
  void log(String message) => print(message);
}

// Classes depend on the interface, not a singleton
class PaymentService {
  final Logger logger;
  PaymentService(this.logger);

  void processPayment() {
    logger.log('Processing payment');
  }
}

// Easy to test with mock
class MockLogger implements Logger {
  List<String> logs = [];
  @override
  void log(String message) => logs.add(message);
}

You need clean, isolated testing

Singletons maintain state between tests, causing test pollution where one test affects another. This makes tests unreliable and order-dependent.

Alternative: Use dependency injection and create fresh instances for each test. Most testing frameworks support this pattern, allowing you to inject mocks or fakes easily.

// Testable code
class OrderService {
  final PaymentProcessor processor;
  OrderService(this.processor);
}

// In tests
void main() {
  test('processes order successfully', () {
    final mockProcessor = MockPaymentProcessor();
    final service = OrderService(mockProcessor); 

  });
}

General Guidelines

Use singletons sparingly and only when you truly need exactly one instance of something for the entire application lifecycle. Good candidates include logging systems, application-level configuration, and hardware interface managers.

For most other cases, prefer dependency injection, state management solutions, or simply passing instances where needed. These approaches make your code more flexible, testable, and maintainable.

Conclusion

The Singleton pattern is a powerful creational tool, but like every tool, you should use it strategically.

Overusing singletons can make apps tightly coupled, hard to test, and less maintainable.

But when used correctly, the Singleton pattern helps you save memory, enforce consistency, and control object lifecycle beautifully.

The key is understanding your specific use case and choosing the right implementation approach – whether eager, lazy, or factory-based – that best serves your application's needs while maintaining clean, testable code.

If these questions have crossed your mind, you're not alone. These are some of the most fundamental concepts in JavaScript, yet they often confuse developers.

In this tutorial, we'll demystify prototypes, prototype chains, and inheritance in JavaScript. By the end, you'll understand the "what," "why," and "how" of JavaScript's prototype system.

Here’s what I’ll cover:

• The String Method Mystery

• How Objects Work Internally

• Understanding the Prototype Chain

• Why Everything in JavaScript is an Object

• The Difference Between proto and prototype

• How Prototypes Work with Functions

• How Prototypes Work with Classes

• Conclusion

Prerequisites

To get the most out of this tutorial, you should have:

• Basic understanding of JavaScript fundamentals

• Familiarity with objects, functions, and classes in JavaScript

• Knowledge of how to declare and use variables

• Experience working with the new keyword (helpful but not required)

The String Method Mystery

Let's start with a simple example that demonstrates something interesting about JavaScript:

let name = "Shejan Mahamud";

After declaring this variable, we can use String methods like:

name.toLowerCase(); // "shejan mahamud"
name.toUpperCase(); // "SHEJAN MAHAMUD"

This seems normal at first glance, but wait – something unusual is happening. Notice anything odd here? We're using dot notation on a string primitive.

Here's the puzzling part: we know that strings are primitive types in JavaScript, not objects. So how can we use dot notation to access methods? After all, dot notation typically only works with objects.

The answer to this mystery lies in understanding how JavaScript handles primitives and prototypes. But before we get there, let's first look at how objects work internally.

How Objects Work Internally

When you create an object in JavaScript like this:

const info1 = {
  fName: "Shejan",
  lName: "Mahamud"
};

JavaScript does something interesting behind the scenes. It automatically adds a hidden property called __proto__ to your object. This property points to Object.prototype, which is the prototype of the built-in Object class.

You might wonder: does Object.prototype also have a __proto__? Yes, it does, but its value is null. This is because Object.prototype is at the top of the prototype chain and doesn't inherit from anything else.

Let's look at a more complex example to understand this better:

const info1 = {
  fName1: "Shejan",
  lName1: "Mahamud"
};

const info2 = {
  fName2: "Boltu",
  lName2: "Mia",
  __proto__: info1
};

const info3 = {
  fName3: "Habu",
  lName3: "Mia",
  __proto__: info2
};

In this example, we've intentionally set the __proto__ property for info2 and info3. Now here's an interesting question: can we access fName1 from info3?

console.log(info3.fName1); // "Shejan"

Yes, we can! Let's understand how this works.

Understanding the Prototype Chain

When you try to access a property on an object, JavaScript follows a specific lookup process:

1. First, it searches for the property in the object itself (the base object)

2. If it doesn't find it there, it looks in the object's __proto__

3. If it still doesn't find it, it continues up the chain, checking each __proto__ until it either finds the property or reaches null

In our example with info3.fName1:

• JavaScript first looks in info3 – and it doesn't find fName1

• Then it checks info3.__proto__, which points to info2 – it doesn't find fName1 there, either

• Next it checks info2.__proto__, which points to info1 – and it finds fName1 here!

This is called the prototype chain, and this is how inheritance works in JavaScript. Here's a visual representation:

┌────────────┐
│  info3     │
│ fName3     │
│ lName3     │
└────┬───────┘
     │ __proto__
     ▼
┌────────────┐
│  info2     │
│ fName2     │
│ lName2     │
└────┬───────┘
     │ __proto__
     ▼
┌────────────┐
│  info1     │
│ fName1     │
│ lName1     │
└────┬───────┘
     │ __proto__
     ▼
┌─────────────────┐
│ Object.prototype│
└────┬────────────┘
     ▼
    null

Each object points to the next object in the chain through its __proto__ property. This chain continues until it reaches null.

Why Everything in JavaScript is an Object

Now let's solve the mystery we started with: how can primitive types use object methods?

In JavaScript, almost everything behaves like an object, even though primitive types (like strings, numbers, and booleans) technically aren't objects. This works through a process called auto-boxing or wrapper objects.

Let's see this in action:

let yourName = "Boltu";

When you try to use a method on this string:

yourName.toLowerCase();

Here's what JavaScript does behind the scenes:

1. It temporarily wraps the primitive value in a wrapper object: new String("Boltu")

2. This temporary object's __proto__ automatically points to String.prototype

3. The method is found in String.prototype and executed

4. After the operation completes, the wrapper object is discarded

5. yourName returns to being a simple primitive value

This is why you can use methods on primitives even though they're not objects. JavaScript creates a temporary object, uses it to access the method, then throws it away.

The same process happens with other primitive types:

• Numbers use Number.prototype

• Booleans use Boolean.prototype

And so on. This elegant system is why developers often say "everything in JavaScript is an object" – even when it's not technically true, it behaves that way when needed.

The Difference Between __proto__ and prototype

This is one of the most confusing aspects of JavaScript for many developers. Let's break it down clearly.

What is prototype?

When you create a function or class in JavaScript, the language automatically creates a blueprint object called prototype. This happens behind the scenes.

Here's an example:

function Person(name) {
  this.name = name;
}

When JavaScript sees this function, it internally does this:

Person.prototype = { 
  constructor: Person 
};

The Person function now has a hidden property called prototype, which is an object containing a constructor property.

You can add methods to this prototype object:

Person.prototype.sayHi = function() {
  console.log("Hi, I'm " + this.name);
};

What is __proto__?

__proto__ is a property that exists on every object instance (arrays, functions, objects – everything). It's an internal reference or pointer that indicates which prototype the object inherits from.

By default, when you create an object, its __proto__ points to Object.prototype.

How They Work Together

When you use the new keyword:

const p1 = new Person("Shejan");

JavaScript performs these steps internally:

1. Creates a new empty object: p1 = {}

2. Sets the object's __proto__: p1.__proto__ = Person.prototype

3. Calls the constructor function with the new object: Person.call(p1, "Shejan")

4. Returns the object: return p1

Now when you try to access a method:

p1.sayHi(); // "Hi, I'm Shejan"

JavaScript looks for sayHi in p1 first. When it doesn't find it, it checks p1.__proto__, which points to Person.prototype, where the method is defined.

The relationship can be expressed as:

p1.__proto__ === Person.prototype; // true
Person.prototype.constructor === Person; // true

In summary:

• prototype is a property of functions/classes that serves as a blueprint for instances

• __proto__ is a property of object instances that points to the prototype they inherit from

How Prototypes Work with Functions

Let's see a complete example with functions:

function Person(name, age) {
  this.name = name;
  this.age = age;
}

// Adding a method to the prototype
Person.prototype.introduce = function() {
  console.log(`Hi, I'm ${this.name} and I'm ${this.age} years old.`);
};

// Creating instances
const person1 = new Person("Alice", 25);
const person2 = new Person("Bob", 30);

person1.introduce(); // "Hi, I'm Alice and I'm 25 years old."
person2.introduce(); // "Hi, I'm Bob and I'm 30 years old."

// Both instances share the same prototype
console.log(person1.__proto__ === Person.prototype); // true
console.log(person2.__proto__ === Person.prototype); // true
console.log(person1.__proto__ === person2.__proto__); // true

The key benefit here is memory efficiency: the introduce method exists only once in Person.prototype, but all instances can access it through the prototype chain.

How Prototypes Work with Classes

ES6 introduced the class syntax, which looks different but works the same way under the hood:

class User {
  constructor(name) {
    this.name = name;
  }

  sayHi() {
    console.log(`Hi, I'm ${this.name}`);
  }
}

const user1 = new User("Charlie");
user1.sayHi(); // "Hi, I'm Charlie"

// Let's check what's really happening
console.log(typeof User); // "function"
console.log(User.prototype); // { sayHi: f, constructor: f User() }
console.log(user1.__proto__ === User.prototype); // true

Classes are essentially syntactic sugar over JavaScript's prototype-based inheritance. Internally:

• A class is still a constructor function

• Methods defined in the class are added to ClassName.prototype

• Instances created with new have their __proto__ set to the class's prototype

This means everything we learned about function prototypes applies to classes as well.

Conclusion

Understanding prototypes and the prototype chain is fundamental to mastering JavaScript. These concepts form the foundation of how JavaScript implements inheritance and object-oriented programming.

Key Takeaways

Let's recap what we've learned:

1. Every object has __proto__: This property points to the prototype the object inherits from, enabling the prototype chain lookup mechanism.

2. Functions and classes have prototype: This property serves as a blueprint for instances created with the new keyword.

3. The prototype chain enables inheritance: When JavaScript can't find a property on an object, it walks up the prototype chain until it finds the property or reaches null.

4. Primitives use wrapper objects: Even though primitives aren't objects, JavaScript temporarily wraps them in objects to provide access to methods.

5. Classes are syntactic sugar: The modern class syntax is cleaner, but it still uses prototypes under the hood.

JavaScript might seem quirky at first, but once you understand how it works under the hood, you'll appreciate its elegant and flexible design.

Happy coding!

This article will help you gain a solid grasp of OOP in TypeScript by walking you through the language features that support it, and then showing how these features naturally give rise to the four foundational principles: inheritance, polymorphism, encapsulation, and abstraction.

Prerequisites

To get the most out of this article, you should be familiar with:

• JavaScript fundamentals – variables, functions, objects, and arrays.

• Basic TypeScript syntax – including types and how they differ from plain JavaScript.

Table of Contents

• How to Read This Article

• TypeScript Language Features

  • Objects

  • Classes, Attributes, and Methods

  • Interfaces

  • Abstract Classes

• Object-Oriented Programming Principles

  • Inheritance – Superclass and Subclass

  • Polymorphism

  • Encapsulation

  • Abstraction

• Conclusion

How to Read This Article

I’ve organized this article into two sections. The first section covers TypeScript language features that enable you to implement Object-Oriented Programming (OOP). The second part discusses concepts derived from these features that lead to the four OOP principles: inheritance, polymorphism, encapsulation, and abstraction.

While many teachers, books, and courses start by explaining these principles, I prefer to start with the language features themselves. The reason is simple: they are formal structures – in other words, concrete. Moreover, throughout the article, you'll notice that the OOP principles naturally emerge when you use the language structure correctly.

TypeScript Language Features

In this section, we’ll explore TypeScript's features that facilitate OOP implementation. Similar mechanisms exist in other object-oriented languages, such as Java and C#, though they may vary in syntax while preserving the core concepts.

Objects

An object is a data type that stores a collection of values organized into key/value pairs. These may include primitive data or other objects.

In the following example, the person object stores various pieces of information, such as the key name, which contains the value "Lucas" of type string, and the address key, which holds another object.

const person = {
  name: "Lucas", // primitive value of type string
  surname: "Garcez",
  age: 28, // primitive value of type number
  address: {
    // object type containing the keys "city" and "country"
    city: "Melbourne",
    country: "Australia",
  },
};

Classes, Attributes, and Methods

A class serves as a blueprint for creating objects. It specifies an object's structure and behavior through its attributes and methods. Attributes outline the data structure (keys and value types), whereas methods define the actions that can be performed on those attributes.

class Person {
  name: string; // attribute
  surname: string; // attribute
  age: number; // attribute

  // constructor method (special method)
  constructor(name: string, surname: string, age: number) {
    this.name = name;
    this.surname = surname;
    this.age = age;
  }

  // method to obtain the full name: "Lucas Garcez"
  getFullName() {
    return `${this.name} ${this.surname}`;
  }
}

Constructor Method

The constructor is a special method within a class. It’s automatically invoked when a new object is created. Constructors are responsible for initializing the class attributes with values provided during object creation. In TypeScript, the constructor is defined using the constructor keyword, as you can see in the code above.

Instance

An instance refers to an object created from a class. For example, using the class Person mentioned above, you can create an object named lucas. Therefore, lucas is an instance of the class Person. To create an instance of an object in JavaScript or TypeScript, you use the keyword new, as demonstrated below:

const lucas = new Person("Lucas", "Garcez", 28);
lucas.name; // "Lucas"
lucas.getFullName(); // "Lucas Garcez"

It is important to note that you can create multiple objects (instances) from the same class. Although all these objects share the same structure (attributes and methods), they are independent and occupy separate memory spaces within the program.

For instance, when creating a new object:

const maria = new Person("Maria", "Oliveira", 19);

You now have a new instance of the Person class that doesn't interfere with the previously created lucas object. Each instance maintains its own values and behaviors, ensuring that manipulating one object doesn't affect the others.

Interfaces

An interface defines a contract establishing which attributes and methods a class must implement. In TypeScript, this relationship is established using the keyword implements. When a class implements an interface, it must include all the attributes and methods specified by that interface and their respective types.

In the following example, you have a banking system where a customer can have either CurrentAccount or SavingsAccount account. Both options must adhere to the bank’s general account rules defined by the BankAccount interface.

// Contract defining the attributes and methods of a bank account
interface BankAccount {
  balance: number;
  deposit(amount: number): void;
  withdraw(amount: number): void;
}

class CurrentAccount implements BankAccount {
  balance: number;
  // The class can have other attributes and methods
  // beyond those specified in the interface
  overdraftLimit: number;

  deposit(amount: number): void {
    this.balance += amount;
  }

  withdraw(amount: number): void {
    if (amount <= this.balance) {
      this.balance -= amount;
    }
  }
}

class SavingsAccount implements BankAccount {
  balance: number;

  deposit(amount: number): void {
    // can have different logic from CurrentAccount
    // but must respect the method signature,
    // i.e., parameters (amount: number) and return type (void)
  }

  withdraw(amount: number): void {
    // ...
  }
}

Abstract Classes

Just like interfaces, abstract classes define a model or contract that other classes must follow. But while an interface only describes the structure of a class without providing implementations, an abstract class can include method declarations and concrete implementations.

Unlike regular classes, though, abstract classes cannot be instantiated directly – they exist solely as a base from which other classes can inherit their methods and attributes.

In TypeScript, the abstract keyword is used to define an abstract class. In the following example, you’ll refactor the banking system by replacing the interface with an abstract class to define base behavior for all bank accounts.

// Abstract class that serves as the base for any type of bank account
abstract class BankAccount {
  balance: number;

  constructor(initialBalance: number) {
    this.balance = initialBalance;
  }

  // Concrete method (with implementation)
  deposit(amount: number): void {
    this.balance += amount;
  }

  // Abstract method (must be implemented by subclasses)
  abstract withdraw(amount: number): void;
}

class CurrentAccount extends BankAccount {
  withdraw(amount: number): void {
    const fee = 2; // Current accounts have a fixed withdrawal fee
    const totalAmount = amount + fee;

    if (this.balance >= totalAmount) {
      this.balance -= totalAmount;
    } else {
      console.log("Insufficient balance.");
    }
  }
}

class SavingsAccount extends BankAccount {
  withdraw(amount: number): void {
    if (this.balance >= amount) {
      this.balance -= amount;
    } else {
      console.log("Insufficient balance.");
    }
  }
}

// ❌ Error! Cannot instantiate an abstract class
const genericAccount = new BankAccount(1000); // Error

// ✅ Creating a current account
const currentAccount = new CurrentAccount(2000); // uses the BankAccount constructor
currentAccount.deposit(500); // uses the deposit method from BankAccount
currentAccount.withdraw(300); // uses the withdraw method from CurrentAccount

// ✅ Creating a savings account
const savingsAccount = new SavingsAccount(1500); // uses the BankAccount constructor
savingsAccount.deposit(1100); // uses the deposit method from BankAccount
savingsAccount.withdraw(500); // uses the withdraw method from SavingsAccount

Object-Oriented Programming Principles

Now that you understand the key language mechanisms, you can formalize the pillars of Object-Oriented Programming that guide the creation of systems that are better organized, reusable, and scalable.

Inheritance – Superclass and Subclass

Inheritance is a mechanism that allows a class to derive characteristics from another class. When a class B inherits from a class A, it means that B automatically acquires the attributes and methods of A without needing to redefine them.

You can visualize this relationship as a parent-child structure, where A is the superclass (base/parent class) and B is the subclass (derived/child class). A subclass can use inherited resources, add new behaviors, or override superclass methods to address specific needs.

We’ve already discussed inheritance when learning about abstract classes, but inheritance can also be applied to concrete classes. This allows for code reuse and behavior specialization.

// BankAccount is now a regular class where you define attributes and methods
// that will be reused by the child class CurrentAccount
class BankAccount {
  balance: number = 0;

  constructor(initialBalance: number) {
    this.balance = initialBalance;
  }

  deposit(amount: number): void {
    this.balance += amount;
  }

  withdraw(amount: number): void {
    if (amount <= this.balance) {
      this.balance -= amount;
    }
  }
}

// CurrentAccount is a subclass of BankAccount, meaning 
// it inherits its attributes and methods.
class CurrentAccount extends BankAccount {
  overdraftLimit: number; // new attribute exclusive to CurrentAccount

  // When specifying a constructor method for a subclass,
  // we need to call another special method, "super".
  // This method calls the superclass (BankAccount) constructor to ensure
  // it is initialized before creating the CurrentAccount object itself.
  constructor(initialBalance: number, overdraftLimit: number) {
    super(initialBalance); // Must match the superclass constructor method signature
    this.overdraftLimit = overdraftLimit;
  }

  // Even though the withdraw method already exists in the superclass (BankAccount),
  // it is overridden here. This means every time a CurrentAccount
  // object calls the withdraw method, this implementation will be used, 
  // ignoring the superclass method.
  override withdraw(amount: number): void {
    const totalAvailable = this.balance + this.overdraftLimit;
    if (amount > 0 && amount <= totalAvailable) {
      this.balance -= amount;
    }
  }
}

// Creating a CurrentAccount with an initial balance of $0.00
// and an overdraft limit of $100.
const currentAccount = new CurrentAccount(0, 100);

// Making a $200 deposit by calling the deposit method
// In this case, the method from BankAccount will be invoked
// since deposit was not overridden in CurrentAccount
currentAccount.deposit(200); // balance: 200

// Withdrawing $250 by calling the withdraw method
// In this case, the method from CurrentAccount will be invoked
// as it has been overridden in its definition
currentAccount.withdraw(250); // balance: -50

Polymorphism

Polymorphism is a concept that often creates confusion in Object-Oriented Programming. But in practice, it is merely a natural consequence of using interfaces and inheritance.

The term polymorphism originates from Greek and means "many forms" (poly = many, morphos = forms). This concept allows objects from different classes to respond to the same method call but with distinct implementations, making code more flexible and reusable.

To clarify this concept, let's consider a practical example. Suppose you have a function named sendMoney, responsible for processing a financial transaction, transferring a certain amount from account A to account B. The only requirement is that both accounts follow a common contract, ensuring the methods withdraw and deposit are available.

// BankAccount could be an interface, a concrete class,
// or an abstract class. For the sendMoney function, the specific implementation
// does not matter—only that BankAccount includes withdraw and deposit methods.
function sendMoney(
  sender: BankAccount,
  receiver: BankAccount,
  amount: number
) {
  sender.withdraw(amount);
  receiver.deposit(amount);
}

const lucasAccount = new CurrentAccount(500, 200);
const mariaAccount = new SavingsAccount(300);

// transferring $100 from Lucas to Maria
sendMoney(lucasAccount, mariaAccount, 100);

Polymorphic Methods:

The withdraw and deposit methods are called within the sendMoney function without requiring the function to know whether it is dealing with a CurrentAccount or SavingsAccount. Each class implements withdraw according to its own rules, demonstrating the concept of polymorphism.

Decoupling:

The sendMoney function does not depend on the specific type of bank account. Any class that extends BankAccount (if it's a class) or implements BankAccount (if it's an interface) can be used without requiring modifications to the sendMoney function.

With this approach, you ensure flexibility and code reusability, as new account types can be introduced without affecting the functionality of sendMoney.

Encapsulation

Encapsulation is one of the fundamental principles of OOP, but its concept can be applied to any programming paradigm. It involves hiding the internal implementation details of a module, class, function, or any other software component, exposing only what is necessary for external use. This improves code security, maintainability, and modularity by preventing unauthorized access and ensuring controlled interactions.

Access Modifiers – public, private, and protected

In OOP, encapsulation is essential for controlling the visibility and access to methods and attributes within a class. In TypeScript, this is achieved using access modifiers, which are defined by the keywords public, protected, and private.

• public – Allows the attribute or method to be accessed from anywhere, both inside and outside the class. This is the default visibility, meaning that if no access modifier is specified in the code, TypeScript assumes it as public.

• protected – Allows access within the class and its subclasses but prevents external access.

• private – Restricts access to the attribute or method only within the class itself.

export class Person {
  private firstName: string; // Accessible only within the class itself
  private lastName: string; // Accessible only within the class itself
  protected birthDate: Date; // Accessible by subclasses but not from outside

  constructor(firstName: string, lastName: string, birthDate: Date) {
    this.firstName = firstName;
    this.lastName = lastName;
    this.birthDate = birthDate;
  }

  // Public method that can be accessed from anywhere
  public getFullName(): string {
    return `${this.firstName} ${this.lastName}`;
  }
}

// The Professor class inherits from Person and can access
// attributes and methods according to their access modifiers.
class Professor extends Person {
  constructor(firstName: string, lastName: string, birthDate: Date) {
    super(firstName, lastName, birthDate); // Calls the superclass (Person) constructor
  }

  getProfile() {
    this.birthDate; // ✅ Accessible because it is protected
    this.getFullName(); // ✅ Accessible because it is public
    this.firstName; // ❌ Error! Cannot be accessed because it is private in the Person class
    this.lastName; // ❌ Error! Cannot be accessed because it is private in the Person class
  }
}

function main() {
  // Creating an instance of Professor
  const lucas = new Professor("Lucas", "Garcez", new Date("1996-02-06"));

  // Testing direct access to attributes and methods
  lucas.birthDate; // ❌ Error! birthDate is protected and can only be accessed within the class or subclasses
  lucas.getFullName(); // ✅ Accessible because it is a public method
  lucas.firstName; // ❌ Error! firstName is private and cannot be accessed outside the Person class
  lucas.lastName; // ❌ Error! lastName is also private and inaccessible outside the Person class
}

Access Modifiers Table

Abstraction

The concept of abstraction frequently causes confusion because its meaning goes beyond the technical context. If you look up the definition of the word in English, the Cambridge Dictionary defines "abstract" as:

Something that exists as an idea, feeling, or quality, rather than as a material object.

This definition can be directly applied to OOP: Abstraction represents an idea or concept without going into concrete implementation details.

Many online references describe abstraction as "hiding implementation details," which can be misleading since this concept is more closely related to encapsulation. In OOP, abstraction does NOT mean hiding details but defining contracts through abstract classes and interfaces.

// Abstraction using interface
interface BankAccountInterface {
  balance: number;
  deposit(amount: number): void;
  withdraw(amount: number): void;
}

// Abstraction using class
abstract class BankAccountClass {
  balance: number;

  constructor(initialBalance: number) {
    this.balance = initialBalance;
  }

  // Concrete method (with implementation)
  deposit(amount: number): void {
    this.balance += amount;
  }

  // Abstract method (must be implemented by subclasses)
  abstract withdraw(amount: number): void;
}

In the examples above, both BankAccountInterface and BankAccountClass are examples of abstraction as they define contracts that must be implemented by those who use them.

Conclusion

Although learning Object-Oriented Programming isn't easy, I hope this article has helped clarify the OOP fundamentals and advanced topics.

If you want to keep learning TypeScript and OOP, I highly recommend reading Martin Fowler's book Refactoring: Improving the Design of Existing Code. This book contains a massive catalog of refactoring techniques, and the second edition has all code examples written in TypeScript, many of which use OOP features and principles mentioned here.

This article is for you if any of these sounds familiar:

• JavaScript is your first programming language.

• You are new to, or not entirely comfortable with, Object-Oriented Programming (OOP) principles.

• You have primarily used functions for structuring your JavaScript code.

If you're nodding along to any of these, then keep reading.

In this article, we'll take a step-by-step approach, showing you how object-oriented programming is implemented in JavaScript with objects and constructor functions, and clearly illustrate why understanding and using classes will make you a more versatile and effective JavaScript developer, even if you’re used to writing everything in functions. We’ll end everything with a simple to-do app example so you can see how to use classes.

Table of Contents

• Functions, Functions Everywhere I Turn

• Hold on a second. Are we saying functions are bad now?

• Wait, what? JavaScript has no real classes?

• Let's talk about objects in JavaScript.

• Constructor Functions: Object Blueprints—Let's Get Practical

• Constructor Functions: Great for Blueprints, but... Memory Waste?

• Prototypes to the Rescue (Again): Sharing Methods Efficiently

• Constructor Functions + Prototypes: A Powerful Combo

• Inheritance with Constructor Functions: Passing Down the Family Traits (the Constructor Way)

• Enter ES6 Classes: Syntactic Sugar for Prototypes

• ES6 Classes: Class Syntax – Prototypes in Disguise

• What’s Next? More Class Features and Real-World Examples

• Conclusion

Functions, Functions Everywhere I Turn

If you started with JavaScript, chances are that you've become really comfortable with functions. They're like the building blocks of everything for you, right? Think about it: if I asked you to write a program to greet someone by name, you'd probably whip up something like this in a flash:

function greetUser(userName) {
  alert("Hello, " + userName + "!");
}

greetUser("Alice"); // Like magic! It greets Alice.

Okay, let's level up a bit. Imagine that I asked you to write a program that figures out someone's birth year just by knowing their age. If they're 25, you'd want it to tell them '2000' (assuming the current year is 2025).

What would your first thought be? Probably something like, 'Function time!' Am I right? You'd think, 'I'll write a function; it'll take the age, and boom, it'll spit out the birth year.' See?

Function-first thinking. Totally natural in JavaScript. And here's how you might code it:

function getBirthYear(age) {
  const currentYear = 2025; //  For this example, let's say it's 2025
  const birthYear = currentYear - age;
  return birthYear;
}
console.log(getBirthYear(25)); // Yep, it logs 2000!

Now, let's make it a bit more complex. What if we want to be a little smarter and make sure the age is actually a valid age? You know, not some crazy string or a negative number. Sticking with our function-loving brains, what's the natural next step? Another function, of course. We'd probably create a validateAge function:

function validateAge(age) {
  if (typeof age !== "number" || age <= 0 || age > 120) {
    return "Invalid age";
  } else {
    return age; //  Age is good to go!
  }
}

console.log(validateAge(25)); //  Output: 25 (valid!)
console.log(validateAge("twenty")); //  Output: Invalid age (not a number)
console.log(validateAge(-5)); //  Output: Invalid age (negative)

See how we're just piling up functions? getBirthYear does one thing, validateAge does another. They're separate little boxes of code.

Let's push this a little further. What if we also wanted to figure out someone's zodiac sign based on their birth year? Yep, you guessed it—the brain says, 'More functions.' Let's just write another getZodiacSign function:

function getZodiacSign(birthYear) {
    const signs = [
        "Monkey", 
        "Rooster", 
        "Dog", 
        "Pig", 
        "Rat",    
        "Ox",
        "Tiger", 
        "Rabbit", 
        "Dragon", 
        "Snake", 
        "Horse", 
        "Sheep"
    ];
    return signs[birthYear % 12]; // Simple modulo trick!
}

Are you noticing the pattern here? For every new thing we want to do we're just adding more and more separate functions. Things are starting to feel a bit... scattered, right? And we're not even done adding features.

Okay, now let's say we want to store even more information about a person—their name, country, profession, besides just age. How would we manage all this with our function-centric approach? Well, we might try to create a big 'Person' function that takes all this info:

function Person(name, age, country, profession) {
  const personName = name;
  const personAge = age;
  const personCountry = country;
  const personProfession = profession;

  const validatedAge = validateAge(personAge);
  const birthYear = getBirthYear(validatedAge);
  const zodiacSign = getZodiacSign(birthYear);

  alert(
    `${personName}, you're ${personAge} years old, born in ${birthYear}, zodiac sign: ${zodiacSign}!`
  );
}

What if we then want to use the person's name in our other functions, like getZodiacSign or getBirthYear? We'd have to go back and manually add name as an argument to each of those functions. Imagine having to update every function whenever you add a new piece of person information.

//  Suddenly, we need 'name' everywhere!

function getZodiacSign(birthYear, name) {
  alert("Zodiac sign for " + name + " is...");
  //... rest of zodiac logic...
}

function getBirthYear(age, name) {
  alert("Birth year for " + name + " is...");
  // ... rest of birth year logic...
}

In this tiny example, it's sort of manageable. But picture a huge project with tons of functions spread across files and folders, how you’d try to keep everything in sync and update functions whenever your person data changes. That sounds like a recipe for headaches, bugs, and a lot of frustration. It can become incredibly inefficient and, honestly, pretty error-prone.

Hold on a second. Are we saying functions are bad now?

Functions are amazing. Think of this function-focused approach as the 'classic JavaScript way' of doing things. If you started with JavaScript, this probably feels totally natural and comfortable—and that's great. Even super popular modern libraries like React are built using functions for components. Functions are incredibly powerful and flexible.

But, even in React, if you change some core data (like a 'prop' in React terms) in a main component, you might have to go digging through lots of other components to make sure everything still works smoothly. Functions are fantastic, but sometimes, for certain kinds of problems, there might be another way to organize our code. A way that, for some folks, feels more intuitive, especially if they come from other programming backgrounds.

Imagine asking a programmer whose first language was Java or C++ to build our birth year program. Their brain might light up, but they'd probably think something a bit different. Maybe something like this:

'We need a Person(class). A Person has an age(proterty) and we need a way to calculateBirthYear(action) for a Person.'

Notice anything different? Functions aren't the first thing that jumps to their mind. It's more about objects and things having properties and actions. Mind-blowing, huh? Many programmers who started with languages like Java or C++ naturally think in this object-oriented (or OOP) style. And hey, maybe that's why you're reading this—maybe you're curious about exploring this object-thinking approach too, especially in JavaScript. Don't worry, I’m not asking you to suddenly switch to Java 😉.

So, about these classes in JavaScript. Get ready for a little JavaScript twist. Here's the thing: JavaScript technically doesn't have classes in the way languages like Java or C++ do. I know, it can be a bit of a head-scratcher. Instead of classical classes as found in languages like Java or C++, JavaScript is built on something called prototypes*.* It uses these flexible prototypes and objects to mimic how classes work in other languages. So, if you want to use classes in JavaScript effectively, the real key is to understand objects and prototypes first. That's where the magic is in JavaScript OOP.

Wait, what? JavaScript has no real classes?

Does that mean we are stuck with just functions forever? Nope. Even though JavaScript does things its own way with prototypes (instead of classic classes), it still fully supports 'Object-Oriented Programming' (OOP).

Let's break down OOP in plain English. Two big ideas in OOP are Encapsulation and Inheritance. Sounds fancy, right? But they're actually pretty simple concepts.

Encapsulation? Imagine a capsule, like for medicine. You're just bundling things that belong together. In OOP, encapsulation means grouping data (like age, name) and the actions you can do with that data (like calculate birth year, greet) inside a single 'object'. JavaScript objects are perfect for this.

And inheritance? Think of it like inheriting traits from your family. In JavaScript OOP, objects can 'inherit' properties and behaviors from other objects. JavaScript calls this prototypal inheritance, and the object you inherit from is called the prototype (we'll dive deeper into prototype soon).

See? No function jail here. JavaScript is totally ready for OOP. To see this in action, let's rewrite our birth year program, but this time using this OOP style in JavaScript.

Check this out. Here's how we could rewrite our birth year program using an OOP style in JavaScript, using just a good old JavaScript object:

const Person = {
  //  --- Properties (Data) ---
  name: "Spruce",
  age: 25,
  country: "Nigeria",
  profession: "Engineer",

  //  --- Methods (Actions related to Person data) ---
  isValidAge: function () {
    return typeof this.age === "number" && this.age > 0;
  },

  getBirthYear: function () {
    if (!this.isValidAge()) {
      return "Invalid age!";
    }
    return new Date().getFullYear() - this.age;
  },

  getZodiacSign: function () {
    if (!this.isValidAge()) {
      return "Oops, can't get zodiac for an invalid age!";
    }

    const birthYear = this.getBirthYear();
    const zodiacSigns = [
      "Capricorn",
      "Aquarius",
      "Pisces",
      "Aries",
      "Taurus",
      "Gemini",
      "Cancer",
      "Leo",
      "Virgo",
      "Libra",
      "Scorpio",
      "Sagittarius",
    ];
    return zodiacSigns[birthYear % 12];
  },

  greet: function () {
    return (
      `Hello, I'm ${this.name}. I'm ${
        this.age
      } years old, born in ${this.getBirthYear()}, ` +
      `working as a ${this.profession} from ${
        this.country
      }.  My zodiac sign is ${this.getZodiacSign()}.`
    );
  },
};

//  --- Let's use our Person object! ---
console.log(Person.greet());

//  Output (might vary slightly depending on year):

// "Hello, I'm Spruce. I'm 25 years old, born in 2000, working as a Engineer from Nigeria.  My zodiac sign is Pig."

See how neat that is? Everything about a Person, their details (name, age, and so on) and what you can do with a person (validate age, get birth year, greet) is all bundled together, and nicely organized inside this single Person object. That's encapsulation in action. Pretty cool, right?

Now, want to know the Person name? Super easy:

console.log(Person.name); // Output: "Spruce"

Birth year? Piece of cake:

console.log(Person.getBirthYear()); // Output (if current year is 2025): 2000

And here's the real magic of encapsulation: if we change something inside the Person object (like, say, we decide to change the age), all the methods (actions) inside automatically adapt. We don't have to go hunting around in separate functions to update things. Let me show you:

//  Age is 25 initially...
console.log("Birth year when age is 25:", Person.getBirthYear()); // Output (if current year is 2025): 2000

//  Let's update the age directly in the Person object...
Person.age = 30;

//  Now, getBirthYear automatically uses the *new* age!
console.log("Birth year when age is 30:", Person.getBirthYear()); // Output (if current year is 2025): 1995

So, JavaScript uses objects—and, as we'll see, prototypes—to bring OOP to life, even if it doesn't have classic classes. Hopefully, you're starting to see the appeal of organizing code this way. Before we jump into classes, it makes a ton of sense to get a really solid understanding of objects and prototypes in JavaScript, right? That's what we'll dive into next.

Let's talk about objects in JavaScript.

If you're already familiar with how objects work, that's fantastic. It'll make understanding everything we cover in this article even smoother. To make sure we're all on the same page, let's start with a super basic object:

const Person = {};

So, is Person an empty object? At first glance, it certainly looks empty. If you thought "yes," you're not alone. It's a common initial thought. But in JavaScript, objects are a little more interesting than just what we explicitly put into them. Let's explore how objects really work under the hood.

Okay, so how do objects work in JavaScript?

Let's break it down. At its core, an object is a collection of properties. Think of properties as named containers for values. Each property has a name (also called a 'key').

const Person = {
  firstName: "John",
  lastName: "Doe",
};

firstName and lastName are the property names (keys), and "John" and "Doe" are their respective values. A property in an object is always a key-value pair. The value part can be many things.

The value associated with a property can be a primitive data type. In JavaScript, primitives are things like strings, numbers, booleans (true or false), null, undefined, and symbols. Let's see some examples:

const exampleObject = {
  name: "Example", // String
  age: 30, // Number
  isStudent: false, // Boolean
  favoriteColor: null, // null
};

But the cool thing is, property values can also be more complex data types or even other objects, functions, and arrays. Let's look at that:

const anotherObject = {
  address: {
    // Value is another object
    street: "123 Main St",
    city: "Anytown",
  },
  hobbies: ["reading", "hiking"], // Value is an array
  greet: function () {
    // Value is a function (a method!)
    console.log("Hello!");
  },
};

When a function is a property of an object, we call it a method. It's essentially a function that belongs to the object and usually operates on the object's data.

const calculator = {
  value: 0,
  add: function(number) {
    this.value += number; // 'this' refers to the calculator object
  },
  getValue: function() {
    return this.value;
  }
};

calculator.add(5);
console.log(calculator.getValue()); // Output: 5

Now, here’s where things get really interesting. Objects in JavaScript don't just have the properties we explicitly define. They can also reference properties from other objects. This is a core concept called prototypal inheritance (sometimes just called prototypal delegation).

Remember our seemingly empty Person = {} object? We said it looked empty, right? Well, it's time for a bit of JavaScript magic. Even though we didn't put any properties in it ourselves, it's not completely empty. Every object in JavaScript, by default, has a hidden link (often referred to internally as its [[Prototype]] property) to another object called its prototype.

For objects created using the simple {} syntax (like our person object), their default prototype is the built-in Object.prototype. Think of Object.prototype as a kind of parent object that provides some basic, built-in functionality to all objects.

This is why you can do things like this, even with our "empty" Person object:

console.log(Person.toString()); // Output: [object Object]

Wait a minute. We never defined a toString() method in our Person object. So where is it coming from? It's coming from its prototype, Object.prototype. toString() is a method that's built into Object.prototype, and because Person's prototype is Object.prototype, Person can access and use the toString() method.

So, a good way to think about it is: "The prototype of an object is another object from which it can look up and use properties and methods if it doesn't have them itself."

Why is understanding prototypes so important? Because it unlocks the power of code reuse and creating specialized objects based on more general ones. This is where things get really powerful, especially as your JavaScript projects grow.

Imagine that we want to create a more specific type of Person—say, a Developer. A Developer is still a Person, but they might have some additional properties or behaviors specific to developers. Basically, we want a Developer object to be a Person, but also have its own unique stuff.

This is where we can explicitly set up prototypes. Instead of relying on the default Object.prototype, we can tell JavaScript: "Hey, I want the prototype of my Developer object to be the Person object we already defined." We can do this using Object.create():

const Person = {
  firstName: "John",
  lastName: "Doe",
  sayHello: function () {
    console.log(`Hello, my name is ${this.firstName} ${this.lastName}`);
  },
};

const developer = Object.create(Person); // developer's prototype is now 'Person'
developer.firstName = "Spruce"; // Add a *specific* firstName for developer
developer.programmingLanguage = "JavaScript"; // Developer's own property

developer.sayHello(); // Output: Hello, my name is Spruce Person (still accesses sayHello from 'person' prototype!)
console.log(developer.programmingLanguage); // Output: JavaScript (developer's own property)
console.log(developer.lastName); // Output: Doe (inherited from 'Person' prototype!)

Let's break down what's happening when we access properties on Developer:"

console.log(developer.firstName); // Output: Spruce (developer's *own* property)
console.log(developer.programmingLanguage); // Output: JavaScript (developer's *own* property)
console.log(developer.lastName); // Output: Doe (found on the *prototype* 'Person')
console.log(developer.sayHello()); // Output: Hello, my name is Spruce Person (method from *prototype*)
console.log(developer.job); // Output: undefined (not on 'Developer' OR 'Person' prototype)

When you try to access a property like Developer.lastName, JavaScript does the following:

1. First, it checks: Does Developer have a property named lastName directly on itself? In our example, Developer only has firstName and programmingLanguage as its own properties. lastName is not there.

2. If it doesn't find it on the object itself, JavaScript then looks at the object's prototype (which we set to Person using Object.create()).

3. It checks: 'Does the Person object (the prototype) have a property named lastName?' Yes, Person does have lastName: "Doe". So, JavaScript uses this value.

4. If the property isn’t found on the prototype either, JavaScript would then look at the Person's prototype (which is Object.prototype by default), and so on, up the prototype chain. If it goes all the way up the chain and still doesn't find the property, it finally returns undefined (like when we tried to access developer.job).

Own properties are simply the properties that are defined directly on the object itself when you create it (like firstName and programmingLanguage on Developer). Prototype properties are accessed through the prototype chain.

You can even create longer prototype chains. For example, let's say we want to create a JavaScriptDeveloper object, which is a type of Developer. We can make Developer the prototype of JavaScriptDeveloper:

const JavaScriptDeveloper = Object.create(Developer); // javaScriptDeveloper's prototype is 'Developer'

JavaScriptDeveloper.framework = "React"; // JavaScriptDeveloper's own property

console.log(JavaScriptDeveloper.firstName); // Output: Spruce (from 'Developer' prototype)

console.log(JavaScriptDeveloper.lastName); // Output: Doe (from 'Person' prototype)

console.log(JavaScriptDeveloper.programmingLanguage); // Output: JavaScript (from 'Developer' prototype)

console.log(JavaScriptDeveloper.framework); // Output: React (JavaScriptDeveloper's own property)

console.log(JavaScriptDeveloper.job); // Output: undefined (not found anywhere in the chain)

(Optional Exploration: If you're curious, trace the lookup for javaScriptDeveloper.lastName. It goes: JavaScriptDeveloper -> Developer -> Person -> Object.prototype).

Okay, prototypes are powerful. We can create objects that share properties and behaviors and specialize them for different needs. But imagine if we wanted to create hundreds of Person objects, hundreds of Developer objects, and hundreds of JavaScriptDeveloper objects.

Using Object.create() every time would still be quite repetitive, especially if we want to ensure that every Person starts with the same basic properties (like firstName and lastName).

We need a better way to create multiple objects that follow the same pattern, like a blueprint that we can re-use over and over again to create objects. This is what classes are for, they are just blueprints that we can use to create multiple objects, and JavaScript uses Constructor functions to create classes (the blueprints).

In the next section, we’ll dive into how javascript uses Constructor functions to implement classes.

Constructor Functions: Object Blueprints—Let's Get Practical

Okay, prototypes are pretty cool for code reuse and making specialized objects. We saw how Object.create() lets us create objects that inherit from others. But imagine that we wanted to make tons of Person objects, like, hundreds of them for a website. Typing out Object.create(person) for every single one would get super repetitive, especially if we always want every Person to start with the same basic properties, like a firstName and lastName.

We need a more efficient way to make lots of objects that follow the same pattern. What we really need is something like a blueprint—something we can use over and over again to stamp out new objects, all looking and working in a similar way. And guess what? That’s exactly what constructor functions are for.

Think of constructor functions as JavaScript's way of creating blueprints for objects. They're like object factories. And in JavaScript, we use constructor functions, which are specialized functions used in a particular way, to create these blueprints. Yep, functions again. But we use them in a special way.

So what is a constructor function, exactly?

Well, like I said, it's a function that creates objects. Take a look at this example:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function () {
    console.log(`Hello, I'm ${this.name}`);
  };
}

That looks like a regular function. You're absolutely right. It looks just like any other function you've probably written in JavaScript. In fact, let's prove it. If we just log PersonConstructor itself, we’ll see:

console.log(PersonConstructor);

// output
function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function () {
    console.log(`Hello, I'm ${this.name}`);
  };
}

See? Just a regular function. So, what makes it a constructor function?

The Magic Ingredient: The new Keyword

What turns an ordinary function into a constructor**—**something that builds objects—is the new keyword. It's like saying to JavaScript, "Hey, treat this function as a blueprint, and use it to create a new object for me."

Let's see it in action:

const person1 = new PersonConstructor("Alice", 25);

console.log(person1);

// output

// PersonConstructor { name: 'Alice', age: 25, greet: [Function] }

In the output now, instead of just seeing the function code, we're seeing a PersonConstructor object. The new keyword didn't just call the function, it actually created a brand new object based on the PersonConstructor blueprint.

Now, we can use this blueprint, PersonConstructor, to create as many Person objects as we want, all with the same basic structure:

const person1 = new PersonConstructor("Alice", 25);
const person2 = new PersonConstructor("Bob", 30);
const person3 = new PersonConstructor("Charlie", 28);

console.log(person1);
console.log(person2);
console.log(person3);

// output
PersonConstructor { name: 'Alice', age: 25, greet: [Function] }
PersonConstructor { name: 'Bob', age: 30, greet: [Function] }
PersonConstructor { name: 'Charlie', age: 28, greet: [Function] }

Cool, right? We have three distinct Person objects, all created from the same PersonConstructor blueprint.

Hold Up... What's This this Keyword I Keep Seeing?

You've probably noticed the word this popping up a lot in these code examples, like in this.name, this.age, and this.greet(). And you might be thinking, "What in the JavaScript world is this?"

Don't worry, this can be a bit confusing at first, but it's actually pretty simple once you get the hang of it. Let's break it down with a simple analogy.

Imagine you're describing yourself. You might say, "My name is [Your Name]." In this sentence, "my" refers to you, the person speaking.

In JavaScript objects, this is like "my" or "me." It's a way for an object to refer to itself.

Let's see this with a regular object example first:

const PersonObject = {
  name: "Spruce",
  greet: function () {
    console.log("Hello, my name is " + PersonObject.name); //  Using PersonObject.name directly
  },
};

PersonObject.greet(); // Output: Hello, my name is Spruce

In this PersonObject, inside the greet function, we used PersonObject.name to access the name property. This works perfectly fine. We're directly telling JavaScript to get the name property from the PersonObject. We could use this here too, but let's see why this becomes super helpful, especially in constructor functions.

Now, consider this slightly different version using this:

const PersonObjectThis = {
  name: "Spruce",
  greet: function () {
    console.log("Hello, my name is " + this.name); // Using 'this.name'
  },
};

PersonObjectThis.greet(); // Output: Hello, my name is Spruce

See? It still works the same way. When greet is called on PersonObjectThis, inside the greet function, it automatically refers to PersonObjectThis. So this.name is just a more dynamic way of saying "the name property of this current object."

Why use this instead of directly naming the object?

Because this is dynamic and context-aware. It always points to the object that is currently calling the method. This becomes essential in constructor functions because constructor functions are designed to create many different objects.

Back to constructor functions: What does this mean there?

Let's revisit our PersonConstructor:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function () {
    console.log(`Hello, I'm ${this.name}`);
  };
}

const person1 = new PersonConstructor("Alice", 25);
const person2 = new PersonConstructor("Bob", 30);

When we do const person1 = new PersonConstructor("Alice", 25); inside the PersonConstructor function:

• this becomes person1. It's as if JavaScript is doing:

  • person1.name = "Alice";

  • person1.age = 25;

  • person1.greet = function() { ... };

And when we do const person2 = new PersonConstructor("Bob", 30); inside PersonConstructor again:

• this becomes person2. Like JavaScript doing:

  • person2.name = "Bob";

  • person2.age = 30;

  • person2.greet = function() { ... };

So, this in a constructor function is like a placeholder that gets filled in with the specific object being created when you use new. It's what lets us create many different objects from the same blueprint.

Constructor Functions: Great for Blueprints, but... Memory Waste?

Okay, so now that you know how to create object blueprints using constructor functions, and you understand what this does, we can make lots of Person objects.

But there's a little problem lurking in our PersonConstructor:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
  this.greet = function () {
    // 😬 Look at this greet function!
    console.log(`Hello, I'm ${this.name}`);
  };
}

const person1 = new PersonConstructor("Alice", 25);
const person2 = new PersonConstructor("Bob", 30);

console.log(person1, person2);

// output

PersonConstructor {name: "Alice", age: 25, greet: function}

PersonConstructor {name: "Bob", age: 30, greet: function}

Notice the greet function inside the PersonConstructor? Every time we create a new Person object using new PersonConstructor(), we're actually copying the entire greet function to each and every object.

Imagine that we create one thousand Person objects. We'd have a thousand identical greet functions in memory. For a simple greet() function, the memory impact might seem small. However, if you had more complex methods with lots of code, or if you were creating thousands or even millions of objects, duplicating these functions for every single object can become a significant waste of memory.

It also impacts performance as JavaScript has to manage all these duplicated functions. That's a lot of duplicated code, and it's not very memory-efficient, especially if the greet function (or other methods) were more complex.

Prototypes to the Rescue (Again): Sharing Methods Efficiently

Remember prototypes? We learned that objects can inherit properties and methods from their prototypes. Well, constructor functions have a built-in way to use prototypes to solve this memory-waste problem.

Instead of defining the greet function inside the constructor and thus copying it to every instance, we can add it to the prototype of the PersonConstructor function.

Like this:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
}

//  --- Add the greet method to the PROTOTYPE of PersonConstructor! ---
PersonConstructor.prototype.greet = function () {
  console.log(`Hello, I'm ${this.name}`);
};

Now, the greet method is defined only once on PersonConstructor.prototype. But all objects created with PersonConstructor can still use it. They inherit it from the prototype.

Let's test it:

const person1 = new PersonConstructor("Alice", 25);
const person2 = new PersonConstructor("Bob", 30);

person1.greet(); // Output: Hello, I'm Alice  - Still works!
person2.greet(); // Output: Hello, I'm Bob    - Still works!

console.log(person1.greet === person2.greet); // Output: false - They are NOT the same function object in memory

console.log(person1.__proto__.greet === person2.__proto__.greet); // Output: true - But they share the same prototype method!

person1.greet() and person2.greet() still work perfectly. But now, the greet function is not copied for each object. It's shared through the prototype. This is much more efficient, especially when we're dealing with lots of objects and methods.

Constructor Functions + Prototypes: A Powerful Combo

We've now seen how constructor functions act as blueprints for creating objects, and how using the prototype of a constructor function lets us efficiently share methods among all objects created from that blueprint.

This is a key pattern in JavaScript for creating reusable object structures.

Okay, we've covered object creation and efficient methods... But what about inheritance with constructor functions?

What if we want to create a DeveloperPerson blueprint that inherits from our PersonConstructor blueprint? So that DeveloperPerson objects automatically has name, age, and greet, but can also have its own special developer-related properties and methods?

That's where things get a bit more involved with constructor functions, and we'll need to use a special trick called call() to make inheritance work. Let's dive into that next.

Inheritance with Constructor Functions: Passing Down the Family Traits (the Constructor Way)

Alright, we're making good progress. We've got constructor functions to create object blueprints, and prototypes to share methods efficiently. But one of the big reasons people use OOP is for inheritance – the idea of creating specialized objects that build upon more general ones.

Think back to our Person and Developer example. A Developer is a Person, right? They have a name, an age, maybe they greet people, but they also have developer-specific properties, like a favorite programming language and the ability to code.

How can we create a DeveloperPersonConstructor blueprint that inherits all the basic PersonConstructor stuff, and then adds its own developer-specific features? With constructor functions, you can use something called call().

call(): The Secret Inheritance Handshake

call() is a function method that lets you do something a bit unusual: you can borrow a function from one object and run it in the context of another object. Sounds confusing? Let's simplify.

To illustrate call(), let's consider our PersonConstructor. We want to create a DeveloperPersonConstructor that also sets up name and age in the same way PersonConstructor does, before adding developer-specific properties.

This is where call() comes in. We can use call() to essentially say: "Hey PersonConstructor, run your code, but run it as if you were inside DeveloperPersonConstructor, and set up name and age for this DeveloperPerson object we're currently creating."

Let's see this in code to make it clearer:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
}

PersonConstructor.prototype.greet = function () {
  console.log(`Hello, I'm ${this.name}`);
};

function DeveloperPersonConstructor(name, age, programmingLanguage) {
  //  --- "Borrow" the PersonConstructor to set up name and age! ---
  PersonConstructor.call(this, name, age); //  <--  The magic of 'call()'

  // --- Now, add developer-specific properties ---
  this.programmingLanguage = programmingLanguage;
  this.code = function () {
    console.log(`${this.name} is coding in ${this.programmingLanguage}`);
  };
}

See that line: PersonConstructor.call(this, name, age); ? That's the key to inheritance here. Let's break it down:

• PersonConstructor.call(...): We're calling the PersonConstructor function, but not in the usual way. We're using .call().

• this: The first argument to call() is crucial. It specifies what this should be inside the PersonConstructor function when it runs. Here, we're passing this from DeveloperPersonConstructor. Why? Because we want PersonConstructor to set up name and age on the DeveloperPerson object that's currently being created.

• name, age: These are the arguments we're passing to the PersonConstructor function itself. So, when PersonConstructor runs (thanks to .call()), it will receive name and age and do what it normally does: set this.name = name and this.age = age. But because this is actually the DeveloperPerson object, it sets these properties on the DeveloperPerson object.

Putting it all Together: Creating a DeveloperPerson

Now, let's create a DeveloperPerson object and see what happens:

const devPerson1 = new DeveloperPersonConstructor("Eve", 30, "JavaScript");

console.log(devPerson1.name); // Output: Eve (Inherited from PersonConstructor!)
console.log(devPerson1.age); // Output: 30 (Inherited from PersonConstructor!)
devPerson1.greet(); // Output: (Oops! Error!)
console.log(devPerson1.programmingLanguage); // Output: JavaScript (Developer-specific)
devPerson1.code(); // Output: Eve is coding in JavaScript (Developer-specific)

Notice that devPerson1.name and devPerson1.age are there. DeveloperPersonConstructor borrowed the part of PersonConstructor that sets up those basic properties. And we also have devPerson1.programmingLanguage and devPerson1.code() which are specific to developers.

Uh Oh! Where's greet()?

But wait, devPerson1.greet() is throwing an error. Why? Because even though we borrowed the constructor logic from PersonConstructor, we haven't yet set up the prototype chain for inheritance of prototype methods like greet().

Right now, devPerson1's prototype is just the default object prototype (Object.prototype). It's not inheriting from PersonConstructor.prototype. We need to fix that.

Setting the Prototype Chain for Constructor Inheritance

To make DeveloperPersonConstructor objects also inherit prototype methods from PersonConstructor, we need to manually adjust the prototype chain. We can do this using Object.create() again.

We want the prototype of DeveloperPersonConstructor to be an object that inherits from PersonConstructor.prototype.

Here's the code:

function PersonConstructor(name, age) {
  this.name = name;
  this.age = age;
}

PersonConstructor.prototype.greet = function () {
  console.log(`Hello, I'm ${this.name}`);
};

function DeveloperPersonConstructor(name, age, programmingLanguage) {
  PersonConstructor.call(this, name, age);
  this.programmingLanguage = programmingLanguage;
  this.code = function () {
    console.log(`${this.name} is coding in ${this.programmingLanguage}`);
  };
}

// ---  Set up the Prototype Chain for Inheritance! ---
DeveloperPersonConstructor.prototype = Object.create(
  PersonConstructor.prototype
);

That line DeveloperPersonConstructor.prototype = Object.create(PersonConstructor.prototype); is doing the magic. It's saying, "Hey JavaScript, set the prototype of DeveloperPersonConstructor to be a new object that inherits from PersonConstructor.prototype."

Now, let's try devPerson1.greet() again:

const devPerson1 = new DeveloperPersonConstructor("Eve", 30, "JavaScript");

devPerson1.greet(); // Output: Hello, I'm Eve  - 🎉 It works now!

devPerson1.greet() now works. devPerson1 is inheriting the greet() method from PersonConstructor.prototype through the prototype chain we just set up.

Let's Trace the Prototype Chain

Let's really understand what's happening when we do devPerson1.greet():

1. JavaScript checks: Does devPerson1 itself have a greet property? No.

2. JavaScript looks at devPerson1's prototype: DeveloperPersonConstructor.prototype. Does it have a greetproperty? No, we only added developer-specific methods or properties to DeveloperPersonConstructor directly, not to its prototype in our example. (We could add developer-specific prototype methods later).

3. JavaScript goes up the prototype chain to DeveloperPersonConstructor.prototype's prototype: PersonConstructor.prototype. Does it have a greet property? Yes. We defined PersonConstructor.prototype.greet = function() { ... };

4. JavaScript finds greet() on PersonConstructor.prototype, and executes it in the context of devPerson1 (so this.name inside greet() refers to devPerson1.name).

Prototype chain in action. devPerson1 -> DeveloperPersonConstructor.prototype -> PersonConstructor.prototype-> Object.prototype.

Going Even Further: JavaScript Developer Person

We can even create longer inheritance chains. Let's say we want to create a JavaScriptDeveloperPersonConstructor that's a special type of DeveloperPersonConstructor, maybe with a specific JavaScript framework preference.

We can do the same pattern:

function JavaScriptDeveloperPersonConstructor(name, age, framework) {
  //  "Borrow" from DeveloperPersonConstructor first!
  DeveloperPersonConstructor.call(this, name, age, "JavaScript"); // Hardcoded "JavaScript"
  this.framework = framework;
  this.codeJavaScript = function () {
    // Specific to JavaScript developers
    console.log(`${this.name} is coding in JavaScript with ${this.framework}`);
  };
}

// Set up prototype chain: JavaScriptDeveloperPerson -> DeveloperPerson -> Person
JavaScriptDeveloperPersonConstructor.prototype = Object.create(
  DeveloperPersonConstructor.prototype
);

Now we have a three-level inheritance chain.

Constructor Functions: Powerful, but a Bit... Verbose?

Constructor functions and prototypes are really powerful. They are the fundamental way JavaScript achieves OOP-like behavior. However, as you can see, setting up inheritance with call() and Object.create() can get a bit wordy and tricky to read, especially as inheritance chains get longer.

And guess what? The JavaScript folks noticed this too. In 2015, a new, cleaner syntax for creating object blueprints was introduced in JavaScript.

Enter ES6 Classes: Syntactic Sugar for Prototypes

You see, in 2015, JavaScript developers recognized that using prototypes and constructor functions directly to achieve class-like patterns could become verbose and less straightforward to manage as applications grew. Therefore, they introduced the class syntax in ECMAScript 2015 (ES6).

Classes in JavaScript provide a much cleaner and more familiar way to create object blueprints and set up inheritance. But here’s the super important thing to remember: JavaScript classes are still built on top of prototypes. They don't fundamentally change how JavaScript OOP works. They are just syntactic sugar – a nicer, easier way to write code that's still using prototypes behind the scenes.

In the next section, we'll see how to rewrite our Person, DeveloperPerson, and JavaScriptDeveloperPerson examples using the new class syntax, and you'll see how much cleaner and more class-like (pun intended) it feels, while using the power of JavaScript prototypes.

ES6 Classes: Class Syntax – Prototypes in Disguise

Okay, we've wrestled with constructor functions and call() and Object.create() to get inheritance working with prototypes. It's powerful, but let's be honest, it can feel a little verbose and indirect, especially if you're used to class-based languages.

That's where ES6 classes come to the rescue. They offer a much more streamlined and class-like syntax for creating object blueprints in JavaScript.

Let's rewrite our PersonConstructor example using the class syntax. Get ready for a breath of fresh air.

PersonClass - Constructor Function Reimagined as a Class

Here's how we can define our Person blueprint as a class:

class PersonClass {
  //  Using the 'class' keyword!
  constructor(name, age) {
    //  'constructor' method - like our old constructor function
    this.name = name; //  Still using 'this' in the constructor
    this.age = age;
  }

  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
}

Doesn't that look much cleaner and more organized? Let's break down the class syntax:

• class PersonClass { ... }: We start with the class keyword, followed by the class name (PersonClass in this case). Class names are conventionally capitalized.

• constructor(name, age) { ... }: Inside the class, we have a special method called constructor. This is like our old PersonConstructor function. It's where we put the code to initialize the properties of a new PersonClass object when it's created with new. We still use this inside the constructor to refer to the new object being created.

• greet() { ... }: This is how we define methods in a class. We simply write the method name (greet), followed by parentheses for parameters (none in this case), and then the method body in curly braces. Notice that we don't use the function keyword here. It's just greet() { ... }.

Creating Objects from a Class - Still Using new

To create objects from our PersonClass blueprint, we still use the new keyword, just like we did with constructor functions:

const classPerson1 = new PersonClass("Charlie", 28);
const classPerson2 = new PersonClass("Diana", 32);

console.log(classPerson1.name); // Output: Charlie
classPerson1.greet(); // Output: Hello, I'm Charlie

Yep, it works exactly the same way as our constructor function example, but the class syntax is just much more readable and less cluttered.

DeveloperPersonClass - Inheritance Made Easy with extends

Now, let's tackle inheritance using classes. Remember how we had to use call() and Object.create() to get DeveloperPersonConstructor to inherit from PersonConstructor? With classes, inheritance becomes super straightforward using the extends keyword.

Here's how we can rewrite DeveloperPersonConstructor as a DeveloperPersonClass that inherits from PersonClass:

class DeveloperPersonClass extends PersonClass {
  //  'extends' for inheritance!
  constructor(name, age, programmingLanguage) {
    super(name, age); //  'super()' calls the parent class constructor!
    this.programmingLanguage = programmingLanguage;
  }

  code() {
    // Developer-specific method
    console.log(`${this.name} is coding in ${this.programmingLanguage}`);
  }
}

Look at that. Inheritance in classes is declared using the extends keyword: class DeveloperPersonClass extends PersonClass {...}. This line alone says, "Hey JavaScript, DeveloperPersonClass should inherit from PersonClass."

Inside the DeveloperPersonClass constructor, we have this line: super(name, age);. super() is crucial for class inheritance. It's how we call the constructor of the parent class (PersonClass in this case). When we call super(name, age), it's essentially doing the same thing as PersonConstructor.call(this, name, age) in our constructor function example—it's running the PersonClass constructor to set up the inherited properties (name and age) on the DeveloperPersonClass object.

After calling super(), we can then add any developer-specific properties or methods to our DeveloperPersonClass, like this.programmingLanguage = programmingLanguage; and the code() method.

Using DeveloperPersonClass - Inheritance in Action, Cleaner Syntax

Let's create a DeveloperPersonClass object and see inheritance in action with this cleaner syntax:

const classDevPerson1 = new DeveloperPersonClass("Eve", 35, "JavaScript");

console.log(classDevPerson1.name); // Output: Eve (Inherited from PersonClass!)
console.log(classDevPerson1.age); // Output: 35 (Inherited from PersonClass!)
classDevPerson1.greet(); // Output: Hello, I'm Eve (Inherited from PersonClass!)
console.log(classDevPerson1.programmingLanguage); // Output: JavaScript (Developer-specific)
classDevPerson1.code(); // Output: Eve is coding in JavaScript (Developer-specific)

It works exactly as expected. classDevPerson1 inherits name, age, and greet() from PersonClass and also has its own programmingLanguage and code() methods. But the class syntax makes the inheritance relationship much more obvious and easier to work with.

Classes: Syntactic Sugar, Prototype Power Underneath

Let's be crystal clear again: JavaScript classes are syntactic sugar over prototypes. They are a more user-friendly way to write code that is still based on prototypes and constructor functions behind the scenes.

When you define a class, JavaScript is actually doing these things for you under the hood:

• It's creating a constructor function (like our PersonConstructor).

• It's setting up the .prototype property of that constructor function.

• When you use extends, it's using Object.create() and call() to set up the prototype chain for inheritance.

Classes don't change the fundamental prototype-based nature of JavaScript OOP. They just give us a more familiar and less verbose syntax to work with it.

So, Are Classes Just "Fake" Classes?

Some people argue that JavaScript classes are “fake” because they’re merely syntactic sugar. But honestly, that’s not the point at all. Syntactic sugar is awesome—it makes our code easier to read, write, and maintain. For those coming from a class-based language background, classes make object-oriented programming in JavaScript much more approachable and understandable.

The key takeaway is that while classes give you a neat, familiar syntax, you still need to understand the underlying mechanism: prototypes. Classes are just a friendly layer on top of JavaScript’s prototype system.

What’s Next? More Class Features and Real-World Examples

Alright, now that you’re comfortable with the idea of classes, it’s time to see them in action. Understanding the theory is only half the battle—we need some practical examples.

And to solidify your understanding, let’s walk through building a classic example: a basic to-do list app. While a to-do app is still relatively simple in concept, it introduces enough front-end interaction to see how classes can organize front-end JavaScript code for interactive elements in a manageable way for learning.

Imagine you want to build a really basic to-do app. What do you need to manage?

• To-dos: Each to-do item has a description and a status (done or not).

• Actions: You’ll want to add new to-dos, mark them as complete, delete them, and list them.

This naturally leads us to think of a “ToDo” item as an object, and if you’re creating many to-do items, a ToDo class is a perfect blueprint.

Setting Up Your Files

Before writing any code, create two files in the same folder:

• index.html: This is the webpage structure.

• script.js: This is where your JavaScript code with classes will live.

You can use any text editor (like VS Code, Sublime Text, or even Notepad) to create these files.

Creating the ToDo Class

Let’s start by building our ToDo class. Copy and paste the following code into your script.js file:

class ToDo {

constructor(description) {

this.description = description; // Every to-do needs a description

this.completed = false; // By default, it's not completed

}

markComplete() {

this.completed = true;

console.log("${this.description}" marked as complete!);

}

// More methods (e.g., for editing the to-do) can be added later.

}

Notice how clean that is. The constructor sets up the description and completed status for each new to-do item. The markComplete() method updates the status and logs a confirmation message.

Building the ToDoList Class

Next, we’ll build a ToDoList class to manage our collection of to-dos. Add the following code to your script.js file, below the ToDo class:

class ToDoList {

constructor() {

this.todos = []; // Start with an empty array of to-dos

}

addTodo(description) {

const newTodo = new ToDo(description); // Create a new ToDo object

this.todos.push(newTodo); // Add it to our list

this.renderTodoList(); // Update the webpage display

}

listTodos() {

return this.todos; // Return the array of todos (for further processing or rendering)

}

markTodoComplete(index) {

if (index >= 0 && index < this.todos.length) {

this.todos[index].markComplete();

this.renderTodoList(); // Update the display after marking complete

}

}

renderTodoList() {

const todoListElement = document.getElementById('todoList');

todoListElement.innerHTML = ''; // Clear the current list in HTML

this.todos.forEach((todo, index) => {

const listItem = document.createElement('li');

listItem.textContent = todo.description;

if (todo.completed) {

listItem.classList.add('completed'); // Add CSS class for styling completed items

}

// Create a "Complete" button for each to-do

const completeButton = document.createElement('button');

completeButton.textContent = 'Complete';

completeButton.onclick = () => this.markTodoComplete(index);

listItem.appendChild(completeButton);

todoListElement.appendChild(listItem);

});

}

}

In this class:

• The constructor initializes an empty array to hold our to-do items.

• addTodo(description) creates a new ToDo object and adds it to the array, then calls renderTodoList() to update the display.

• listTodos() returns the list of to-dos.

• markTodoComplete(index) marks a specific to-do as complete and refreshes the display.

• renderTodoList() finds the HTML element with the ID todoList, clears its content, and then creates list items for each to-do, including a “Complete” button.

Creating the HTML Structure

Next, open your index.html file and paste in the following HTML code:

<!DOCTYPE html>

<html>

<head>

  <title>My Simple To-Do App</title>

  <style>

    /* Simple CSS to style completed items */

    .completed {

      text-decoration: line-through;

      color: gray;

    }

  </style>

</head>

<body>

  <h1>My To-Do List</h1>

  <input type="text" id="todoInput" placeholder="Enter new to-do...">

<button id="addButton">Add To-Do</button>

  <ul id="todoList"></ul>

  <script src="script.js"></script>

</body>

</html>

This HTML file sets up:

• A heading for your to-do list.

• An input box (with id="todoInput") for entering new to-dos.

• An “Add To-Do” button (with id="addButton").

• An empty unordered list (with id="todoList") where your to-dos will appear.

• A link to the script.js file that contains your JavaScript code.

Making It All Work Together

Finally, let’s hook up our HTML elements with our JavaScript. At the bottom of your script.js file, add this code:

const myTodoList = new ToDoList(); // Create an instance of ToDoList

// Get references to the HTML elements

const addButton = document.getElementById("addButton");

const todoInput = document.getElementById("todoInput");

// Listen for clicks on the "Add To-Do" button

addButton.addEventListener("click", () => {
  const todoText = todoInput.value.trim(); // Get the text from the input box

  if (todoText) {
    // Only add if the input is not empty

    myTodoList.addTodo(todoText); // Add the new to-do

    todoInput.value = ""; // Clear the input box
  }
});

// Render the to-do list initially (it will be empty to start)

myTodoList.renderTodoList();

This code does the following:

• Creates an instance of the ToDoList class.

• Finds the HTML elements for the input and button.

• This code adds an event listener to the HTML button element that has the ID "addButton". This listener is set to react to "click" events on this button. When the "Add To-Do" button is clicked, the code inside the event listener function will execute. This code takes the text that the user has typed into the HTML input field with the ID "todoInput" and adds it as a new to-do item to our list.

• Initially renders the to-do list on the webpage.

Your Challenge: Go Proto-Style

Now that you’ve seen how classes can make building this to-do app more structured, here’s a challenge: Try building the same to-do app without using the class keyword. Use object literals and prototypes instead. Think about:

• How would you create a ToDo “blueprint” using a constructor function and prototypes?

• How would you add the markComplete() method to the ToDo prototype?

• How would you structure a ToDoList “blueprint” similarly?

By building the same app using both approaches, you’ll really understand that classes are just a nicer, more familiar way of writing prototype-based code.

Conclusion

Congratulations! You’ve built a basic, interactive to-do app using JavaScript classes and HTML. You now see how classes help you organize code and encapsulate related functionality. While classes are just syntactic sugar over prototypes, they make it much easier to write, read, and maintain your code—especially as your applications grow.

Your next step? Experiment with the prototype approach and compare it with the class-based approach. The more you code, the more natural these concepts will become. Happy coding, and keep building cool stuff.

If you have any questions, feel free to find me on Twitter at @sprucekhalifa, and don’t forget to follow me for more tips and updates. Happy coding!

What is Polymorphism?

The word polymorphism is derived from Greek, and means "having multiple forms":

• Poly = many

• Morph = forms

In programming, polymorphism is the ability of an object to take many forms.

The key advantage of polymorphism is that it allows us to write more generic and reusable code. Instead of writing separate logic for different classes, we define common behaviours in a parent class and let child classes override them as needed. This eliminates the need for excessive if-else checks, making the code more maintainable and extensible.

MVC frameworks like Django use polymorphism to make code more flexible. For example, Django supports different databases like SQLite, MySQL, and PostgreSQL. Normally, each database requires different code to interact with it, but Django provides a single database API that works with all of them. This means you can write the same code for database operations, no matter which database you use. So, if you start a project with SQLite and later switch to PostgreSQL, you won’t need to rewrite much of your code, thanks to polymorphism.

In this article, to make things easy to understand, I’ll show you a bad code example with no polymorphism. We’ll discuss the issues that this bad code causes, and then solve the issues by refactoring the code to use polymorphism.

(Btw, if you learn better by video, checkout my Polymorphism in Python YouTube video.)

First, an example with no polymorphism:

class Car:
    def __init__(self, brand, model, year, number_of_doors):
        self.brand = brand
        self.model = model
        self.year = year
        self.number_of_doors = number_of_doors

    def start(self):
        print("Car is starting.")

    def stop(self):
        print("Car is stopping.")

class Motorcycle:
    def __init__(self, brand, model, year):
        self.brand = brand
        self.model = model
        self.year = year

    def start_bike(self):
        print("Motorcycle is starting.")

    def stop_bike(self):
        print("Motorcycle is stopping.")

Let’s say that we want to create a list of vehicles, then loop through it and perform an inspection on each vehicle:

# Create list of vehicles to inspect
vehicles = [
    Car("Ford", "Focus", 2008, 5),
    Motorcycle("Honda", "Scoopy", 2018),
]

# Loop through list of vehicles and inspect them
for vehicle in vehicles:
    if isinstance(vehicle, Car):
        print(f"Inspecting {vehicle.brand} {vehicle.model} ({type(vehicle).__name__})")
        vehicle.start()
        vehicle.stop()
    elif isinstance(vehicle, Motorcycle):
        print(f"Inspecting {vehicle.brand} {vehicle.model} ({type(vehicle).__name__})")
        vehicle.start_bike()
        vehicle.stop_bike()
    else:
        raise Exception("Object is not a valid vehicle")

Notice the ugly code inside the for loop! Because vehicles is a list of any type of object, we have to figure out what type of object we are dealing with inside each loop before we can access any information on the object.

This code will continue to get uglier as we add more vehicle types. For example, if we extended our codebase to include a new Plane class, then we’d need to modify (and potentially break) existing code – we’d have to add another conditional check in the for loop for planes.

Introducing: Polymorphism…

Cars and motorcycles are both vehicles. They both share some common properties and methods. So, let’s create a parent class that contains these shared properties and methods:

Parent class (or "superclass"):

class Vehicle:
    def __init__(self, brand, model, year):
        self.brand = brand
        self.model = model
        self.year = year

    def start(self):
        print("Vehicle is starting.")

    def stop(self):
        print("Vehicle is stopping.")

Car and Motorcycle can now inherit from Vehicle. Let’s create the child classes (or "subclasses") of the Vehicle superclass:

class Car(Vehicle):
    def __init__(self, brand, model, year, number_of_doors):
        super().__init__(brand, model, year)
        self.number_of_doors = number_of_doors

    # Below, we "override" the start and stop methods, inherited from Vehicle, to provide car-specific behaviour

    def start(self):
        print("Car is starting.")

    def stop(self):
        print("Car is stopping.")

class Motorcycle(Vehicle):
    def __init__(self, brand, model, year):
        super().__init__(brand, model, year)

    # Below, we "override" the start and stop methods, inherited from Vehicle, to provide bike-specific behaviour

    def start(self):
        print("Motorcycle is starting.")

    def stop(self):
        print("Motorcycle is stopping.")

Car and Motorcycle both extend Vehicle, as they are vehicles. But what’s the point in Car and Motorcycle both extending Vehicle if they are going to implement their own versions of the start() and stop() methods? Look at the code below:

# Create list of vehicles to inspect
vehicles = [Car("Ford", "Focus", 2008, 5), Motorcycle("Honda", "Scoopy", 2018)]

# Loop through list of vehicles and inspect them
for vehicle in vehicles:
    if isinstance(vehicle, Vehicle):
        print(f"Inspecting {vehicle.brand} {vehicle.model} ({type(vehicle).__name__})")
        vehicle.start()
        vehicle.stop()
    else:
        raise Exception("Object is not a valid vehicle")

In this example:

• We have a list, vehicles, containing instances of both Car and Motorcycle.

• We iterate through each vehicle in the list and perform a general inspection on each one.

• The inspection process involves starting the vehicle, checking its brand and model, and stopping it afterwards.

• Despite the vehicles being of different types, polymorphism allows us to treat them all as instances of the base Vehicle class. The specific implementations of the start() and stop() methods for each vehicle type are invoked dynamically at runtime, based on the actual type of each vehicle.

Because the list can only contain objects that extend the Vehicle class, we know that every object will share some common fields and methods. This means that we can safely call them, without having to worry about whether each specific vehicle has these fields or methods.

This demonstrates how polymorphism enables code to be written in a more generic and flexible manner, allowing for easy extension and maintenance as new types of vehicles are added to the system.

For example, if we wanted to add another vehicle to the list, we don’t have to modify the code used to inspect vehicles (“the client code”). Instead, we can just extend our code base (that is, create a new class), without modifying existing code:

class Plane(Vehicle):
    def __init__(self, brand, model, year, number_of_doors):
        super().__init__(brand, model, year)
        self.number_of_doors = number_of_doors

    def start(self):
        print("Plane is starting.")

    def stop(self):
        print("Plane is stopping.")

# Create list of vehicles to inspect
vehicles = [
    Car("Ford", "Focus", 2008, 5),
    Motorcycle("Honda", "Scoopy", 2018),

    ########## ADD A PLANE TO THE LIST: #########

    Plane("Boeing", "747", 2015, 16),

    ############################################
]

The code to perform the vehicle inspections doesn’t have to change to account for a plane. Everything still works, without having to modify our inspection logic.

Conclusion

Polymorphism allows clients to treat different types of objects in the same way. This greatly improves the flexibility of software and maintainability of software, as new classes can be created without you having to modify (often by adding extra if/else if blocks) existing working and tested code.

Further Learning

Polymorphism is related to many other object-oriented programming principles, such as dependency injection and the open-closed SOLID principle. If you’d like to master OOP, then check out my Udemy course:

• Python OOP: Object Oriented Programming From Beginner to Pro 🎥

If you prefer book to video, check out my books:

• Amazon Kindle and paperback 📖

• Gumroad PDF 📖

Thanks for reading :)

We just published a course on the freeCodeCamp.org YouTube channel that provides a comprehensive introduction to object-oriented programming using Python. Created by Dan Adams, this beginner-friendly course covers the fundamental concepts of OOP, including classes and objects, attributes and methods, inheritance, encapsulation, abstraction, and polymorphism. Through clear explanations and practical examples, this course will help you develop the skills needed to write clean, maintainable, and scalable code using Python.

What You Will Learn

This course is designed to take learners from the basics of OOP to more advanced concepts, ensuring a deep understanding of how object-oriented programming works in Python. Below is an overview of the key topics covered.

Understanding Classes and Objects

The foundation of OOP lies in understanding classes and objects. A class serves as a blueprint for creating objects, while an object is an instance of a class with its own unique data and behavior. This section explains how to define classes, create objects, and work with attributes and methods to encapsulate functionality within objects.

Attributes, Methods, and Access Modifiers

Objects contain attributes, which store data, and methods, which define the behavior of an object. Python provides mechanisms to control access to these attributes and methods using access modifiers, such as public, protected, and private attributes. This section covers how to use and modify object attributes, when to make attributes private or protected, and Python’s philosophy on data protection.

Getters, Setters, and Properties

Encapsulation is a key principle of OOP that involves restricting direct access to an object's internal data. This is achieved through getter and setter methods, which control how data is accessed and modified. The course also introduces Python properties, a more Pythonic way to manage attribute access without explicitly defining getter and setter methods.

Static Attributes and Methods

Not all attributes and methods belong to individual instances of a class. Static attributes are shared across all instances of a class, while static methods operate independently of any specific object. This section explains when and why to use static attributes and methods to improve code efficiency and organization.

Encapsulation and Abstraction

Encapsulation helps to bundle data and functionality together while restricting direct access to certain components, making the code more secure and maintainable. Abstraction, on the other hand, focuses on hiding unnecessary details and exposing only what is essential. This section discusses the importance of both concepts and how they contribute to writing clean and efficient software.

Inheritance: Reusing and Extending Code

Inheritance is one of the most powerful features of OOP, allowing developers to create new classes that inherit functionality from existing ones. This promotes code reuse and reduces duplication. The course demonstrates how to implement inheritance in Python, create base and derived classes, and override methods to extend or modify existing functionality.

Polymorphism: Writing Flexible and Scalable Code

Polymorphism allows objects of different classes to be treated as if they belong to the same class, enabling greater flexibility in software design. The course introduces the concept of polymorphism and demonstrates how it can be used to write more adaptable and scalable code.

Why Learn Object-Oriented Programming?

Object-oriented programming is widely used in the software industry and is a fundamental skill for developers working on large-scale applications. Understanding OOP provides several benefits:

• Improved Code Organization – OOP structures code into modular, reusable components, making it easier to read and manage.

• Enhanced Code Maintainability – Encapsulation and abstraction help prevent unintended modifications, reducing the risk of errors.

• Code Reusability – Inheritance allows developers to reuse existing functionality instead of rewriting code from scratch.

• Scalability – OOP principles enable applications to grow in complexity without becoming unmanageable.

• Industry Relevance – Many programming languages and frameworks are based on OOP, making it a valuable skill for any developer.

Course Structure

The course is structured to gradually introduce concepts, ensuring that learners fully grasp each topic before moving on. Below is a general outline of the course contents:

• Introduction – Overview of object-oriented programming and its importance.

• Creating Classes and Objects – Understanding how to define and instantiate objects in Python.

• Working with Object Attributes and Methods – Learning how to modify and access data within objects.

• Encapsulation and Data Protection – Implementing public, protected, and private attributes.

• Inheritance and Code Reusability – Using inheritance to build more efficient programs.

• Polymorphism and Flexibility – Applying polymorphism to create adaptable code.

• Conclusion – Summarizing key concepts and reinforcing best practices.

Start Learning Today

By the end of this course, learners will have a strong understanding of object-oriented programming and the ability to confidently apply OOP principles to real-world projects. Watch the full course on the freeCodeCamp.org YouTube channel (3-hour watch).

In this article, I'll use some common interview questions to simplify the key OOP concepts, providing clear explanations and code snippets to boost your confidence for your next interview.

Table of Contents

• What is OOP?

• What are the Four Main Principles of OOP

• What is Method Overloading?

• What is a Constructor in OOP?

• What is a Destructor in OOP?

• What is a Class in OOP?

• What is an Object in OOP?

• What is a Static Method?

• What is the Difference Between a Class Variable and an Instance Variable?

• Does Python Support Multiple Inheritance?

• What is the Difference Between an Abstract Class and an Interface?

• Conclusion

What is OOP?

Object-Oriented Programming (OOP) is a way of writing software that revolves around objects. These objects can store data and their actions (methods). Rather than concentrating solely on processes and logic, OOP encourages you to structure your code around these objects.

This approach makes it easier to create modular, reusable, and scalable software designs.

What are the Four Main Principles of OOP

The four pillars of OOP are:

• Encapsulation

• Abstraction

• Inheritance

• Polymorphism

What is Encapsulation, and Why is it Important?

Encapsulation helps protect the data inside an object. Think of it like keeping certain details private, allowing only controlled access to them.

That is, instead of directly changing or viewing the data, you interact with it through specific methods. This ensures that the data is safe from unintended changes.

Example:

class Person:
    def __init__(self, name, age):
        self.name = name
        self.__age = age  # Private attribute (notice the double underscore)

    def get_age(self):
        return self.__age  # A method to access the private age attribute

In this example, __age is kept private, and we can only get the age using the get_age() method. This ensures that age is not accidentally modified in a way that could cause issues.

What is Abstraction, and How is it Different from Encapsulation?

Abstraction allows you to show only the important details of an object or system, while hiding the complex parts that the user doesn't need to see.

Think of it like driving a car, you only need to know how to use the steering wheel, gear, gas pedal, and brakes to drive. You don’t need to understand how the engine works internally.

In programming, abstraction helps you focus on what something does, not how it works inside.

Example: Let’s say you’re using a Car class. The abstraction lets you start the car without knowing all the mechanical details:

class Car:
    def start_engine(self):
        print("Engine started")

    def drive(self):
        print("Car is driving")

# The user interacts with the car without knowing how the engine works
my_car = Car()
my_car.start_engine()
my_car.drive()

Here, you don’t need to worry about how the start_engine method works internally, you just use it!

Key Difference:

• Encapsulation: Focuses on bundling data and restricting access.

• Abstraction: Focuses on hiding complexity and exposing only necessary details.

What is inheritance in OOP?

Inheritance lets you create a new class by using an existing class. The new class (called the child class) gets all the attributes and methods from the existing class (called the parent class).

This allows you to reuse code and build upon what you've already written without starting from scratch.

Example:

# Parent class
class Vehicle:
    def __init__(self, brand):
        self.brand = brand  # This is an attribute (brand)

    def start(self):
        print(f"{self.brand} vehicle started")  # This is a method

# Child class that inherits from Vehicle
class Car(Vehicle):
    def __init__(self, brand, model):
        super().__init__(brand)  # Inherit the brand from Vehicle (parent class)
        self.model = model  # Add a new attribute specific to Car

    def display_info(self):
        print(f"Car: {self.brand}, Model: {self.model}")

# Creating an object of the Car class
my_car = Car("IVM", "Ikenga")
my_car.start()  # Output: IVM vehicle started
my_car.display_info()  # Output: Car: IVM, Model: Ikenga

In this example, Vehicle is the parent class, and Car is the child class. Car inherits the brand and start() method from Vehicle, but it also has its own attribute (model) and method (display_info()).

Inheritance makes it easier to create more specialized classes (like Car) based on a general class (like Vehicle).

What is Polymorphism?

Polymorphism allows different types of objects to respond to the same action in their own unique way. It’s like how both cats and dogs make sounds, but each makes a different sound when you ask them to!

Polymorphism can be achieved through method overriding (when a child class has a method with the same name as a method in its parent class but provides its own implementation).

Example of method overriding:

# Parent class
class Animal:
    def sound(self):
        return "Some generic animal sound"

# Child class Dog overriding the sound method
class Dog(Animal):
    def sound(self):
        return "Bark"

# Child class Cat overriding the sound method
class Cat(Animal):
    def sound(self):
        return "Meow"

# Creating instances of each class
my_dog = Dog()
my_cat = Cat()

# Calling the sound method
print(my_dog.sound())  # Output: Bark
print(my_cat.sound())  # Output: Meow

In this example:

• Animal is the parent class, and it has a method called sound().

• Both Dog and Cat are child classes of Animal, and they override the sound() method to provide their own specific sound.

• When you call sound() on a dog, it returns "Bark", and for a cat, it returns "Meow."

This is polymorphism in action, different objects (Dog, Cat) responding to the same method (sound()) in different ways.

It's a powerful tool that helps in creating flexible and easy-to-maintain code!

What is Method Overloading?

Method overloading happens when you create multiple methods with the same name, but with different types of parameters inside the same class.

While Python doesn't support traditional method overloading, you can mimic similar behavior by using default arguments/parameters or handling multiple arguments inside the method.

Example 1: Using Default Parameters

class Calculator:
    def add(self, a, b=0, c=0):
        return a + b + c

# Create an instance of Calculator
calc = Calculator()

# Call the add method with different numbers of arguments
print(calc.add(5))        # Output: 5 (a = 5, b and c default to 0)
print(calc.add(5, 10))    # Output: 15 (a = 5, b = 10, c default to 0)
print(calc.add(5, 10, 15))# Output: 30 (a = 5, b = 10, c = 15)

In this example, the add method has one required parameter (a) and two optional parameters (b and c) with default values of 0.

By changing the number of arguments you pass when calling the method, you can achieve a method overloading effect.

Example 2: Using *args for Dynamic Parameters

class Calculator:
    def add(self, *args):
        return sum(args)

# Create an instance of Calculator
calc = Calculator()

# Call the add method with different numbers of arguments
print(calc.add(5))           # Output: 5 (adds just one number)
print(calc.add(5, 10))       # Output: 15 (adds two numbers)
print(calc.add(5, 10, 15))   # Output: 30 (adds three numbers)

In this example, the add method can handle any number of arguments thanks to *args, allowing you to call the method with one or more parameters. It sums up all the numbers passed to it.

What is a Constructor in OOP?

A constructor is a special method that automatically runs when you create a new object from a class. It helps to set up the object's initial values (like setting the name or age of a person).

In Python, the constructor method is named __init__, which stands for "initialize”.

Example:

class Student:
    def __init__(self, name, grade):  # The constructor method
        self.name = name  # Setting the name when the object is created
        self.grade = grade  # Setting the grade when the object is created

# Creating a new Student object
student1 = Student("Alice", "A")

# Accessing the student's details
print(student1.name)  # Output: Alice
print(student1.grade)  # Output: A

In this example, the __init__ method automatically assigns the values for name and grade when we create a Student object (like student1).When you print student1.name, it shows "Alice," and student1.grade shows "A."

This helps to set up each student object with different details when needed!

What is a Destructor in OOP?

A destructor is a method that is called when an object is destroyed. In Python, the destructor is defined using __del__.

Example:

class Demo:
    def __init__(self):
        print("Constructor called")

    def __del__(self):
        print("Destructor called")

obj = Demo()
del obj  # Explicitly calling the destructor

In this example, the Demo class has a constructor (__init__) that prints "Constructor called" when an object is created, and a destructor (__del__) that prints "Destructor called" when the object is deleted.

The del obj explicitly triggers the destructor to clean up the object.

What is a Class in OOP?

A class is like a template for making objects in programming. It outlines what properties (called attributes) and actions (called methods) the objects will have. Think of a class as a recipe that tells you how to create something, like a car.

Example:

 class Car:
    def __init__(self, make, model):
        self.make = make  # The brand of the car, like IVM
        self.model = model  # The specific model, like Ikenga

    def display_info(self):
        return f"Car: {self.make}, Model: {self.model}"  # Shows the car's information

In this example:

• Car is the class that describes what a car is.

• make and model are attributes that hold information about the car.

• display_info is a method that tells us how to get details about the car.

When we create a car object from this class, it will have its own make and model, just like real cars do!

What is an Object in OOP?

An object is a specific example of a class. Think of it like a real-life item that has certain characteristics defined by the class. When you create an object, you're giving it actual values for its properties.

my_car = Car("IVM", "Ikenga")
print(my_car.display_info())  # This will show: Car: IVM, Model: Ikenga

In this example, my_car is an object created from the Car class.

What is a Static Method?

This is a method that belongs to a class, not to an instance (object) of that class. Unlike other methods, static methods don’t need access to instance-specific data (attributes) or class-specific data.

You can call a static method directly from the class without creating an object.

Example:

class MathOperations:
    @staticmethod  # This tells Python it's a static method
    def add(a, b):
        return a + b

# We don't need to create an object of the class to use the static method
result = MathOperations.add(5, 3)
print(result)  # Output: 8

In this example, @staticmethod is used to define the method as static. You can call MathOperations.add() directly using the class name, without creating an object of MathOperations.

What is the Difference Between a Class Variable and an Instance Variable?

A class variable is shared among all instances of a class, while an instance variable is specific to each object and defined inside methods, usually within the constructor.

Example:

class MyClass:
    class_var = "I am a class variable"

    def __init__(self, instance_var):
        self.instance_var = instance_var  # Instance variable

In this example, a class MyClass has a class variable class_var that is shared by all instances, and an instance variable instance_var that is unique to each object created from the class.

Does Python Support Multiple Inheritance?

Yes, Python allows multiple inheritance, where a class can inherit from more than one parent class.

Example:

class Parent1:
    def display(self):
        print("Parent1")

class Parent2:
    def display(self):
        print("Parent2")

class Child(Parent1, Parent2):
    pass

child = Child()
child.display()  # Method resolution order determines which display() is called

In this example, the Child class inherits from both Parent1 and Parent2, and due to the method resolution order (MRO), Child will call Parent1's display() method first.

What is the Difference Between an Abstract Class and an Interface?

An abstract class is a special type of class that you cannot create an object from. It can have both incomplete methods (called abstract methods) that don’t have any implementation, as well as fully implemented methods that do have code.

An interface is like a contract that defines methods that must be implemented by any class that uses it. In Python, we achieve interfaces through abstract base classes (ABCs), which only contain abstract methods. They don’t have any implementation.

Simple example to illustrate the concepts:

from abc import ABC, abstractmethod

# Abstract Class
class Animal(ABC):
    @abstractmethod
    def sound(self):
        pass  # This is an abstract method, no implementation

    def sleep(self):
        return "Sleeping..."  # This is a regular method with implementation

# Subclass that implements the abstract method
class Dog(Animal):
    def sound(self):
        return "Bark"  # Implementation of the abstract method

class Cat(Animal):
    def sound(self):
        return "Meow"  # Another implementation of the abstract method

# Using the classes
my_dog = Dog()
print(my_dog.sound())  # Output: Bark
print(my_dog.sleep())  # Output: Sleeping...

my_cat = Cat()
print(my_cat.sound())  # Output: Meow
print(my_cat.sleep())  # Output: Sleeping...

In this example, an abstract class Animal with an abstract method sound, and two subclasses, Dog and Cat, implement the sound method, demonstrating the use of abstract classes and method overriding in Python.

Conclusion

Understanding these OOP principles is crucial for any developer. It forms the foundation of most modern programming languages.

By mastering the key concepts and being prepared for interview questions, you’ll not only build better software but also enhance your chances of landing your next developer role.

If you found this guide helpful please give it a like. You can follow me on X for more insightful articles.

The SOLID Principles were introduced by a software engineer named Robert C. Martin (also known as "Uncle Bob") in the early 2000s. Uncle Bob’s goal was to promote good software design practices, particularly in object-oriented programming (OOP), by addressing common problems developers face as software systems grow in size and complexity.

Here are the five SOLID principles:

• 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)

By following these principles, you can create software designs that are easier to understand, maintain, and extend, leading to higher-quality software that is more robust and adaptable to change.

In this article, to demonstrate each principle, I’ll first show you a bad code example in C# that violates the principle. We will then discuss the issues this bad code causes, and then solve those issues by refactoring the code to satisfy the principle.

First up we have the…

Single Responsibility Principle (SRP) in C

A class should have only one reason to change, meaning that it should have only one responsibility or purpose.

This principle encourages you to create classes that are more focussed and perform one single well-defined task, rather than multiple tasks. Breaking up classes into smaller, more focused units makes code easier to understand, maintain, and test.

An example that violates the SRP:

public class User
{
 public string Username { get; set; }
 public string Email { get; set; }

 public void Register()
 {
   // Register user logic, e.g. save to database...

   // Send email notification
   EmailSender emailSender = new EmailSender();
   emailSender.SendEmail("Welcome to our platform!", Email);
 }
}

public class EmailSender
{
 public void SendEmail(string message, string recipient)
 {
   // Email sending logic
   Console.WriteLine($"Sending email to {recipient}: {message}");
 }
}

In this example, the User class manages user data (username and email), and contains logic for registering a user. This violates the SRP because the class has more than one reason to change. It could change due to:

• Modifications in user data management – for example adding more fields, such as firstName, gender, hobbies.

• Modifications to the logic of registering a user, for example we may choose to fetch a user from the database by their username rather than their email.

To adhere to the Single Responsibility Principle, we should separate these responsibilities into separate classes.

Refactoring the code to satisfy the SRP:

public class User
{
 public string Username { get; set; }
 public string Email { get; set; }
}

public class EmailSender
{
 public void SendEmail(string message, string recipient)
 {
   // Email sending logic
   Console.WriteLine($"Sending email to {recipient}: {message}");
 }
}

public class UserService
{
 public void RegisterUser(User user)
 {
   // Register user logic...

   EmailSender emailSender = new EmailSender();
   emailSender.SendEmail("Welcome to our platform!", user.Email);
 }
}

In the refactored code, the User class is responsible solely for representing user data. The UserService class now handles user registration, separating concerns related to user data management from user registration logic. The UserService class is responsible only for the business logic of registering a user.

This separation of responsibilities adheres to the Single Responsibility Principle, making the code easier to understand, maintain, and extend.

Open/Closed Principle (OCP) in C

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

This principle promotes the idea that existing code should be able to be extended with new functionality without modifying its source code. It encourages the use of abstraction and polymorphism to achieve this goal, allowing for code to be easily extended through inheritance or composition.

(By the way, if you don’t understand these fundamental OOP concepts, such as abstraction, polymorphism, inheritance and composition — then check out my book, Mastering Design Patterns in C#: A Beginner-Friendly Guide, Including OOP and SOLID Principles on Amazon or Gumroad.)

Let's consider an example of a Shape class hierarchy that calculates the area of different geometric shapes. Initially, this violates the Open/Closed Principle because adding a new shape requires modifying the existing code:

public enum ShapeType
{
 Circle,
 Rectangle
}

public class Shape
{
 public ShapeType Type { get; set; }
 public double Radius { get; set; }
 public double Length { get; set; }
 public double Width { get; set; }

 public double CalculateArea()
 {
   switch (Type)
   {
     case ShapeType.Circle:
       return Math.PI * Math.Pow(Radius, 2);
     case ShapeType.Rectangle:
       return Length * Width;
     default:
       throw new InvalidOperationException("Unsupported shape type.");
   }
 }
}

In this example, the Shape class has a method, CalculateArea(), that calculates the area based on the type of shape. Adding a new shape, such as a triangle, would require modifying the existing Shape class, violating the OCP.

To adhere to the Open/Closed Principle, we should design the system in a way that allows for extension without modification. Let's refactor the code using inheritance and polymorphism:

public abstract class Shape
{
 public abstract double CalculateArea();
}

public class Circle : Shape
{
 public double Radius { get; set; }

 public override double CalculateArea()
 {
   return Math.PI * Math.Pow(Radius, 2);
 }
}

public class Rectangle : Shape
{
 public double Length { get; set; }
 public double Width { get; set; }

 public override double CalculateArea()
 {
   return Length * Width;
 }
}

In this refactored code, we define an abstract Shape class with an abstract CalculateArea() method. Concrete shape classes (Circle and Rectangle) inherit from the Shape class and provide their own implementations of CalculateArea().

Adding a new shape, such as a triangle, would involve creating a new class – extending the codebase – that inherits from Shape and implements CalculateArea(), without modifying existing code. This adheres to the OCP by allowing for extension without modification.

Being able to add functionality without modifying existing code means that we don’t have to worry as much about breaking existing working code and introducing bugs.

Following the OCP encourages us to design our software so that we add new features only by adding new code. This helps us to build loosely-coupled, maintainable software.

Liskov Substitution Principle (LSP) in C

Objects of a superclass should be replaceable with objects of its subclass without affecting the correctness of the program.

This principle ensures that inheritance hierarchies are well-designed and that subclasses adhere to the contracts defined by their superclasses.

Violations of the LSP can lead to unexpected behavior or errors when substituting objects, making code harder to reason about and maintain.

Let's consider an example involving a Rectangle class and a Square class, which inherit from a common Shape class. Initially, we'll violate the LSP by not adhering to the behavior expected from these classes. Then, we'll fix it to ensure that the principle is respected.

public abstract class Shape
{
 public abstract double Area { get; }
}

public class Rectangle : Shape
{
 public virtual double Width { get; set; }

 public virtual double Height { get; set; }

 public override double Area => Width * Height;
}

public class Square : Rectangle
{
 public override double Width
 {
   get => base.Width;
   set => base.Width = base.Height = value;
 }

 public override double Height
 {
   get => base.Height;
   set => base.Height = base.Width = value;
 }
}

Now, let’s test out if Rectangle calculates its area correctly:

// Program.cs

var rect = new Rectangle();
rect.Height = 10;
rect.Width = 5;

System.Console.WriteLine("Expected area = 10 * 5 = 50.");

System.Console.WriteLine("Calculated area = " + rect.Area);

Running the program:

Expected area = 10 * 5 = 50.

Calculated area = 50

Perfect!

Now, in our program, the Square class inherits from, or extends, the Rectangle class, because, mathematically, a square is just a special type of rectangle, where its height equals its width. Because of this, we decided that Square should extend Rectangle – it’s like saying “a square is a (special type of) rectangle”.

But look what happens if we substitute the Rectangle class for the Square class:

var rect = new Square();
rect.Height = 10;
rect.Width = 5;

System.Console.WriteLine("Expected area = 10 * 5 = 50.");

System.Console.WriteLine("Calculated area = " + rect.Area);

Expected area = 10 * 5 = 50.

Calculated area = 25

Oh dear, LSP has been violated: we replaced the object of a superclass (Rectangle) with an object of its subclass (Square), and it affected the correctness of our program. By modeling Square as a subclass of Rectangle, and allowing width and height to be independently set, we violate the LSP. When setting the width and height of a Square, it should retain its squareness, but our implementation allows for inconsistency.

Let’s fix this to satisfy LSP:

public abstract class Shape
{
 public abstract double Area { get; }
}

public class Rectangle : Shape
{
 public double Width { get; set; }

 public double Height { get; set; }

 public override double Area => Width * Height;
}

public class Square : Shape
{
 private double sideLength;

 public double SideLength
 {
   get => sideLength;
   set
   {
     sideLength = value;
   }
 }

 public override double Area => sideLength * sideLength;
}

// Program.cs

Shape rectangle = new Rectangle { Width = 5, Height = 4 };

Console.WriteLine($"Area of the rectangle: {rectangle.Area}");

Shape square = new Square { SideLength = 5 };

Console.WriteLine($"Area of the square: {square.Area}");

In this corrected example, we redesign the Square class to directly set the side length. Now, a Square is correctly modeled as a subclass of Shape, and it adheres to the Liskov Substitution Principle.

How does this satisfy LSP? Well, we have a superclass, Shape, and subclasses Rectangle and Square. Both Rectangle and Square maintain the correct expected behavior of a Shape — we can substitute a square for a rectangle and the area will still be calculated correctly.

Interface Segregation Principle (ISP) in C

Clients should not be forced to depend on interfaces they do not use.

This principle encourages the creation of fine-grained interfaces that contain only the methods required by the clients that use them. It helps to prevent the creation of "fat" interfaces that force clients to implement unnecessary methods, leading to cleaner and more maintainable code.

Let's consider an example involving 2D and 3D shapes, initially violating the ISP.

Violating ISP:

public interface IShape
{
 double Area();
 double Volume(); // problem: 2D shapes don't have volume!
}

public class Circle : IShape
{
 public double Radius { get; set; }

 public double Area()
 {
   return Math.PI * Math.Pow(Radius, 2);
 }

 public double Volume()
 {
   throw new InvalidOperationException("Volume not applicable for 2D shapes.");
 }
}

public class Sphere : IShape
{
 public double Radius { get; set; }

 public double Area()
 {
   return 4 * Math.PI * Math.Pow(Radius, 2);
 }

 public double Volume()
 {
   return (4.0 / 3.0) * Math.PI * Math.Pow(Radius, 3);
 }
}

In this example, we have an IShape interface representing both 2D and 3D shapes. However, the Volume() method is problematic for 2D shapes, like Circle and Rectangle, because they don't have volume. This violates the ISP because clients (classes using the IShape interface) may be forced to depend on methods they do not need.

var circle = new Circle();
circle.Radius = 10;

System.Console.WriteLine(circle.Area());
System.Console.WriteLine(circle.Volume()); // My text editor doesn't flag a problem...

var sphere = new Sphere();
sphere.Radius = 10;

System.Console.WriteLine(sphere.Area());
System.Console.WriteLine(sphere.Volume());

Usually, if I try to call a method on an object that doesn’t exist, VS Code will tell me that I’m making a mistake. But above, when I call circle.Volume(), VS code is like “no problem”. And VS code is correct, because the IShape interface forces Circle to implement a Volume() method, even though circles don’t have volume.

It’s easy to see how violating ISP can introduce bugs into a program – above, everything looks fine, until we run the program and an exception gets thrown.

Fixing ISP

public interface IShape2D
{
 double Area();
}

public interface IShape3D
{
 double Area();
 double Volume();
}

public class Circle : IShape2D
{
 public double Radius { get; set; }

 public double Area()
 {
   return Math.PI * Math.Pow(Radius, 2);
 }
}

public class Sphere : IShape3D
{
 public double Radius { get; set; }

 public double Area()
 {
   return 4 * Math.PI * Math.Pow(Radius, 2);
 }

 public double Volume()
 {
   return (4.0 / 3.0) * Math.PI * Math.Pow(Radius, 3);
 }
}

In the fixed example, we've segregated the IShape interface into two smaller, more focused interfaces: IShape2D and IShape3D. Each shape class now implements only the interface that is relevant to its functionality.

This adheres to the Interface Segregation Principle by ensuring that clients are not forced to depend on methods that they do not use. Clients can now depend only on the interfaces that they need, promoting better code reuse and flexibility.

Next up, the fifth and final SOLID principle…

Dependency Inversion Principle (DIP) in C

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

Dependency Inversion is the strategy of depending upon interfaces or abstract classes rather than upon concrete classes. This principle promotes decoupling between modules and promotes the use of interfaces or abstract classes to define dependencies, allowing for more flexible and testable code.

Let's start with an example violating the DIP and then we’ll correct it.

public class Engine // Engine is our "low-level" module
{
 public void Start()
 {
   System.Console.WriteLine("Engine started.");
 }
}

public class Car // Car is our "high-level" module
{
 private Engine engine;

 public Car()
 {
   this.engine = new Engine(); // Direct dependency on concrete Engine class
 }

 public void StartCar()
 {
   engine.Start();
   System.Console.WriteLine("Car started.");
 }
}

In this example:

• The Car class directly creates an instance of the Engine class, leading to a tight coupling between Car and Engine.

• If the Engine class changes, it may affect the Car class, violating the Dependency Inversion Principle.

The UML diagram below shows that Car depends on Engine:

But what do we mean by “high level” and “low level” classes?

High-Level Class: The high-level class is typically the one that represents the main functionality or business logic of the application. It orchestrates the interaction between various components and is often more abstract in nature.

In this example, the Car class can be considered the high-level class. It represents the main functionality related to starting the car and driving it. The Car class is concerned with the overall behavior of the car, such as controlling its movement.

Low-Level Class: The low-level class is usually one that provides specific functionality or services that are used by the high-level class. It typically deals with implementation details and is more concrete in nature.

In this example, the Engine class can be considered the low-level class. It provides the specific functionality related to starting the engine. The Engine class encapsulates the details of how the engine operates, such as ignition and combustion.

So in summary, the Car class is the high-level class, representing the main functionality of the application related to the car's behavior.

The Engine class is the low-level class, providing specific functionality related to the operation of the engine, which is used by the Car class.

Fixing DIP:

To adhere to the Dependency Inversion Principle, we introduce an abstraction (interface) between Car and Engine, allowing Car to depend on an abstraction instead of a concrete implementation.

public interface IEngine
{
 void Start();
}

public class Engine : IEngine
{
 public void Start()
 {
   System.Console.WriteLine("Engine started.");
 }
}

public class Car
{
 private IEngine engine;

 public Car(IEngine engine)
 {
   this.engine = engine;
 }

 public void StartCar()
 {
   engine.Start();
   System.Console.WriteLine("Car started.");
 }
}

We can now inject any type of engine into Car implementations:

var engine = new Engine(); // concrete implementation to be "injected" into the car

var car = new Car(engine);

car.StartCar();

From the UML diagram below, we can see that both objects now depend on the abstraction level of the interface. Engine has inverted its dependency on Car.

In this corrected example:

1. We define an interface IEngine representing the behavior of an engine.

2. The Engine class implements the IEngine interface.

3. The Car class now depends on the IEngine interface instead of the concrete Engine class.

4. Dependency injection is used to inject the IEngine implementation into the Car class, promoting loose coupling. Now, if we want to give a car a different type of engine, for example a FastEngine, we can inject that in instead.

5. Now, if the implementation of the engine changes, it won't affect the Car class as long as it adheres to the IEngine interface.

Dependency Injection (DI) offers several advantages in software development:

• Decoupling: DI promotes loose coupling between components by removing direct dependencies. Components rely on abstractions rather than concrete implementations, making them more independent and easier to maintain.

• Testability: Dependency injection simplifies unit testing by allowing components to be easily replaced with mock or stub implementations during testing. This enables isolated testing of individual components without relying on their dependencies.

• Flexibility: DI provides flexibility in configuring and swapping dependencies at runtime. It allows different implementations of dependencies to be used interchangeably without modifying the client code, facilitating runtime customization and extensibility.

• Readability and Maintainability: By explicitly specifying dependencies in the constructor or method parameters, DI improves code readability and makes the codebase easier to understand. It also reduces the risk of hidden dependencies, leading to more maintainable and understandable code.

• Reusability: DI promotes component reusability by decoupling them from their specific contexts or environments. Components can be designed to be independent of the application framework or platform, making them more portable and reusable in different projects or scenarios.

• Scalability: DI simplifies the management of dependencies in large-scale applications by providing a standardised approach for dependency resolution. It helps prevent dependency hell and makes it easier to manage and scale complex systems.

Overall, dependency injection enhances modularity, testability, and maintainability of software systems, contributing to improved software quality and developer productivity.

Conclusion

Congratulations – you now understand the extremely important SOLID principles. These principles are going to save you a lot of headaches during your software development career, and guide you towards creating beautiful, maintainable, flexible, testable software.

If you’d like to take your software development skills to the next level and learn:

• OOP principles: encapsulation, abstraction, inheritance, polymorphism, coupling, composition, composition vs inheritance, fragile base class problem.

• All 23 design patterns (“The Gang of Four Design Patterns”) with real world examples.

• Unified Modeling Language (UML): the standard way to model classes and the relationships between them.

Then check out my book:

Mastering Design Patterns in C#: A Beginner-Friendly Guide, Including OOP and SOLID Principles on Amazon (also available on Gumroad).

Hopefully this article helps you to become a better OOP software developer!

Thanks for reading,

Danny 😎

Object-relational mapping, as a programming concept, is an efficient standard protocol for facilitating seamless connection with databases. But what does it really mean, and how do you set it up as a developer? We’ll answer these questions and highlight more about object-relational mapping.

Here are the prerequisites:

• Knowledge of Node.js

• Use the Express framework

• An installed MySQL database

Table of Contents

• Table of Contents

• What is an ORM?

• How to Set Up Your Node.js Server

• How to Integrate Relevant Packages

• Demo Project

• Additional Information

What is an ORM?

Object Relational Mapping (ORM) is a database communication concept in programming that involves the abstraction of data types as compatible object-oriented programming variables. It simply eliminates the use of database-defined queries and storage types to allow ease of creating databases via the programming languages.

Its use has been widely adopted in the tech space as has more advantages than conventional database query methods. Here are some of them:

• It reduces the risk of data manipulation: SQL and non-SQL injections involve inputting malicious SQL syntaxes and queries into the database, which can compromise database security. Having an ORM in place adds an input validation scheme feature, and details the expected input variable syntax and processes it accordingly.

• Ease of database communication: ORM serves to simplify the use of databases as a data tool without undergoing the process of learning a different database query language. The ORM schema can be highlighted in an object-oriented fashion in the application language and can be configured to automatically translate the code to queries compatible with the database.

• This feature also allows easy code portability, achieving maintenance of a single database integration code base while changing the database without any adverse outcome. It is highly flexible and can be used in any database of choice.

• It also has additional features included to allow database interactions. Database migration features and version control processes are provided. With these, we have seen some of its benefits, we will then highlight popular ORM tools used globally.

Here are the popular ORM tools:

• SQLAlchemy

• Prisma ORM

• Sequelize

• ActiveRecord

• TypeORM

• Waterline

For this article, we’ll be streamlining our ORM use cases to a basic Node.js project linked to a MySQL database. We’ll use the Sequelize ORM as the tool of choice.

With an average package download of 8.5 million monthly and an active development community, Sequelize boasts robust features that seamlessly integrate databases with backend applications. It also provides a user oriented documentation which helps guide the user on setting up and using the tool.

Here is a link to the documentation. It also offers support for MySQL, DB2, and SQLite Microsoft SQL server, and it offers features such as read replication, lazy loading, and efficient database transaction properties.

Next, we’ll set up our web application and install Sequelize to connect us to a MySQL database hosted locally.

How to Set Up Your Node.js Server

In this section you’ll set up our Node server. Navigate to the command line and execute npm init. This command creates a new Node project structure for you.

Next, install the Express package – this will serve as the backend framework. You can do this by running the npm i express command.

How to Integrate Relevant Packages

For the purpose of this tutorial, we’ll install the Sequelize Node package manager in our Node application in order to set up the ORM communication to the database.

To set this up, execute npm i sequelize.

We’ll use a locally hosted MySQL database. To do this, we’ll install an npm package database driver. In this case, we will be installing mysql2. Here is a link to the package

Run npm i mysql2 to install it.

Let’s move on to configuring the connection to the database and building our demo project.

Demo Project

In this section we’ll build a simple backend server that performs Create-Read-Update-Delete operations, with the Sequelize library serving as the connection pipeline.

In order to begin the project, we’ll have to set up the database connection for our application. We’ll create a database connection file and set up our database credentials. You can name the file SequelizeConfig.

module.exports = {

    HOST: "localhost",

    USER: "root",

    PASSWORD: "",

    DB: "sequel",

    dialect: "mysql"

}

In the code above, the database credentials were specified, along with the host address. In our case, the database is locally hosted, so localhost is the default host.

The database login details were also provided. The user here is the root, while the password was set to an empty string. This should be tweaked to ensure database security. I also created a defunct database named “sequel”.

The dialect refers to the type of database the user intends to use. In our case, the dialect is MySQL. Note that this can also be replicated on a cloud hosted database with the credentials obtained. With that, let's integrate the connection file with the application.

const SequelConfig = require('../config/sequelize');

const Sequelize = require('sequelize');

const sequelize = new Sequelize(SequelCOnfig.DB, SequelCOnfig.USER, SequelCOnfig.PASSWORD, {

    host: SequelCOnfig.HOST,

    dialect: SequelCOnfig.dialect

});

In order to facilitate a connection to the database, the variables in the config file were imported and initialized in the Sequelize setup file.

const db = {};

db.Sequelize = Sequelize;

db.sequelize = sequelize;

db.user = require('../model/user.model')(sequelize, Sequelize);

db.token = require('../model/token.model')(sequelize, Sequelize)

module.exports= db;

This file above imports the config file created previously and initializes the Sequelize library. The code then fetches the database details inputted in the config file and, when executed, creates the database.

Furthermore, the various database models which will be discussed subsequently are then integrated with the defunct database and generates a SQL database table .

To get this up and running, the database file created is invoked using the sequelize.sync() method. Any error encountered is logged and the database connection gets terminated.

db.sequelize.sync().then(() => {

  console.log('user created ');

}).catch(err => {

  console.error(err)

})

We’ll go on to discuss the database models.

Models

const Sequelize = require("sequelize");

module.exports = (sequelize) => {

sequelize.define(

"user", {

firstName: {

type : Sequelize.DataTypes.STRING,

allowNull : false

},

lastName: {

type : Sequelize.DataTypes.STRING,

allowNull : false

},

email : {

type : Sequelize.DataTypes.STRING,

allowNull : false, unique: true

},

password: {

type : Sequelize.DataTypes.STRING,

allowNull : false

},

role:  {

type : Sequelize.DataTypes.STRING,

allowNull : false

}

}

)

}

In the code above, the user model was initialized in Sequelize ORM and the field details were specified: email, role, lastName, and password. The type of data to be received was also specified.

It also provides an option to ensure the uniqueness of the user details, and the option to prevent the user from leaving some fields empty via the use of allowNull = false.

On execution of the application, the Sequelize ORM creates an SQL equivalent of the model as a data table.

Next, we’ll work on the CRUD functions in Node.js.

Create Operation

const createUser = async (userInfo) => {

try {

// Check if the email already exists in the database

const ifEmailExists = await User.findOne({ where: { email: userInfo.email } });

if (ifEmailExists) {

throw new ApiError('Email has already been registered');

}

// Create the new user

const newUser = await User.create(userInfo);

return newUser; // Return the created user object

} catch (error) {

// Handle errors such as validation or uniqueness constraint

throw error;

}

};

The function above highlights the controller function for creating user entries in the Express server.

The function is asynchronous, which allows for execution of some commands before eventual execution. The code ensures that the user email doesn’t exist in the database before cresting a new user.

In addition, we also ensured that each email field is unique. If the user details are entered into the database successfully, a “successful” response is sent back to the server. Additionally, any error encountered leads to termination of the function and the error gets sent back to the server.

Read Operation

const FetchUser = async (userId) => {

let userDets;

if (userId) {

// Fetch a single user by ID if userId is provided

userDets = await User.findOne({ where: { id: userId } });

// Check if the user exists

if (!userDets) {

throw new ApiError(httpStatus.NOT_FOUND, 'User not found');

}

} else {

// Fetch all users if no userId is provided

userDets = await User.findAll();

// Check if any users were found

if (userDets.length === 0) {

throw new ApiError(httpStatus.NOT_FOUND, 'No users found');

}

}

The read operation fetches the desired query and sends it back to the user without modification. The user ID, which should be unique, is used to search for a specific user. In this scenario, we want access to all the users created in the database.

In case the requested query is not found, an appropriate error code is generated.

Update Operation

const updateUser = async (userId, userDetails) => {

// First, find the user by their ID

const user = await User.findOne({ where: { id: userId } });

if (!user) {

throw new ApiError(httpStatus.BAD_REQUEST, "User doesn't exist");

}

// Update the user with the new details

await User.update(userDetails, { where: { id: userId } });

// Fetch the updated user to return it

const updatedUser = await User.findOne({ where: { id: userId } });

console.log('Updated user:', updatedUser); // Log the updated user

return updatedUser; // Return the updated user object

};

The update operation aims to modify the data entered in previous operations. That is, to update some data fields.

In the case of Sequelize, the update method is invoked. To succeed with this, the particular user to be edited must be identified. The code above then generates the updated data field and sends it as the output of a successful request.

Delete Operation

const deleteUser = async (userId) => {

const user = await User.findOne({ where: { id: userId } });

if (!user) {

throw new ApiError(httpStatus.BAD_REQUEST, "User doesn't exist");

}

// Delete the user

await user.destroy();

console.log('Deleted user:', user); // Log the deleted user

return user; // Return the deleted user object (useful for confirmation)

};

The delete operation is invoked when data in the database table needs to be deleted. Sequelize makes provision for this via the use of the destroy method. This method deletes a specific user. When executed, a success response code is displayed.

Additional Information

So far, we have integrated an ORM library to serve as a connection between our backend application and our relational database. We also explored advanced concepts such as database migrations and CRUD operations. To learn more about this, you can explore the documentation and utilize it in building more complex projects, as hands-on learning is much encouraged.

Feel free to reach out to me on my blog and check out my other articles here. Till next time, keep on coding!

To get the most out of this guide, you should have a background in JavaScript, understand how Mongoose works, and know Object-Oriented Programming basics.

Here's what we'll cover:

1. What is a Mongoose Schema?

2. Discriminator

3. Statics

4. Methods

5. Query Builder

6. Hooks

7. Summary

What is a Mongoose Schema?

Mongoose schemas provide a structured way to model data in a MongoDB database, allowing you to define the properties and behavior of the documents. Schemas serve as a blueprint for a document that gets saved in the database. They enables developers to enforce data integrity and work with MongoDB in a more intuitive and organized manner.

Within a MongoDB collection, a schema outlines the fields of the documents, their data types, validation rules, default values, constraints, and more.

Programmatically, a Mongoose schema is a JavaScript object. Actually, it is an instance of a built-in class called Schema inside the mongoose module. For this reason, you can add more methods to its prototype. This will help you implement many features as middleware, methods, statics, and more. You will learn about some of them in this tutorial.

Features you'll learn how to implement:

• Discriminator

• Statics

• Methods

• Query Builder

• Hooks

Discriminator

A discriminator is a feature that enables you to create multiple models (subtypes) that inherit from a base model (parent). This happens by defining a base schema and then extending it with extra fields specific to each subtype or each child schema.

All documents, regardless of their specific model, are stored in the same MongoDB collection. This keeps your data organized in a single collection while allowing for flexible querying and data management. Also, each document includes a special field that indicates its specific model type, allowing Mongoose to distinguish between the different subtypes.

How to use discriminator:

1. Start by defining a base schema, which will have the common fields among the subtypes. After that, create a model from it.

    import mongoose from 'mongoose';
   
    const baseSchema = new mongoose.Schema({
        name: { type: String, required: true },
    }, { discriminatorKey: 'kind' }; // defaults to '__t');
   
    const BaseModel = mongoose.model('Base', baseSchema);
   

2. Create the subtypes that extend the base schema by defining the discriminator for each one.

    const catSchema = new mongoose.Schema({
        meow: { type: Boolean, default: true }
    });
    // subtype
    const Cat = BaseModel.discriminator('Cat', catSchema);
   
    const dogSchema = new mongoose.Schema({
        bark: { type: Boolean, default: true }
    });
    // subtype
    const Dog = BaseModel.discriminator('Dog', dogSchema);
   

3. You can then create documents in the regular way. All the documents will be stored in the same collection, but each has its own type depending on its subtype model.

    const fluffy = await Cat.create({ name: 'Fluffy' });
    const rover = await Dog.create({ name: 'Rover' });
   

discriminator use case:

Let's say that you're building a multi-user Ecommerce web application which accommodates three main user roles: admins, clients, and sellers. Each of these roles plays a crucial part in the ecosystem of online shopping.

If you try to build a class for each role, you'll find that all the three have common fields and methods. You may decide to create a parent schema (user) and some other children schemas (client, seller, admin) that inherit from it.

You can use the discriminator to achieve this.

In your user.model.js file, add the following code:

import mongoose from "mongoose";

const userSchema = mongoose.Schema(
  {
    name: String,
    profilePic: String,
    email: String,
    password: String,
    birthDate: Date,
    accountAcctivated: { type: Boolean, default: false },
  },
  {
    timestamps: true,
    discriminatorKey: "role",
  }
);

const User = mongoose.model("User", userSchema);
export default User;

Now you have the base model (User) from which other subtypes will inherit. In this parent schema, you define the common fields that all users will share regardless of their roles.

In your client.model.js file:

import mongoose from "mongoose";
import User from "./user.model.js";

const clientSchema = mongoose.Schema(
  {
    products: Array,
    address: String,
    phone: String,
  }
);

const Client = User.discriminator("Client", clientSchema);
export default Client;

In your seller.model.js file:

import mongoose from "mongoose";
import User from "./user.model.js";

export const sellerSchema = mongoose.Schema(
  {
    rating: Number,
    businessType: { type: String, enum: ["individual", "corporation"] },
  }
);

const Seller = User.discriminator("Seller", sellerSchema);
export default Seller;

In your admin.model.js file:

import mongoose from "mongoose";
import User from "./user.model.js";

export const adminSchema = mongoose.Schema(
  {
    permissions: Array,
    assignedTasks: Array,
    department: String,
  }
);

const Admin = User.discriminator("Admin", adminSchema);
export default Admin;

The subtypes or children will be the Client, Seller, and Admin. In each subtype schema, you should add any extra fields or behaviors specific to this subtype only. By creating the child model using the discriminator, the child model will inherit all the fields and methods of its parent model User.

So the previous code will create a user collection in the database with each document having a role field either Client, or Seller, or Admin. All documents are now sharing the parent (user) fields, and depending on the role of each document, each has another extra field.

Although all the documents will be saved in one single collection, models are fully separated while coding. What does this mean?

For instance, If you need to retrieve all clients from the User collection, you should write Client.find({}). This statement uses the discriminator key to find all documents whose role is Client. This way, any operations or queries that refer to one of the child models will still be written separately from the parent model.

Note: Before diving into the next sections, just keep in mind that any statics, methods, query builders, or hooks should be defined before creating the model itself (that is, before const User = mongoose.model("User", userSchema);).

Statics

Statics are useful for defining functions that operate on the model level. They allow you to define reusable functions for operations related to the entire model. They help encapsulate logic that applies to the model rather than individual documents, making your code cleaner, more organized and maintainable

Methods like find, findOne, findById and others all are methods attached to the model. By using the statics property of Mongoose schemas, you will be able to build your own model method.

Statics are powerful. By using them, you can encapsulate complex queries that you might want to reuse. Also, you can create statics for operations that modify or aggregate data, such as counting documents or finding documents based on specific criteria.

statics use case

Statics are easy to build. You define a static method on your schema using the statics object.

In your user.model.js file, add these static methods, countUsers and findByEmail:

// model method
userSchema.statics.countUsers = function () {
    return this.countDocuments({});
};

// model method
userSchema.statics.findByEmail = async function (email) {
  return await this.findOne({ email });
};

Inside any static method, this refers to the model itself. In this example, this in this.findOne({ email }) refers to the User model.

Example usage:

const user = await User.findByEmail("foo@bar.com");
//or
const client = await Client.findByEmail("foo@bar.com");
//or
const seller = await Seller.findByEmail("foo@bar.com");
//or
const admin = await Admin.findByEmail("foo@bar.com");

When you call the static method on your model, the method gets called and this is replaced by the model you called the statics on. This line performs a query to find a single document in the MongoDB collection where the email field matches the provided email argument.

Methods

Methods are functions that you can define on a schema and that can be called on instances of documents created from this schema. They help encapsulate logic within the document itself, making your code cleaner and more modular.

By using instance methods, you can easily interact with and manipulate the data associated with specific documents.

methods use case

You can define methods on the schema using the methods object.

In your user.model.js file, add a document method through which you can check the password of a user:

// instance or document method
userSchema.methods.getProfile = function () {
    return `${this.name} (${this.email})`;
};

// instance or document method
userSchema.methods.checkPassword = function (password) {
    return password === this.password ? true : false;
};

Inside any document method, this refers to the document itself. In this example, this in this.password refers to the user document at which the method will get called on. This means that you can access all the fields of this document. This is so valuable because you can retrieve, modify, and check for anything related to this document.

Example usage:

const client = await Client.findById(...)
client.checkPassword("12345")
//or
const seller = await Seller.findById(...)
seller.checkPassword("12345")
//or
const admin = await Admin.findById(...)
admin.checkPassword("12345")

Since methods are instance-level functions, they are called on the documents. await Client.findById(...) will return a document that has all the built-in methods as well as your own predefined methods checkPassword and getProfile. So by calling, for example client.checkPassword("12345"), the this keyword in the checkPassword function definition will get replaced with the client document. This in turn will compare the user password with the password saved earlier in the database.

Query Builder

A query builder in Mongoose is a custom method that you can define on the query object to simplify and encapsulate common query patterns. These query builders allow you to create reusable and readable query logic, making it easier to work with your data.

One of the most valuable usages of query builders is chaining. They can be chained with other query builders that you've built or with standard query methods like find, sort, and so on.

Query builder use case

You define query builders by adding them to the query property of a Mongoose schema.

In your user.model.js file, add a query helper method that lets you implement pagination.

// query helper
userSchema.query.paginate = function ({ page, limit }) {
    // some code
    const skip = limit * (page - 1);
    return this.skip(skip).limit(limit);
};

To implement pagination, you need two important variables: first, the page number, and second, the number of items you will retrieve per page.

To query the database for a specific count of documents, you will always use the skip and limit built-in query methods in mongoose. skip is used to set a cursor after a certain number of documents, after which the query will get implemented. limit is used to retrieve a specific number of documents.

Inside any query builder method, this refers to the query itself. And since query builders are chainable, you can call any of them after each other.

Finally, any query builder method should return a mongoose query object, which is why you must write return this.skip(skip).limit(limit).

Example usage:

const results = await Client.find().paginate({ page: 2, limit: 5 });
//or
const results = await Seller.find().paginate({ page: 2, limit: 5 });
//or
const results = await Admin.find().paginate({ page: 2, limit: 5 });

You can then call it on any query, and await Client.find().paginate({ page: 2, limit: 5 }) will invoke the paginate function and replace the this keyword with Client.find() using the query builder.

You can implement pagination with certain conditions, but you'll always call skip and limit. By defining the paginate query builder you won't repeat yourself and you'll be able to encapsulate the logic in one single function.

Hooks

Hooks (also known as middleware) are functions that are executed at specific points in the lifecycle of a document. They allow you to add custom behavior before or after certain operations, such as saving, updating, or removing documents.

Types of Hooks

• Pre Hooks: Executed before an operation.

• Post Hooks: Executed after an operation.

Hooks use case

In your user.model.js file, add a post save middleware through which you can send an email for account activation once the user document is saved in the database.

// post hook
userSchema.post("save", async function (doc, next) {
  // send email logic
  // if succeeded
  return next();
  // if failed
  return next(new Error("Failed to send email!"));
});

The callback function will get invoked once you create a user through model.create() or any time you call save() method on the user document.

In this this example, if you need to avoid sending emails on save, you should write a condition to be sure that this save is for a new user only. You can write something like if (doc.createdAt.getTime() === doc.updatedAt.getTime()).

Summary

In this overview of Mongoose features, we've explored four key concepts: discriminators, statics, methods, and hooks.

Discriminators allow you to create multiple models that share a common schema enabling different document types to be stored in a single collection. This facilitates data management and querying.

Statics are model-level methods that provide reusable functionality applicable to the entire model. They encapsulate complex queries and data manipulation logic, helping to keep your codebase clean and maintainable.

Methods are instance-level functions that operate on individual document instances. They allow for custom behaviors and data manipulations specific to each document, so you can modify the document’s data in a specific way, such as formatting or calculating values based on its fields.

Hooks (or middleware) enable you to run functions at specific points in the document lifecycle, such as before or after saving, updating or deleting a document. This is useful for implementing validation, logging, or any other side effects related to database operations.

Together, these features enhance the versatility and organization of your Mongoose models, making it easier to build robust and maintainable applications with MongoDB.

Here can will find a repository where you can learn more about Mongoose schemas and use cases.

Object-oriented programming is one such paradigm, where the code is organized as objects.

It is used to develop desktop and mobile applications or more complex web or enterprise applications.

Using object-oriented programming, you can build modular and scalable software that is easy to maintain.

In this article, you will learn about the principles of object-oriented Programming that lay the foundation for building robust systems.

We will use Java as the programming language for the examples provided below.

What is Object-Oriented Programming?

Object-Oriented Programming is a programming methodology that models real-world entities in the form of objects.

These objects are instances of classes.

A class can be thought of as a blueprint and each class can contain fields, which define the attributes of the object, and methods, which describe the object's behavior. Each class can be developed, tested, and debugged independently.

Now that you have an understanding of the basic definition of object-oriented programming, let us jump right in and learn about its core principles.

There are four core principles, or pillars, in the object-oriented Programming paradigm. They are:

• Abstraction
• Encapsulation
• Inheritance
• Polymorphism

What do they mean? Let us explore further with a simple explanation followed by an example for each of them in the following sections.

What is Abstraction?

Abstraction is defined as the concept of hiding the details of implementation and exposing only the necessary functionalities of the object to the user.

The keywords that you need to keep in mind here are: 'Implementation hiding'.

Abstraction in Java can be achieved through Interfaces and Abstract classes.

abstract class Animal {
    public abstract void makeSomeNoise();
}

class Dog extends Animal {
    public void makeSomeNoise() {
        System.out.println("Bark");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.makeSomeNoise(); // Output - Bark
    }
}

In the above example, abstraction is achieved with the help of an abstract class named Animal.

Here, only the necessary functionality of the class is exposed via the makeSomeNoise() method.

The details of implementation are hidden in the abstract class and they are only provided in the concrete class Dog, which extends the Animal class.

Note that you will learn more about the extends keyword while we discuss Inheritance.

What is Encapsulation?

Encapsulation refers to the concept of encapsulating or wrapping up the member variables (data) and the methods (behavior) of an object into a single unit, such as a class.

The internal information of the object is hidden so that we can prevent unintended modifications and allow only controlled access. The keywords that you need to keep in mind here are: 'Information hiding'.

Encapsulation in Java is achieved through access modifiers. We mark the fields as private and make them accessible via public setter and getter methods.

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public void display() {
        System.out.println("Name: " + name + ", Age: " + age);
    }
}

public class Main {
    public static void main(String[] args) {
        Person person = new Person("Raj", 30);
        person.display(); // Output - Name: Raj, Age: 30

        person.setName("Kumar");
        person.setAge(25);
        person.display(); // Output - Name: Kumar, Age: 25
    }
}

In the above example, the fields and methods are encapsulated within a class named Person.

You declare the fields name and age as private and provide public setter and getter methods getName(), setName(), getAge(), and setAge() to modify the values as needed.

What is Inheritance?

Inheritance establishes a hierarchical relationship between two classes.

In this concept, one class inherits the fields (properties) and methods (behavior) of another class, while having properties and behavior of its own.

The class that inherits from another is called a subclass, derived class, or child class. The class from which the subclass inherits is known as the superclass, base class, or parent class.

In Java, inheritance is achieved using the extends keyword.

class Animal {
    public void makeSomeNoise(){
        System.out.println("Make some animal noise");
    }
}

class Dog extends Animal {
    public void makeSomeNoise() {
        System.out.println("Bark");
    }
    public void doSomething(){
        System.out.println("Play with ball");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog myDog = new Dog();
        myDog.makeSomeNoise(); // Output - Bark
        myDog.doSomething(); // Output - Play with ball
    }
}

In the above example, the extends keyword indicates that the Dog class is the subclass of the Animal class.

The Dog class inherits the makeSomeNoise() method from the Animal class. This allows the Dog class to reuse the method and provide its own implementation without having to rewrite it completely.

You can also note that the Dog class has its own behavior through the doSomething() method.

Inheritance defines an "IS-A" relationship between the two classes. In our example, Dog IS-A Animal.

Note that Java supports multi-level inheritance. For example, class Labrador inherits from class Dog, which in turn inherits from class Animal. However, it does not support multiple inheritance. That is, a class is not allowed to inherit from two or more parent classes.

What is Polymorphism?

Poly (many), morph (forms).

Polymorphism defines the capability of an object to be represented in different forms.

In Java, polymorphism can be categorized into two types: compile-time polymorphism and runtime polymorphism.

Compile-time polymorphism is achieved through method overloading – multiple methods have the same name but different type or number of parameters.

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

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

public class Main {
    public static void main(String[] args) {
        MathOperation math = new MathOperation();
        System.out.println(math.add(95, 5));       // Output - 100
        System.out.println(math.add(75, 5, 20));   // Output - 100
    }
}

In the above example, we have overloaded the add() method. There are two methods with the same name add but they have different number of parameters.

During compilation, based on the number of parameters passed to the method, the appropriate call is made.

Runtime polymorphism is achieved through method overriding – a subclass has a method with the same name and same set of parameters as that of its superclass method. However, it provides its own implementation of the method.

Here, the method resolution happens at runtime.

class Animal {
    public void makeSomeNoise() {
        System.out.println("Make some animal noise");
    }
}

class Dog extends Animal {
    @Override
    public void makeSomeNoise() {
        System.out.println("Barks");
    }
}

class Cat extends Animal {
    @Override
    public void makeSomeNoise() {
        System.out.println("Meows");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal myAnimal; 

        myAnimal = new Dog(); 
        myAnimal.makeSomeNoise(); // Output - Barks

        myAnimal = new Cat(); 
        myAnimal.makeSomeNoise(); // Output - Meows
    }
}

In the above example, the makeSomeNoise() method of the Animal class is overridden by the Dog and Cat subclasses and they provide their own implementation of this method.

During object creation, the Animal variable holds a Dog or Cat object and when the makeSomeNoise() method is called, the appropriate overridden method is called based on the actual object type.

Conclusion

In this article, we explored the fundamental principles of Object-Oriented Programming (OOP).

Familiarity with these concepts is crucial for building robust, maintainable, and scalable software systems.

• Inheritance
• Encapsulation
• Polymorphism
• Abstraction

Whether you're a seasoned programmer or a beginner stepping into the world of C#, this article aims to enhance your understanding of OOP concepts and their implementation in C#.

If you're new to C#, consider taking the free certification course on freeCodeCamp or the free course on Microsoft Learn to familiarize yourself with the language.

Remember, the principles of OOP are universal and apply to most object-oriented programming languages. Therefore, the knowledge you gain from this article can be applied to learning OOP in any language.

Let's get started!

Table of Contents

2. What is Object-Oriented Programming (OOP)

3. Why Use Object-Oriented Programming?

4. The Four Pillars of Object-Oriented Programming

5. Inheritance

6. Types of Inheritance

7. Encapsulation

8. Polymorphism

9. Abstraction

10. Summary

What is Object-Oriented Programming (OOP)

Object-Oriented Programming (OOP) is a programming paradigm that uses objects and classes to design and develop software applications. It is based on the concept of objects, which can contain data in the form of fields (attributes or properties) and code in the form of procedures (methods or functions).

Object-Oriented Programming offers several benefits, including:

• Modularity: OOP promotes modularity by breaking down complex systems into smaller, manageable parts (objects). This makes it easier to maintain and update the code.

• Reusability: OOP allows you to reuse existing code by creating new objects based on existing ones. This saves time and effort in developing new applications.

• Flexibility: OOP provides flexibility in designing and implementing software systems. You can easily modify and extend the functionality of objects without affecting other parts of the system.

• Scalability: OOP supports scalability by allowing you to add new objects and classes as the system grows. This makes it easier to accommodate changes and enhancements in the software.

As you can see, OOP offers several advantages that makes it a popular choice for developing software applications. Let's explore the four fundamental pillars of OOP in more detail.

The Four Pillars of Object-Oriented Programming

The four pillars of Object-Oriented Programming are:

1. Inheritance
2. Encapsulation
3. Polymorphism
4. Abstraction

These pillars form the foundation of OOP and are essential concepts to understand when working with object-oriented programming languages like C#.

Let go deep into each of the pillars of OOP in the next sections.

Let's start with the first pillar of OOP: Inheritance.

Inheritance

Inheritance is a concept used in most programming languages and is something you can't avoid when working with object-oriented programming. Programming languages like C# and Java are some of the languages that support inheritance. In this article, we will be looking at inheritance in C# and how to use it in your application.

What is Inheritance?

Imagine that you have a family tree, where each generation represents a class in C#. The first generation is the base class, which is the foundational class that provides the basic structure and properties. This could be likened to the patriarch of the family, who establishes the family's core values and characteristics.

As the family tree progresses, each subsequent generation inherits the traits and characteristics of the previous generation but also adds or modifies them to reflect their unique identity. These subsequent generations can be thought of as derived classes in C#, which inherit from the base class but also introduce their own unique features or modifications.

For example, the patriarch might have established the family's love for gardening, which becomes a fundamental trait passed down through the generations. However, as the family tree evolves, some members might develop a special interest in growing exotic plants, while others might focus on organic gardening. These special interests represent the unique characteristics of the derived classes, which inherit the basic love for gardening from the base class but also introduce their own unique features.

In this analogy, the base class is the patriarch, which represents the foundational class with its basic properties and characteristics. The derived classes are the subsequent generations, each with their unique features or modifications, inheriting the basic traits from the base class but also adding their own unique aspects. This process of inheritance allows for the creation of a rich and varied family tree, where each generation builds upon the previous one, introducing new traits and refining existing ones.

Inheritance is a mechanism that allows you to define a new class based on an existing class. The new class inherits all the members (fields, properties, and methods) of the existing class. The existing class is known as the base class, and the new class is known as the derived class.

Basic Syntax of inheritance in C#:

class BaseClass
{
    // Base class members
}

class DerivedClass : BaseClass
{
    // Derived class members
}

In the above code snippet, BaseClass is the base class, and DerivedClass is the derived class. The DerivedClass inherits all the members of the BaseClass. The colon (:) is used to indicate that the DerivedClass is derived from the BaseClass.

If You are new to C# and you don't know what a class is, don't worry, I will explain it to you. A class is a blueprint for creating objects. It defines the properties and methods that an object of the class will have. Here is an example of a class in C#:

class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public void Display()
    {
        Console.WriteLine($"Name: {Name}, Age: {Age}");
    }
}

In the above code snippet, the Person class has two properties (Name and Age) and a method (Display). The properties represent the state of the object, and the method represents the behavior of the object. You can create an object of the Person class and set its properties like this:

Person person = new Person();
person.Name = "John";
person.Age = 30;

You can call the Display method on the person object to display the name and age of the person:

person.Display(); // Output: Name: John, Age: 30

Before moving on with the article, let's look at some keywords you're going to come across a lot base class, Abstract class ,derived class, parent class, and child class.

Let me explain them to you.

• Base class: This is the class whose members are inherited by another class. It is also known as the parent class.

public class BaseClass
{
    public void Display()
    {
        Console.WriteLine("This is a base class");
    }
}

• Abstract class: This is a class that cannot be instantiated. It is used to provide a common base for all the derived classes. It can contain both abstract and non-abstract methods.

public abstract class AbstractClass
{
    public abstract void Display();
}

• Derived class: This is the class that inherits the members of the base class. It is also known as the child class.

public class DerivedClass : BaseClass

{
    public void Show()
    {
        Console.WriteLine("This is a derived class");
    }
}

So now you know what these keywords mean, let's move on to the next section.

Types of Inheritance

Inheritance can be classified into different types based on the way the classes are derived. The following are the types of inheritance:

• Single Inheritance: Single inheritance is a fundamental concept in object-oriented programming where a class, known as the derived class, is based on another class, known as the base class. This is the simplest form of inheritance.

To illustrate this, let's consider a real-world analogy. Imagine you are the only child of your father. In this scenario, you inherit characteristics from your father. This is akin to single inheritance in programming.

Let's look at an example in C#:

public class Father
{
    public void Display()
    {
        Console.WriteLine("This is the father class");
    }
}

In the above code, Father is the base class with a method Display.

Now, let's create a derived class Child that inherits from the Father class:

public class Child : Father
{
    public void Show()
    {
        Console.WriteLine("This is the child class");
    }
}

In this code snippet, the Child class is derived from the Father class. The Child class inherits the Display method from the Father class.

You can create an object of the Child class and call the Display method. This demonstrates that the Child class can access the Display method from the Father class.

Child child = new Child();
child.Display(); // Output: This is the father class

• Multilevel Inheritance: Multilevel inheritance is a concept in object-oriented programming where a class is derived from another derived class, creating a chain of inheritance.

To better understand this, let's consider a family tree analogy. Assuming you are the child of your father, and your father is the child of your grandfather. In this scenario, you inherit characteristics from both your father and grandfather. This is similar to multilevel inheritance in programming.

Let's explore this concept with an example in C#:

public class Grandfather
{
    public void Display()
    {
        Console.WriteLine("This is the grandfather class");
    }
}

In the above code, Grandfather is the base class with a method Display.

Next, we created a derived class Father that inherits from the Grandfather class:

public class Father : Grandfather
{
    public void Show()
    {
        Console.WriteLine("This is the father class");
    }
}

Here, the Father class is derived from the Grandfather class and inherits the Display method from it.

Finally, we created another derived class Child that inherits from the Father class:

public class Child : Father
{
    public void DisplayChild()
    {
        Console.WriteLine("This is the child class");
    }
}

In this code snippet, the Child class is derived from the Father class. The Child class inherits the Display and Show methods from the Father class.

We can create an object of the Child class and call the Display and Show methods. This demonstrates that the Child class can access the Display and Show methods from the Father class.

Child child = new Child();
child.Display(); // Output: This is the grandfather class
child.Show(); // Output: This is the father class
child.DisplayChild(); // Output: This is the child class

• Hierarchical Inheritance: Hierarchical inheritance is a concept in object-oriented programming where multiple classes are derived from a single base class, forming a tree-like structure.

To illustrate this, let's consider a real-world analogy. Assuming you and your siblings share the same parent. In this scenario, all of you inherit characteristics from the same parent. This is akin to hierarchical inheritance in programming.

Let's explore this concept with an example in C#:

public class Parent
{
    public void Display()
    {
        Console.WriteLine("This is the parent class");
    }
}

In the above code, Parent is the base class with a method Display.

Next, we created two derived classes Child1 and Child2 that inherit from the Parent class:

public class Child1 : Parent
{
    public void Show1()
    {
        Console.WriteLine("This is the first child class");
    }
}

public class Child2 : Parent
{
    public void Show2()
    {
        Console.WriteLine("This is the second child class");
    }
}

In this code snippet, the Child1 and Child2 classes are derived from the Parent class. Both classes inherit the Display method from the Parent class.

We can create objects of the Child1 and Child2 classes and call the Display, Show1, and Show2 methods. This demonstrates that both Child1 and Child2 classes can access the Display method from the Parent class.

Child1 child1 = new Child1();
child1.Display(); // Output: This is the parent class
child1.Show1(); // Output: This is the first child class

Child2 child2 = new Child2();
child2.Display(); // Output: This is the parent class
child2.Show2(); // Output: This is the second child class

Congratulation you have learned the basics of inheritance in C#, let's move to the next section Encapsulation.

Understanding Encapsulation and Properties in C

As we continue our journey through the pillars of OOP, we now arrive at Encapsulation. Before we delve into Encapsulation, it's crucial to understand a common concept in C# called properties.

Properties in C# are members of a class that provide a flexible mechanism to read, write, or compute the value of a private field. They can be used as if they are public data members, but they are actually special methods called accessors. These accessors are used to get and set the values of private fields.

If you're new to this concept, don't worry. Let's break it down with an example:

public class Person
{
    private string name;

    public string Name
    {
        get { return name; }
        set { name = value; }
    }
}

In the above code snippet, the Person class has a private field name and a property Name. The property Name has two accessors: a get accessor to retrieve the value of the name field, and a set accessor to set the value of the name field.

Understanding properties is key to grasping the concept of Encapsulation, which we will explore in the next section.

Encapsulation

To understand Encapsulation, let's use an analogy. Consider a gift box that contains a gift. The gift box acts as a container that encapsulates the gift. The gift is hidden from the outside world and can only be accessed through the gift box. This is akin to Encapsulation in object-oriented programming.

Encapsulation is the principle of bundling the data (fields) and methods (functions) that operate on the data into a single unit, known as a class. It restricts direct access to some of an object's components and allows access only through the methods of the class. In essence, Encapsulation conceals the internal state of an object and only exposes the necessary information to the outside world.

Let's see an example in C#:

public class Person
{
    private string name;
    private int age;

    public string Name
    {
        get { return name; }
        set { name = value; }
    }

    public int Age
    {
        get { return age; }
        set { age = value; }
    }

    public void Display()
    {
        Console.WriteLine($"Name: {Name}, Age: {Age}");
    }
}

In the above code snippet, the Person class encapsulates the data (fields name and age) and methods (Display) into a single unit. The fields name and age are private, meaning they cannot be accessed directly from outside the class. The properties Name and Age provide controlled access to the private fields using get and set accessors.

Let's add another example to further illustrate this concept:

public class BankAccount
{
    private double balance;

    public double Balance
    {
        get { return balance; }
        private set { balance = value; }
    }

    public void Deposit(double amount)
    {
        if (amount > 0)
        {
            Balance += amount;
        }
    }

    public void Withdraw(double amount)
    {
        if (amount > 0 && Balance >= amount)
        {
            Balance -= amount;
        }
    }

    public void DisplayBalance()
    {
        Console.WriteLine($"Balance: {Balance}");
    }
}

In this example, the BankAccount class encapsulates the balance field and the methods that operate on it (Deposit, Withdraw, DisplayBalance). The balance field is private and can only be accessed through the Balance property and the methods of the class. This ensures that the balance cannot be directly manipulated from outside the class, providing a secure way to manage a bank account.

Congratulations! You have learned about Encapsulation and how it is implemented in C#. Let's move on to the next section, Polymorphism.

Understanding Polymorphism in C

As we delve deeper into the four pillars of OOP, we now encounter Polymorphism. The term Polymorphism originates from the Greek words poly (many) and morphos (forms), signifying "many forms". In the realm of object-oriented programming, Polymorphism denotes an object's ability to assume multiple forms.

To comprehend Polymorphism, let's consider a music player. It can play various types of music files, such as MP3, WAV, or AAC. Each of these file types is different, yet our music player can handle all of them. This is akin to Polymorphism in object-oriented programming.

Polymorphism

Polymorphism is a core concept in object-oriented programming that allows objects of different classes to be treated as objects of a common superclass. It provides a single interface to represent multiple underlying forms (classes) and enables objects to be processed in a generic manner.

In C#, there are two types of Polymorphism:

1. Compile-time Polymorphism (Method Overloading)
2. Run-time Polymorphism (Method Overriding)

Compile-time Polymorphism (Method Overloading)

Compile-time Polymorphism, also known as Method Overloading, allows a class to have multiple methods with the same name but different parameters. The compiler determines which method to invoke based on the number and types of arguments.

Here's an example of Method Overloading in C#:

public class Printer
{
    public void Print(string message)
    {
        Console.WriteLine($"Printing string: {message}");
    }

    public void Print(int number)
    {
        Console.WriteLine($"Printing number: {number}");
    }

    public void Print(string message, int copies)
    {
        for (int i = 0; i < copies; i++)
        {
            Console.WriteLine($"Printing string: {message}");
        }
    }
}

In this example, the Printer class has three Print methods with the same name but different parameters. This is an example of Method Overloading in C#.

Run-time Polymorphism (Method Overriding)

Run-time Polymorphism, also known as Method Overriding, allows a subclass to provide a specific implementation of a method that is already provided by its superclass.

Here's an example of Method Overriding in C#:

public class MusicPlayer
{
    public virtual void Play()
    {
        Console.WriteLine("Playing music");
    }
}

public class Mp3Player : MusicPlayer
{
    public override void Play()
    {
        Console.WriteLine("Playing MP3 music");
    }
}

public class WavPlayer : MusicPlayer
{
    public override void Play()
    {
        Console.WriteLine("Playing WAV music");
    }
}

In this example, the MusicPlayer class has a virtual method Play. The Mp3Player and WavPlayer classes override the Play method with specific implementations for playing MP3 and WAV music, respectively. This is an example of Method Overriding in C#.

Let's see how Polymorphism can be used in a program:

MusicPlayer player = new Mp3Player();
player.Play(); // Output: Playing MP3 music

player = new WavPlayer();
player.Play(); // Output: Playing WAV music

In this code snippet, we created an object of the Mp3Player class and assigned it to a variable of type MusicPlayer. We then called the Play method on the player object, which invokes the overridden Play method in the Mp3Player class. We then created an object of the WavPlayer class and assigned it to the player variable. When we call the Play method again, it invokes the overridden Play method in the WavPlayer class.

Congratulations! You have learned about Polymorphism and how it is implemented in C#. Let's move on to the final pillar of OOP, Abstraction.

Understanding Abstraction in C

As we delve into the final pillar of OOP, we encounter Abstraction. Abstraction is the process of hiding complex implementation details and exposing only the essential features of an object. It emphasizes on what an object does rather than how it does it.

To comprehend Abstraction, let's consider a smartphone. When you use a smartphone, you don't need to understand the intricacies of how the internal components like the processor or the memory work. You only need to know how to interact with the user interface to make calls, send messages, or use apps. This is akin to Abstraction in object-oriented programming.

Abstraction

Abstraction is a key concept in object-oriented programming that allows you to create a blueprint for a class with some abstract methods that must be implemented by the derived classes. It enables you to define the structure of a class without providing the implementation details.

In C#, Abstraction can be achieved using abstract classes and interfaces. Let's explore both concepts:

Abstract Classes

An abstract class is a class that cannot be instantiated and can contain both abstract and non-abstract methods. An abstract method is a method without a body that must be implemented by the derived classes.

Here's an example of an abstract class in C#:

public abstract class Animal
{
    public abstract void Speak();
}

public class Dog : Animal
{
    public override void Speak()
    {
        Console.WriteLine("The dog barks");
    }
}

public class Cat : Animal
{
    public override void Speak()
    {
        Console.WriteLine("The cat meows");
    }
}

In this example, the Animal class is an abstract class with an abstract method Speak. The Dog and Cat classes inherit from the Animal class and provide specific implementations for the Speak method. This is an example of Abstraction using abstract classes in C#.

Interfaces

An interface is a reference type in C# that defines a contract for classes to implement. It contains only the declaration of the methods, properties, events, or indexers, without providing the implementation.

Here's an example of an interface in C#:

public interface IFlyable
{
    void Fly();
}

public class Bird : IFlyable
{
    public void Fly()
    {
        Console.WriteLine("The bird flies");
    }
}

public class Airplane : IFlyable
{
    public void Fly()
    {
        Console.WriteLine("The airplane flies");
    }
}

In this example, the IFlyable interface defines a contract with a method Fly. The Bird and Airplane classes implement the IFlyable interface and provide specific implementations for the Fly method. This is an example of Abstraction using interfaces in C#.

Congratulations! You have now learned about Abstraction and how it is implemented in C#. The key takeaway is that Abstraction allows us to hide the complexity of the system and expose only the necessary details to the user.

Summary

In this article, we have explored the four fundamental pillars of object-oriented programming (OOP) in C#: Inheritance, Encapsulation, Polymorphism, and Abstraction.

These pillars form the foundation of OOP and are essential concepts to understand when working with object-oriented programming languages like C#. The knowledge gained from this article will help you enhance your understanding of OOP concepts and their implementation in C#.

Thank you for reading this article, I hope you find it helpful. If you have any questions or feedback, feel free to reach out to me. Happy coding!

Like many other programming languages, Python supports both OOP and functional programming. However, OOP becomes valuable when writing large-sized and complex programs.

In this article, you will learn the benefits of OOP in Python, how to define a class, class and instance attributes, and instance methods. You will also learn the concept of encapsulation and how to implement inheritance between classes in Python.

To fully understand this article, you should have the following prerequisites:

• Basic knowledge of the Python programming language.

• Familiarity with the concepts of functions and objects in programming.

• Experience working with a code editor or integrated development environment (IDE).

• Basic understanding of how to use a command-line terminal or console.

Now let's dive in.

Why Use Object-Oriented Programming?

Object-oriented programming (OOP) offers several benefits when organizing and managing code. By grouping related data and functions into logical classes, OOP promotes code structure and simplifies maintenance, especially as programs grow in size and complexity. The modular approach makes it easier to understand, modify, and reuse code, thereby reducing development time.

Another benefit of OOP is its ability to provide a clear and relatable programming style, which can be more helpful for developers. The use of objects and the relationships between them mirror real-world concepts. This makes it easier to reason about code and design complex systems.

Finally, OOP's concepts such as encapsulation and inheritance, contribute to code robustness by promoting data protection and code reusability.

What is a Class in Python?

OOP in Python heavily relies on the concept of class. You can think of a class as a blueprint that is used to create objects. To illustrate this, imagine that you have a blueprint for a speaker. You can use this blueprint to build multiple speakers. Each speaker that is created using the blueprint is an instance of the blueprint. Also, each created speaker has its attributes such as color, model, and name. They will also have their methods showing a certain kind of behavior such as volume up and volume down.

How to Define a Class in Python

To define a class, you have to use the class keyword, provided by Python, then followed by the name of the class and a colon:

class ClassName:
    pass

Now using our earlier illustration, let’s create a class named Speaker. In your code editor, create a file named classes.py and copy the following lines of code into it:

class Speaker:
    pass

speaker_one = Speaker()
print(speaker_one)

In the preceding code, you defined a class named Speaker without any attributes or methods. You used the keyword pass in the class body. In Python, the pass keyword does nothing and is usually used as a placeholder.

In line four of the code, you created an instance of the Speaker class and assigned it to the variable speaker_one. This process is also known as instantiating an object from a class. You then printed speaker_one in line five.

Now run the code by running the command python classes.py in your terminal. You will get an output similar to this in your terminal:

<__main__.Speaker object at 0x10087f8e0>

The output shows that speaker_one is an object. 0x10087f8e0 in the output shows the memory address where Python stores the object on your computer.

The memory address in your terminal output will be different.

You can create several more instances from the Speaker class and they will all be different from one another. To verify this, let’s use the equality comparison (\==) operator. In your classes.py file, delete print(speaker_one) and add the following to the bottom of your code:

speaker_two = Speaker()

if speaker_one == speaker_two:
    print("speaker one is the same as speaker two")
else:
    print("speaker one is different from speaker two")

Now run python classes.py in your terminal. You will get the following output:

speaker one is different from speaker two

Class and Instance Attributes

In this section, you'll add attributes to your Speaker class. You can see attributes as data stored within an object. While class attributes are common to all instances created from your class, instance attributes are unique to each instance.

Now modify your classes.py file by replacing your code with the following:

class Speaker:
    brand = "Beatpill" # class attribute

    def __init__(self, color, model):
        self.color = color # instance attribute
        self.model = model # instance attribute

You should already be familiar with line one of your new code. In line two, you defined a class attribute, named brand, and assigned it the value Beatpill. Class attributes are variables that belong to the class itself, rather than to individual instances of the class. The effect of class attributes is that all instances you create from your class will inherit and share that class attribute and its value. In this case, every instance you create from your Speaker class will share the same brand value.

Line four of your code defines an __init__ method, which takes in three parameters—self, color, and model. This method will be called anytime you create a new instance from your Speaker class. The self parameter is a reference to the Speaker class and it's a convention in Python to always have it as the first parameter in a __init__ method. Line five and six set instance attributes, color, and model to your Speaker class.

So, every time you create a new instance from your class, you have to provide arguments for your color and model attributes. Not doing this will result in an error.

Now add the following to the bottom of your code:

speaker_one = Speaker("black", "85XB5")
speaker_two = Speaker("red", "Y8F33")

print(f"speaker one is {speaker_one.color} while speaker two is {speaker_two.color}")

By adding the preceding code, you created two instances of the Speaker class—speaker_one and speaker_two. The arguments in each instance represent the values of their color and model attributes. You then printed a message that displays the color attribute of each object. Now, if you run the command python classes.py in your terminal, you will get the output:

speaker one is black while speaker two is red

To see that both instances share the same brand class attribute, modify your print() function like this:

print(
    f"speaker one is {speaker_one.color} while speaker two is {speaker_two.color}",
    speaker_one.brand,
    speaker_two.brand,
    sep="\n",
)

Now run python classes.py and you will get the following output:

speaker one is black and speaker two is red
Beatpill
Beatpill

Instance Methods

In addition to class and instance attributes, classes can also have methods, known as instance methods. Instance methods are functions defined within a class that operate on instances of the class. They use the class and instance attributes to provide behavior and functionality to the objects.

To add instance methods, modify your code file as follows:

class Speaker:
    brand = "Beatpill"

    def __init__(self, color, model):
        self.color = color
        self.model = model

    def power_on(self):
        print(f"Powering on {self.color} {self.model} speaker.")

    def power_off(self):
        print(f"Powering off {self.color} {self.model} speaker.")


speaker_one = Speaker("black", "85XB5")
speaker_two = Speaker("red", "Y8F33")

In the example above, we've added two instance methods—power_on() and power_off(). These methods, just like the __init__ method, take self as the first argument.

The power_on() method prints a message indicating that the speaker of the given color and model is being powered on. Similarly, the power_off() method prints a message about powering off the speaker.

To call these methods, add the following to the bottom of your file:

speaker_one.power_on()
speaker_two.power_off()

Now run python classes.py in your terminal and you will get the following output:

Powering on black 85XB5 speaker.
Powering off red Y8F33 speaker.

Encapsulation in Python

Encapsulation is one of the core concepts of OOP. It refers to the bundling of data (attributes) and methods within a class. Encapsulation provides data protection and control over how the code interacts with an object's internal state.

You can achieve encapsulation in Python by defining private attributes and methods within a class. By convention, private attributes and methods are prefixed with a single underscore (_). While Python does not have strict private modifiers like some other languages, the underscore prefix serves as a warning to other developers not to access or modify the attributes and methods directly from outside the class.

Here's an example of encapsulation in Python:

class Speaker:
    brand = "Beatpill"

    def __init__(self, color, model):
        self._color = color  # Private attribute
        self._model = model  # Private attribute

    def power_on(self):
        print(f"Powering on {self._color} {self._model} speaker.")

    def power_off(self):
        print(f"Powering off {self._color} {self._model} speaker.")

    def get_color(self):
        return self._color

    def set_color(self, new_color):
        self._color = new_color


speaker_one = Speaker("black", "85XB5")
speaker_one.power_on()

# Accessing a private attribute directly (not recommended)
print(speaker_one._color)

# Accessing a private attribute using the getter method (recommended)
print(speaker_one.get_color())

# Modifying a private attribute using the setter method (recommended)
speaker_one.set_color("white")
print(speaker_one.get_color())

In the preceding example, the color and model attributes are private attributes of the Speaker class. Although it is possible to access and modify these attributes directly from outside the class by using, for example, print(speaker_one._color), this practice is discouraged. Doing so violates encapsulation and can lead to unintended behavior or data corruption.

Instead, the class provides getter get_color() and setter set_color() methods to access and modify the private attributes in a controlled manner. These methods act as an interface for interacting with the object's internal state, ensuring data integrity and enabling additional validation.

Encapsulation promotes code modularity, maintainability, and data protection by separating the internal state from the public interface (methods). It allows you to change the internal state without affecting the code that uses the class, as long as the public interface remains the same.

Inheritance in Python

Inheritance is another core concept of OOP. It allows classes to inherit attributes and methods from other classes. The new class inherits attributes and methods from the existing class, known as the parent or base class. The new class is called the child or derived class.

Inheritance promotes code reuse by allowing the child class to inherit and extend the functionality of the parent class. This helps in creating hierarchical relationships between classes and organizing code in a more structured and logical manner.

In Python, inheritance is implemented using the following syntax:

class DerivedClass(BaseClass):
    # Derived class methods and attributes

To see how inheritance works, modify your code as follows:

class Speaker:
    brand = "Beatpill"

    def __init__(self, color, model):
        self._color = color
        self._model = model

    def power_on(self):
        print(f"Powering on {self._color} {self._model} speaker.")

    def power_off(self):
        print(f"Powering off {self._color} {self._model} speaker.")

# Add a SmartSpeaker class and make it inherit from the Speaker class
class SmartSpeaker(Speaker):
    def __init__(self, color, model, voice_assistant):
        super().__init__(color, model)
        self._voice_assistant = voice_assistant

    def say_hello(self):
        print(f"Hello, I am {self._voice_assistant}")


# Create an instance of the SmartSpeaker class
smart_speaker = SmartSpeaker("black", "XYZ123", "Alexa")
smart_speaker.power_on()  # Inherited from Speaker
smart_speaker.say_hello()

In the preceding code, the SmartSpeaker class is derived from the Speaker class. The SmartSpeaker class inherits the attributes and methods of the Speaker class.

The __init__ method of the SmartSpeaker class calls the __init__ method of the Speaker class using super().__init__(color, model). This ensures that the inherited _color and _model attributes are properly initialized. Also, the SmartSpeaker class has its own attribute _voice_assistant, and a new method say_hello.

Now run python classes.py in your terminal and you will get the following output:

Powering on black XYZ123 speaker.
Hello, I am Alexa

Conclusion

Throughout this article, we highlighted the benefits of Object-Oriented Programming (OOP) and demonstrated how to define classes, create and use instance attributes and methods. We provided practical examples to illustrate the implementation of classes in Python, as well as key OOP concepts such as encapsulation and inheritance.

Applying the lessons covered in this article will help you improve your Python programming experience and increase the efficiency and maintainability of your code.

References and Further Reading

• https://en.wikipedia.org/wiki/Object-oriented_programming

• https://realpython.com/python3-object-oriented-programming/

• https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/Object-oriented_programming

• https://docs.python.org/3/tutorial/classes.html

• https://realpython.com/python-classes/

• https://realpython.com/python-double-underscore/

Object-Oriented Programming (OOP) is a fundamental concept in software engineering that allows software engineers to structure code in a more organized and modular way.

Python, with its clear and concise syntax, is an excellent language for learning and implementing OOP principles.

In this article, we'll look at the basics of OOP in Python by building a simple online banking system.

An Overview of OOP Concepts

Before we start coding, let's understand the key concepts of OOP:

• Classes: Classes are blueprints for creating objects. They define the attributes (data) and methods (functions) that objects of that class will have.
• Objects: Objects are instances of classes. They represent real-world entities and encapsulate data and behavior.
• Inheritance: Inheritance allows a class (subclass) to inherit attributes and methods from another class (superclass). It promotes code reuse and supports hierarchical relationships between classes.
• Constructor: A constructor ( __init__() ) is a special type of method that is automatically called when an object of a class is created. Its primary purpose is to initialize the newly created object, setting initial values for its attributes or performing any necessary setup tasks.

How to Build An Online Banking System

Let's start by creating the basic structure for our online banking system using OOP principles.

How to Create A Class and Constructor

Let's create a class and initiate the class with the constructor:

class Account:
    def __init__(self, name, account_number, balance):
        self.name = name
        self.account_number = account_number
        self.balance = balance

In the example above:

• The class keyword declares an Account class.
• The __init__() method is the constructor, defined with the special double underscore notation at the beginning and end.
• self is a reference to the instance of the class. It is the first parameter of all instance methods in Python.
• name is the name of the account holder.
• account_number is a unique identifier for the savings account, and balance are parameters passed to the constructor.
• Inside the constructor self.name, self.account_number, and self.balance are attributes of the class Account that are initialized with the values of name, account_number and balance, respectively.

Constructors can perform various tasks such as initializing attributes, opening connections, loading data, and more. They are essential for ensuring that objects are properly set up and ready for use as soon as they are created.

How to Create Methods (functions)

The next thing to do is to write the different methods for our Account class. Users should be able to deposit and withdraw.

How to create a deposit method

    def deposit(self, amount):
        self.balance += amount
        print(f"{self.name} Deposited {amount} $. Current balance is: {self.balance}")

In the example above:

• The deposit method allows users to add funds to their account.
• The method takes an additional parameter amount, which is the amount to be deposited.
• Inside the method, the amount is added to the current balance using self.balance += amount.
• A message is printed showing the depositor name and the amount deposited and the balance is updated.

How to create a withdraw method

    def withdraw(self, amount):
        if self.balance >= amount:
            self.balance -= amount
            print(f"{self.name} Withdrew {amount} $. Current balance is: {self.balance}")
        else:
            print("You don't have enough funds to withdraw.")

In the example above:

• The withdraw method allows users to withdraw funds from their account.
• The method also takes an amount parameter which is the amount our user wants to withdraw.
• The method checks if the account balance (self.balance) is greater than or equal to the amount our user wants to withdraw.
• If the balance is enough, the withdrawal amount is removed from the balance using self.balance -= amount.
• If the balance is not enough, a message stating “You don't have enough funds to withdraw.” is printed to the user.

How Inheritance Works

Having explained inheritance above, let's see how it works in code. We are going to create a class that inherits the Account class.

Note that the Account class is the supper class, while the Savings_Account class is a subclass, also known as a child class.

class Savings_Account(Account):
    def __init__(self, name, account_number, balance, interest_rate):
        super().__init__(name, account_number, balance)
        self.interest_rate = interest_rate

In the above code:

• The __init__ method is the constructor for the Savings_Account class.
• It accepts four parameters: name which is the name of the account holder, account_number, which is a unique identifier for the savings account, balance, which is the initial balance of the account, and interest_rate, which is the annual interest rate (expressed as a decimal) for the account.
• The super().__init__(name, account_number, balance) line calls the constructor of the parent class (Account) to initialize the account number and balance.
• The self.interest_rate = interest_rate line sets the interest rate specific to the savings account. it is not inherited

How to Create An add_interest Method

def add_interest(self):
    interest = self.balance * self.interest_rate
    self.deposit(interest)

In the example above:

• The add_interest method calculates and adds interest to the account balance.
• The method calculates the interest by multiplying the current balance (self.balance) with the interest rate (self.interest_rate).
• The result is stored in the interest variable.
• Finally, the self.deposit(interest) line calls the deposit method (defined in the parent Account class) to add the interest amount to the account balance.

How to Create and Use Objects

Your class is just a template. You need to create an object for your class to work.

Now, let's create objects from our classes and interact with them.

account1 = Account("John Doe", "123456", 1000)
account1.deposit(500)
account1.withdraw(200)
print()

savings_account = Savings_Account("John Doe", "789012", 2000, 0.05)
savings_account.deposit(1000)
savings_account.add_interest()
savings_account.withdraw(500)
savings_account.withdraw(1000)

In the above code:

• We created an instance account1 of the Account class and performed deposit and withdrawal operations.
• Similarly, we created an instance savings_account of the Savings_Account class and demonstrated deposit, interest addition, and withdrawal operations.

Conclusion

Object-Oriented Programming is a powerful paradigm that allows software engineers to write code that is reusable, maintainable, and can scale.

Python's simplicity makes it an excellent choice for learning and implementing OOP concepts.

By building a simple online banking system, I've show you the basic concepts of classes, objects, and inheritance in Python.

Happy coding!