This handbook serves as a practical guide to understanding software design patterns. I wrote it for every developer, regardless of the language you program in. Examples are written in C#, but every concept here applies equally to Python, Java, TypeScript, Go, and beyond.

The source code lives at github.com/Clifftech123/design-patterns-handbook.

Things to Keep in Mind:

• Design patterns aren't code. They're a way of thinking about how to structure your code. They're a tool, not a silver bullet, for solving specific design problems.

• The concepts are universal. The examples here are written in C#, but the same patterns exist in every language. If you write Python, Java, Go, or TypeScript, you're already using some of these without knowing it.

• There's no one-size-fits-all pattern. Each pattern exists to address a particular kind of problem. Understanding what problem a pattern solves is more important than memorizing the implementation.

I use C# here as the teaching language because it's clear, readable, and widely understood. The goal of this handbook is for you to walk away understanding the pattern itself, not just the C# code.

There are three main types of design patterns: Creational, Structural, and Behavioral. We'll look at each one in turn here, starting with Creational.

What We'll Cover:

• Things to Keep in Mind

• Creational Design Patterns

  • 1. Singleton Design Pattern

  • 2. The Factory Method

  • 3. The Abstract Factory Design Pattern

  • 4. The Builder Design Pattern

  • 5. The Prototype Design Pattern

• Structural Design Patterns

  • 1. The Adapter Design Pattern

  • 2. The Bridge Design Pattern

  • 3. The Composite Design Pattern

  • 4. The Decorator Design Pattern

  • 5. The Facade Design Pattern

  • 6. The Flyweight Design Pattern

  • 7. The Proxy Design Pattern

• Behavioral Design Patterns

  • 1. The Chain of Responsibility Design Pattern

  • 2. The Command Design Pattern

  • 3. The Interpreter Design Pattern

  • 4. The Iterator Design Pattern

  • 5. The Mediator Design Pattern

  • 6. The Memento Design Pattern

  • 7. The Observer Design Pattern

  • 8. The State Design Pattern

  • 9. The Strategy Design Pattern

  • 10. The Template Method Design Pattern

  • 11. The Visitor Design Pattern

• Conclusion

  • A few things worth remembering

Creational Design Patterns

Simply put, Creational patterns are all about how objects are created. They can be divided into class-creation patterns, which use inheritance to decide which class to instantiate, and object-creation patterns, which use delegation to get the job done.

Wikipedia describes them as:

"A creational pattern aims to separate a system from how its objects are created, composed, and represented. They increase the system's flexibility in terms of the what, who, how, and when of object creation."

(Source)

So Creational patterns keep the details of object creation hidden from the client code, making the system easier to manage and maintain.

They also abstract away how objects are created, composed, and represented, so the rest of your code doesn't need to care.

There are five Creational design patterns, which we'll go over one by one below:

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

2. Factory Method: Defines an interface for creating an object, but lets subclasses decide which class to instantiate.

3. Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.

4. Builder: Separates the construction of a complex object from its representation, so the same construction process can produce different results.

5. Prototype: Creates new objects by cloning an existing instance rather than building one from scratch.

1. Singleton Design Pattern

Real World Example:

Think of the conductor of an orchestra. An orchestra has one conductor. Every musician on stage looks to that same conductor for direction: when to start, when to stop, how fast to play, and how loud to go.

The conductor is the single point of authority that all musicians connect to and take decisions from. You can't have two conductors standing at the front giving different instructions. That would cause chaos. No matter which musician needs guidance, they all reach the same one person.

That's exactly how the Singleton works in code: one instance, shared by everyone who needs it, making decisions from one place.

Problems it solves:

• What if two musicians get different conductors giving different instructions? The performance falls apart. There must be one conductor that every musician looks to, without exception.

• How does a musician find the conductor? They don't go searching. There's one well-known place everyone looks, and the same conductor is always there.

• What stops someone from appointing a second conductor? The orchestra itself controls this. Once a conductor is on the podium, no second one can take it.

In simple terms, there's only one instance of the class, and every part of the system that needs it gets access to that exact same instance (never a new one).

Here's how Wikipedia describes the Singleton pattern:

"In object-oriented programming, the singleton pattern is a software design pattern that restricts the instantiation of a class to a singular instance. The pattern is useful when exactly one object is needed to coordinate actions across a system." (Source)

Programming Example:

We'll model the analogy directly now. The OrchestraConductor is the Singleton: one instance, shared by all musicians, making all decisions.

public class OrchestraConductor
{
    // Step 1: Hold the one instance here
    private static OrchestraConductor _instance;

    // Step 2: Private constructor - nobody outside can do: new OrchestraConductor()
    private OrchestraConductor() { }

    // Step 3: The only way to get the conductor
    public static OrchestraConductor GetInstance()
    {
        if (_instance == null)
        {
            _instance = new OrchestraConductor();
        }

        return _instance;
    }

    // Decisions the conductor makes
    public void Start()                    => Console.WriteLine("Conductor: Begin playing.");
    public void Stop()                     => Console.WriteLine("Conductor: Stop playing.");
    public void SetTempo(string tempo)     => Console.WriteLine($"Conductor: Tempo is now {tempo}.");
}

Now let's see it in action:

// Violinist asks for the conductor
OrchestraConductor violinist = OrchestraConductor.GetInstance();

// Pianist asks for the conductor
OrchestraConductor pianist = OrchestraConductor.GetInstance();

// Are they talking to the same conductor?
Console.WriteLine(object.ReferenceEquals(violinist, pianist)); // True

violinist.SetTempo("Allegro");
pianist.Start();

Output:

True
Conductor: Tempo is now Allegro.
Conductor: Begin playing.

Both musicians got the same conductor. The constructor never ran twice. That is the Singleton pattern.

When to Use the Singleton Pattern

Reach for Singleton when you need one shared resource that the whole application talks to, such as a logger, a configuration manager, or a database connection pool.

It's also a good idea when having more than one instance would cause incorrect behaviour or conflicting state.

And it's helpful when you want a global point of access to an object without passing it around everywhere.

2. The Factory Method

Think of a recruitment agency. A company calls the agency and says "we need a worker." The company doesn't go out and create the worker themselves. They just make the request.

The agency decides which specific person to send: a developer, a designer, or a tester, depending on what the company needs. The company doesn't know or care exactly who is coming. They just know the person will be able to do the job.

That's the Factory Method. Your code asks for an object. The Factory decides which specific type to create and hands it back. You work with it without needing to know exactly what it is under the hood.

Problems it solves:

• The company shouldn't need to know who they're getting. They just need someone who can do the job. The agency handles the decision of whom to send. The company never has to worry about the details.

• What if the company needs a different type of worker tomorrow? They call the same agency. The agency decides. The company's process doesn't change, only the agency's decision does.

• What if a new type of worker needs to be introduced? A new specialist agency is created to handle that. Everything else stays exactly the same.

In simple terms, we define an interface for creating an object, but let subclasses decide which class to instantiate. The factory method lets a class defer instantiation to subclasses.

Wikipedia describes it like this:

"In object-oriented programming, the factory method pattern is a design pattern that uses factory methods to deal with the problem of creating objects without having to specify their exact classes. Factory methods can be specified in an interface and implemented by subclasses, or implemented in a base class and optionally overridden by subclasses." (Source)

Programming Example:

The agency is the factory. The worker types are the products. The company is the client.

// The worker interface - all workers can do a job
public interface IWorker
{
    void DoWork();
}

// The concrete workers
public class Developer : IWorker
{
    public void DoWork() => Console.WriteLine("Developer: Writing code.");
}

public class Designer : IWorker
{
    public void DoWork() => Console.WriteLine("Designer: Creating designs.");
}

// The base agency - declares the factory method
public abstract class RecruitmentAgency
{
    // This is the Factory Method - subclasses decide who to hire
    public abstract IWorker HireWorker();
}

// Concrete agencies - each one decides which worker to send
public class TechAgency : RecruitmentAgency
{
    public override IWorker HireWorker() => new Developer();
}

public class DesignAgency : RecruitmentAgency
{
    public override IWorker HireWorker() => new Designer();
}

Now let's see it in action:

// Company A needs a tech worker
RecruitmentAgency agency = new TechAgency();
IWorker worker = agency.HireWorker();
worker.DoWork();

// Company B needs a design worker
RecruitmentAgency agency2 = new DesignAgency();
IWorker worker2 = agency2.HireWorker();
worker2.DoWork();

Output:

Developer: Writing code.
Designer: Creating designs.

The company never used new Developer() or new Designer() directly. The agency made that decision. That is the Factory Method.

3. The Abstract Factory Design Pattern

Real World Example

Think of a furniture store that sells collections. You walk in and choose a style: Modern or Victorian. Once you choose, everything you get comes from that same collection. The sofa, the chair, and the coffee table all match. The store ensures that you never walk out with a modern sofa paired with a Victorian chair. You don't pick individual pieces and hope they go together. The collection guarantees they will.

That's the Abstract Factory. You choose a family, and the Factory produces every object you need from that same family. Everything it gives you is guaranteed to work together.

Problems it solves:

• What if a customer mixes furniture from different collections? The room looks inconsistent. The store solves this by grouping everything into collections. You pick one collection and everything comes from it.

• What if the store wants to introduce a new collection? They create a new collection set. Every existing collection stays untouched. The customer's experience doesn't change, only the options grow.

• What if different stores carry different collections? Each store is its own factory. A customer walks into any store and follows the same process. The store handles which specific pieces to provide.

In simple terms, you provide an interface for creating families of related objects, without specifying their concrete classes.

Wikipedia describes it like this:

"The abstract factory pattern provides a way to create families of related objects without imposing their concrete classes, by encapsulating a group of individual factories that have a common theme without specifying their concrete classes."

Source: Wikipedia - Abstract factory pattern

Programming Example:

The furniture store is the abstract factory. Modern and Victorian are the concrete factories. Sofa and Chair are the products.

// The product interfaces - every furniture type has a contract
public interface ISofa  { void Describe(); }
public interface IChair { void Describe(); }

// Modern collection
public class ModernSofa : ISofa
{
    public void Describe() => Console.WriteLine("Sofa: Sleek modern design.");
}

public class ModernChair : IChair
{
    public void Describe() => Console.WriteLine("Chair: Minimalist modern style.");
}

// Victorian collection
public class VictorianSofa : ISofa
{
    public void Describe() => Console.WriteLine("Sofa: Ornate Victorian design.");
}

public class VictorianChair : IChair
{
    public void Describe() => Console.WriteLine("Chair: Classic Victorian style.");
}

// The abstract factory - every store can produce a sofa and a chair
public interface IFurnitureFactory
{
    ISofa  CreateSofa();
    IChair CreateChair();
}

// Concrete factories - each one produces its own collection
public class ModernFurnitureFactory : IFurnitureFactory
{
    public ISofa  CreateSofa()  => new ModernSofa();
    public IChair CreateChair() => new ModernChair();
}

public class VictorianFurnitureFactory : IFurnitureFactory
{
    public ISofa  CreateSofa()  => new VictorianSofa();
    public IChair CreateChair() => new VictorianChair();
}

Now let's see it in action:

// Customer orders a Modern collection
IFurnitureFactory factory = new ModernFurnitureFactory();
ISofa  sofa  = factory.CreateSofa();
IChair chair = factory.CreateChair();
sofa.Describe();
chair.Describe();

// Customer orders a Victorian collection
IFurnitureFactory factory2 = new VictorianFurnitureFactory();
ISofa  sofa2  = factory2.CreateSofa();
IChair chair2 = factory2.CreateChair();
sofa2.Describe();
chair2.Describe();

Output:

Sofa: Sleek modern design.
Chair: Minimalist modern style.
Sofa: Ornate Victorian design.
Chair: Classic Victorian style.

Every piece came from the same collection. The client never used new ModernSofa() or new VictorianChair() directly. The factory kept the family together. That's the Abstract Factory.

When to Use Abstract Factory:

Use the Abstract Factory pattern when your system needs to work with multiple families of related objects and you need to ensure they're always used together.

It also works well when you want to swap out an entire family of objects in one place without touching the rest of your code.

And it's a good choice when you want to enforce consistency across related objects, so nothing from one family gets accidentally mixed with another.

4. The Builder Design Pattern

Real World Example

Think of a tailor making a suit. Every customer that walks in goes through the same process: take measurements, choose the fabric, select the lining, pick the buttons, and decide on the lapel style.

The tailor follows those same steps for every order. But the finished suit is completely unique to each customer. A businessman walks out with a sharp formal suit. A wedding guest walks out with something entirely different. Same process, same tailor, but with different result every time.

That's the Builder. The construction process stays the same. What changes are the choices made at each step.

Problems it solves:

• What if a suit had to be assembled all at once with no steps? You would have to know every detail upfront and get it all right in one go. The tailor breaks it down into steps so each decision is made clearly, one at a time.

• What if two customers want completely different suits but go through the same tailor? The tailor follows the same process for both. The steps don't change, only the choices within each step.

• What if a new suit style needs to be introduced? A new set of choices is defined for that style. The tailoring process itself stays untouched.

In simple terms, you separate the construction of a complex object from its representation, so that the same construction process can create different results.

Wikipedia describes it like this:

"The Builder pattern separates the construction of a complex object from its representation so that the same construction process can create different representations." (Source)

Programming Example:

The tailor is the director. The suit is the product. The builder handles the step-by-step construction.

// The product
public class Suit
{
    public string Fabric  { get; set; }
    public string Lining  { get; set; }
    public string Buttons { get; set; }

    public void Describe()
    {
        Console.WriteLine($"Suit: {Fabric} fabric, {Lining} lining, {Buttons} buttons.");
    }
}

// The builder - defines the steps
public interface ISuitBuilder
{
    void SetFabric();
    void SetLining();
    void SetButtons();
    Suit GetSuit();
}

// Business suit builder
public class BusinessSuitBuilder : ISuitBuilder
{
    private Suit _suit = new Suit();

    public void SetFabric()  => _suit.Fabric  = "Dark wool";
    public void SetLining()  => _suit.Lining  = "Silk";
    public void SetButtons() => _suit.Buttons = "Black horn";
    public Suit GetSuit()    => _suit;
}

// Wedding suit builder
public class WeddingSuitBuilder : ISuitBuilder
{
    private Suit _suit = new Suit();

    public void SetFabric()  => _suit.Fabric  = "Ivory linen";
    public void SetLining()  => _suit.Lining  = "Satin";
    public void SetButtons() => _suit.Buttons = "Pearl";
    public Suit GetSuit()    => _suit;
}

// The tailor - the director who runs the process
public class Tailor
{
    public Suit MakeSuit(ISuitBuilder builder)
    {
        builder.SetFabric();
        builder.SetLining();
        builder.SetButtons();
        return builder.GetSuit();
    }
}

Now let's see it in action:

Tailor tailor = new Tailor();

Suit businessSuit = tailor.MakeSuit(new BusinessSuitBuilder());
businessSuit.Describe();

Suit weddingSuit = tailor.MakeSuit(new WeddingSuitBuilder());
weddingSuit.Describe();

Output:

Suit: Dark wool fabric, Silk lining, Black horn buttons.
Suit: Ivory linen fabric, Satin lining, Pearl buttons.

The same tailor, following the same process, creates two completely different suits. That is the Builder.

When to Use the Builder Design Pattern

Use the Builder pattern when an object has many parts or configurations and building it all at once would be confusing.

It's also a good choice when you want the same construction process to produce different results depending on the choices made at each step.

And reach for it when you want to keep the construction logic separate from the object itself, so each can change independently.

5. The Prototype Design Pattern

Real World Example

Imagine you're building a drawing application. Users can create shapes like circles, rectangles, or triangles, each with its own colour, size, and position.

Now imagine the user wants ten red circles of the same size placed across the canvas. Creating each one from scratch means repeating the same setup ten times. What if the shape is complex, with many configured properties? That becomes expensive and repetitive.

The Prototype pattern solves this by letting you take one fully configured shape and clone it. The clone starts as an exact copy. The user then moves it, recolours it, or resizes it independently. The original shape is never touched. This also means new shape types can be added at runtime without the application needing to know about them in advance.

Problems it solves:

• Creating a new shape from scratch every time is expensive. If a shape has many properties, setting them all up repeatedly wastes resources. Cloning an already configured object is far cheaper.

• The application shouldn't need to know the exact type of shape it's copying. At runtime, shapes can be added or removed dynamically. The app just calls clone and gets back a ready object, whatever type it happens to be.

• Modifying a copy should never affect the original. Each cloned shape is fully independent. Changes to the copy stay with the copy.

In simple terms, you can create new objects by copying an existing one. The copy starts identical to the original and can then be changed independently.

Wikipedia describes it like this:

"The Prototype pattern is used when the type of objects to create is determined by a prototypical instance, which is cloned to produce new objects." (Source)

Programming Example:

Every shape knows how to clone itself. The application never calls new Circle() or new Rectangle() directly at runtime. It clones what already exists.

// The prototype interface - every shape must be able to clone itself
public abstract class Shape
{
    public string Colour { get; set; }
    public int    Size   { get; set; }

    public abstract Shape Clone();
    public abstract void  Describe();
}

// Concrete shapes
public class Circle : Shape
{
    public override Shape Clone()    => (Shape)this.MemberwiseClone();
    public override void  Describe() => Console.WriteLine($"Circle  | Colour: {Colour} | Size: {Size}");
}

public class Rectangle : Shape
{
    public override Shape Clone()    => (Shape)this.MemberwiseClone();
    public override void  Describe() => Console.WriteLine($"Rectangle | Colour: {Colour} | Size: {Size}");
}

Now let's see it in action:

// Create one configured circle
Circle original = new Circle { Colour = "Red", Size = 50 };

// Clone it instead of building from scratch
Shape clone1 = original.Clone();
Shape clone2 = original.Clone();

// Modify the clones independently
clone2.Colour = "Blue";

original.Describe();
clone1.Describe();
clone2.Describe();

Output:

Circle  | Colour: Red  | Size: 50
Circle  | Colour: Red  | Size: 50
Circle  | Colour: Blue | Size: 50

clone2 changed to blue. The original stayed red. Each object is fully independent. That's the Prototype.

When to Use the Prototype Design Pattern:

Use Prototype when creating a new object from scratch is expensive or complex and an existing object already has everything configured.

It's also helpful when the application needs to create objects at runtime without knowing their exact type in advance.

And it's great when you need many variations of an object and want to start from a known good state rather than rebuild every time.

Structural Design Patterns

Simply put, structural patterns are all about how classes and objects are composed to form larger structures. They use inheritance and composition to let you build flexible, efficient structures without having to rewrite everything from scratch.

Wikipedia describes them as:

"In software engineering, structural patterns are design patterns that ease the design by identifying a simple way to realize relationships among entities." (Source)

Structural design patterns describe how objects and classes are combined to form larger, more complex structures while keeping those structures flexible and efficient.

They focus on composition over inheritance: how you connect things, not just what things are.

There are seven Structural design patterns:

1. Adapter: Converts one interface into another that a client expects, letting incompatible interfaces work together.

2. Bridge: Decouples an abstraction from its implementation so the two can vary independently.

3. Composite: Composes objects into tree structures to represent part-whole hierarchies, letting clients treat individual objects and compositions uniformly.

4. Decorator: Attaches additional responsibilities to an object dynamically, as a flexible alternative to subclassing.

5. Facade: Provides a simplified, unified interface to a complex subsystem.

6. Flyweight: Uses sharing to efficiently support a large number of fine-grained objects.

7. Proxy: Provides a surrogate or placeholder for another object to control access to it.

1. The Adapter Design Pattern

Real World Example

Think of a language translator at a business meeting. A British CEO needs to address a Japanese team. The CEO speaks only English. The team speaks only Japanese. A translator sits between them, converting every English sentence into Japanese and delivering it to the team. Both sides keep speaking their own language. Neither the CEO nor the team change anything about how they communicate. The translator makes them compatible.

That's the Adapter. The client speaks one interface, while the other side speaks a different one. The Adapter sits between them and makes both sides work together without either having to change.

Problems it solves:

• The CEO can't speak Japanese, and the team can't speak English. They're incompatible. The translator adapts one to the other without changing either side.

• What if the CEO now needs to address a French team? A French translator is brought in. The CEO's process doesn't change. Only the translator changes.

• What if an existing class has a useful method but the wrong interface? You wrap it in an adapter. The rest of the system talks to the adapter while the existing class stays untouched.

In simple terms, you wrap an existing class with a new interface so the client can use it without any changes to either side.

Wikipedia describes it like this:

"In software engineering, the adapter pattern is a software design pattern (also known as wrapper) that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code." (Source)

Programming Example:

The CEO is the client and the Japanese team member is the adaptee. They're useful, but they speak the wrong interface. The Translator is the adapter.

// What the CEO expects, someone who can receive a message in English
public interface IEnglishSpeaker
{
    void Speak(string message);
}

// The Japanese team member, speaks only Japanese (the adaptee)
public class JapaneseTeamMember
{
    public void SpeakJapanese(string message)
    {
        Console.WriteLine($"Team member (Japanese): {message}");
    }
}

// The Translator, adapts the Japanese speaker to the English interface
public class Translator : IEnglishSpeaker
{
    private readonly JapaneseTeamMember _teamMember;

    public Translator(JapaneseTeamMember teamMember)
    {
        _teamMember = teamMember;
    }

    public void Speak(string message)
    {
        string translated = TranslateToJapanese(message);
        _teamMember.SpeakJapanese(translated);
    }

    private string TranslateToJapanese(string english) => english switch
    {
        "Good morning, team."         => "おはようございます、チームの皆さん。",
        "Please review the proposal." => "提案書を確認してください。",
        _                             => $"[Japanese: {english}]"
    };
}

// The CEO, only knows how to talk to an IEnglishSpeaker
public class CEO
{
    private readonly IEnglishSpeaker _speaker;

    public CEO(IEnglishSpeaker speaker)
    {
        _speaker = speaker;
    }

    public void Address(string message)
    {
        Console.WriteLine($"CEO (English): {message}");
        _speaker.Speak(message);
    }
}

Now let's see it in action:

JapaneseTeamMember teamMember = new JapaneseTeamMember();
IEnglishSpeaker translator    = new Translator(teamMember);
CEO ceo = new CEO(translator);

ceo.Address("Good morning, team.");
ceo.Address("Please review the proposal.");

Output:

CEO (English): Good morning, team.
Team member (Japanese): おはようございます、チームの皆さん。
CEO (English): Please review the proposal.
Team member (Japanese): 提案書を確認してください。

The CEO never knew about JapaneseTeamMember. The team never knew about the CEO's interface. The Translator made both sides work together without touching either. That's the Adapter.

When to Use it

Use Adapter when you want to use an existing class but its interface doesn't match what your code expects.

It's also helpful when you want to create a reusable class that cooperates with classes that don't have compatible interfaces.

And reach for it when you need to integrate a third-party library or legacy code without modifying it.

2. The Bridge Design Pattern

Real World Example

Think of a TV remote control and a television. The remote is one thing and the TV is another. You can have a basic remote or a smart remote. You can have a Sony TV or a Samsung TV. Any remote works with any TV you're not locked in. Buy a new Samsung TV, and your old remote still works. Buy a smart universal remote, and it works with every TV you own. Neither side needs to know the inner details of the other.

That's the Bridge. The abstraction (remote) and the implementation (TV) are two separate hierarchies that can grow and change completely independently of each other.

Problems it solves:

• What if every remote was hardwired to one specific TV brand? You would need a SonyBasicRemote, a SamsungBasicRemote, a SonySmartRemote, a SamsungSmartRemote...and so on. One class for every combination. Adding one new TV brand would double your remote classes. The Bridge stops this explosion.

• What if you want to add a new remote type without touching the TVs? With Bridge, you just create a new remote class. The TVs are untouched.

• What if you want to add a new TV brand without touching the remotes? Same answer. You add a new TV class. Every existing remote already works with it.

In simple terms, you split a large class into two separate hierarchies (the abstraction and the implementation) so each can be changed and extended without affecting the other.

Wikipedia describes it like this:

"The bridge pattern is a design pattern used in software engineering that is meant to decouple an abstraction from its implementation so that the two can vary independently." (Source)

Programming Example:

The remote control is the abstraction and the TV brand is the implementation. They're connected through a bridge (the ITV interface), but neither hierarchy depends on the other's details.

// The implementation interface — what any TV must be able to do
public interface ITV
{
    void TurnOn();
    void TurnOff();
    void SetChannel(int channel);
    void SetVolume(int volume);
}

// Concrete implementations — each brand handles things its own way
public class SonyTV : ITV
{
    public void TurnOn()           => Console.WriteLine("Sony TV: Powering on. BRAVIA display ready.");
    public void TurnOff()          => Console.WriteLine("Sony TV: Shutting down.");
    public void SetChannel(int ch) => Console.WriteLine($"Sony TV: Switching to channel {ch}.");
    public void SetVolume(int vol) => Console.WriteLine($"Sony TV: Volume set to {vol}.");
}

public class SamsungTV : ITV
{
    public void TurnOn()           => Console.WriteLine("Samsung TV: Turning on. Smart Hub loading.");
    public void TurnOff()          => Console.WriteLine("Samsung TV: Powering off.");
    public void SetChannel(int ch) => Console.WriteLine($"Samsung TV: Channel {ch} selected.");
    public void SetVolume(int vol) => Console.WriteLine($"Samsung TV: Volume at {vol}.");
}

// The abstraction — the remote holds a reference to whichever TV it controls
public abstract class RemoteControl
{
    protected ITV _tv;

    protected RemoteControl(ITV tv) { _tv = tv; }

    public abstract void TurnOn();
    public abstract void TurnOff();
    public abstract void SetChannel(int channel);
}

// Refined abstraction — a basic remote, does exactly what the TV does
public class BasicRemote : RemoteControl
{
    public BasicRemote(ITV tv) : base(tv) { }

    public override void TurnOn()           => _tv.TurnOn();
    public override void TurnOff()          => _tv.TurnOff();
    public override void SetChannel(int ch) => _tv.SetChannel(ch);
}

// Refined abstraction — a smart remote, adds its own behaviour on top
public class SmartRemote : RemoteControl
{
    public SmartRemote(ITV tv) : base(tv) { }

    public override void TurnOn()
    {
        Console.WriteLine("Smart Remote: Activating voice control.");
        _tv.TurnOn();
    }

    public override void TurnOff()
    {
        Console.WriteLine("Smart Remote: Saving watch history.");
        _tv.TurnOff();
    }

    public override void SetChannel(int ch)
    {
        Console.WriteLine("Smart Remote: Looking up channel guide.");
        _tv.SetChannel(ch);
    }

    public void SetVolume(int vol) => _tv.SetVolume(vol);
}

Now let's see it in action:

// Basic remote paired with a Sony TV
Console.WriteLine("--- Basic Remote + Sony TV ---");
RemoteControl basicSony = new BasicRemote(new SonyTV());
basicSony.TurnOn();
basicSony.SetChannel(5);
basicSony.TurnOff();

// Smart remote paired with a Samsung TV
Console.WriteLine("\n--- Smart Remote + Samsung TV ---");
SmartRemote smartSamsung = new SmartRemote(new SamsungTV());
smartSamsung.TurnOn();
smartSamsung.SetChannel(10);
smartSamsung.SetVolume(20);
smartSamsung.TurnOff();

// Swap freely — smart remote now with Sony, no code changes needed
Console.WriteLine("\n--- Smart Remote + Sony TV ---");
SmartRemote smartSony = new SmartRemote(new SonyTV());
smartSony.TurnOn();
smartSony.SetChannel(3);
smartSony.TurnOff();

Output:

--- Basic Remote + Sony TV ---
Sony TV: Powering on. BRAVIA display ready.
Sony TV: Switching to channel 5.
Sony TV: Shutting down.

--- Smart Remote + Samsung TV ---
Smart Remote: Activating voice control.
Samsung TV: Turning on. Smart Hub loading.
Smart Remote: Looking up channel guide.
Samsung TV: Channel 10 selected.
Samsung TV: Volume at 20.
Smart Remote: Saving watch history.
Samsung TV: Powering off.

--- Smart Remote + Sony TV ---
Smart Remote: Activating voice control.
Sony TV: Powering on. BRAVIA display ready.
Smart Remote: Looking up channel guide.
Sony TV: Switching to channel 3.
Smart Remote: Saving watch history.
Sony TV: Shutting down.

The same SmartRemote worked with both Sony and Samsung without any changes. Adding a new TV brand like LG means creating one new class, and every existing remote works with it immediately. That's the Bridge.

When to Use it

Use the Bridge pattern when you want to avoid a permanent binding between an abstraction and its implementation, so either can be swapped at runtime.

You can also use it when both the abstraction and the implementation should be independently extensible through subclassing.

And it's a good fit when changes to the implementation should have no impact on the client code. The client shouldn't need to be recompiled.

3. The Composite Design Pattern

Real World Example

Think of a company organisation chart. A company has a CEO. Under the CEO are department heads, each leading a department full of employees. Under some departments are even smaller sub-teams.

Now imagine you want to know the total salary cost. You can ask a single employee they tell you their salary. You can ask a whole department, which adds up every person inside it, including nested teams. Or you can ask the entire company: it rolls up every salary across every level.

The same question, asked the same way, whether you're talking to one person or thousands.

That's the Composite pattern. Individual items and groups of items share the same interface. The caller never needs to know which one they're dealing with.

Problems it solves:

• What if you had to write different code to handle a single employee versus a whole department? You would end up with if checks everywhere just to figure out what you're talking to. Composite removes that entirely: one interface, always.

• What if departments can contain other departments? Composite handles any depth of nesting naturally. The caller just asks the top of the tree and the operation flows down automatically.

• What if you want to add a new type of team or role? You implement the same interface. Everything above it in the tree keeps working without any changes.

In simple terms, you compose objects into tree structures. This lets individual objects and groups of objects be treated through the same interface, so the caller never has to care about the difference.

Wikipedia describes it like this:

"The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of object. The intent of a composite is to compose objects into tree structures to represent part-whole hierarchies." (Source)

Programming Example:

Every node in the tree (whether a single employee or an entire department) implements IEmployee. The caller treats them identically.

// The component interface — every leaf and composite shares this contract
public interface IEmployee
{
    string Name    { get; }
    int    GetSalary();
    void   GetDetails(string indent = "");
}

// The leaf — a single employee with no reports
public class Employee : IEmployee
{
    private readonly int _salary;

    public string Name { get; }

    public Employee(string name, int salary)
    {
        Name    = name;
        _salary = salary;
    }

    public int  GetSalary()                    => _salary;
    public void GetDetails(string indent = "") => Console.WriteLine($"{indent}- {Name} (£{_salary:N0})");
}

// The composite — a department that holds employees or other departments
public class Department : IEmployee
{
    private readonly List<IEmployee> _members = new();

    public string Name { get; }

    public Department(string name) { Name = name; }

    public void Add(IEmployee employee)    => _members.Add(employee);
    public void Remove(IEmployee employee) => _members.Remove(employee);

    public int GetSalary() => _members.Sum(m => m.GetSalary());

    public void GetDetails(string indent = "")
    {
        Console.WriteLine($"{indent}[{Name}] Total: £{GetSalary():N0}");
        foreach (var member in _members)
            member.GetDetails(indent + "  ");
    }
}

Now let's see it in action:

// Individual employees
var ceo        = new Employee("Alice (CEO)",        120_000);
var cto        = new Employee("Bob (CTO)",           95_000);
var dev1       = new Employee("Carol (Developer)",   65_000);
var dev2       = new Employee("David (Developer)",   62_000);
var cfo        = new Employee("Eve (CFO)",           90_000);
var accountant = new Employee("Frank (Accountant)",  55_000);

// Build the Engineering department
var engineering = new Department("Engineering");
engineering.Add(cto);
engineering.Add(dev1);
engineering.Add(dev2);

// Build the Finance department
var finance = new Department("Finance");
finance.Add(cfo);
finance.Add(accountant);

// Build the whole company
var company = new Department("Acme Corp");
company.Add(ceo);
company.Add(engineering);
company.Add(finance);

// Ask the whole company — one call, rolls up everything
Console.WriteLine("=== Full Company ===");
company.GetDetails();

// Ask just one department — same call, same interface
Console.WriteLine("\n=== Engineering Only ===");
engineering.GetDetails();

// Ask a single employee — same call, same interface
Console.WriteLine("\n=== Single Employee ===");
dev1.GetDetails();

Output:

=== Full Company ===
[Acme Corp] Total: £487,000
  - Alice (CEO) (£120,000)
  [Engineering] Total: £222,000
    - Bob (CTO) (£95,000)
    - Carol (Developer) (£65,000)
    - David (Developer) (£62,000)
  [Finance] Total: £145,000
    - Eve (CFO) (£90,000)
    - Frank (Accountant) (£55,000)

=== Engineering Only ===
[Engineering] Total: £222,000
  - Bob (CTO) (£95,000)
  - Carol (Developer) (£65,000)
  - David (Developer) (£62,000)

=== Single Employee ===
- Carol (Developer) (£65,000)

company.GetDetails(), engineering.GetDetails(), and dev1.GetDetails(): the same call on three different levels of the tree. The caller never checked what it was talking to. That's the Composite pattern.

When to Use it

Use Composite when you need to represent part-whole hierarchies, like trees where individual items and groups of items need to be used interchangeably.

It also works well when you want client code to treat single objects and collections of objects uniformly, without any special-casing.

And it's a good fit when the structure can be nested to any depth and that depth shouldn't affect how the caller interacts with it.

4. The Decorator Design Pattern

Real World Example

Think of ordering a coffee at a cafe. You start with a plain espresso. Then you ask for milk. Then vanilla syrup. Then whipped cream on top. Each addition wraps around or adds to what was already there, adding its own cost and its own description. The espresso at the centre never changes. You're just layering on top of it, one addition at a time. You could add two shots of syrup. You could skip the milk entirely. Every combination is possible without creating a new type of coffee for each one.

That's the Decorator pattern. You start with a base object and wrap it in layers. Each layer adds its own behaviour and then delegates to whatever is underneath it.

Problems it solves:

• What if you needed a class for every combination? EspressoWithMilk, EspressoWithMilkAndVanilla, EspressoWithMilkAndVanillaAndCream...the list explodes. Decorator adds behaviour at runtime, so you never need those classes.

• What if the base coffee shouldn't change? It does not. The espresso class stays untouched. The decorators wrap around it and extend it independently.

• What if a new topping needs to be added? You create one new decorator class. Every existing combination still works exactly as before.

In simple terms, you wrap an object in one or more layers, where each layer adds its own behaviour before or after delegating to the layer beneath it.

Wikipedia describes it like this:

"The decorator pattern is a design pattern that allows behaviour to be added to an individual object, dynamically, without affecting the behaviour of other instances of the same class." (Source)

Programming Example:

The coffee is the component. Each topping is a decorator. Every decorator wraps the component and adds to its description and cost.

// The component interface — every coffee, plain or decorated, shares this
public interface ICoffee
{
    string GetDescription();
    double GetCost();
}

// The base component — a plain espresso
public class Espresso : ICoffee
{
    public string GetDescription() => "Espresso";
    public double GetCost()        => 1.00;
}

// The base decorator — wraps any ICoffee and delegates to it
public abstract class CoffeeDecorator : ICoffee
{
    protected readonly ICoffee _coffee;

    protected CoffeeDecorator(ICoffee coffee) { _coffee = coffee; }

    public virtual string GetDescription() => _coffee.GetDescription();
    public virtual double GetCost()        => _coffee.GetCost();
}

// Concrete decorators — each one adds its own layer
public class Milk : CoffeeDecorator
{
    public Milk(ICoffee coffee) : base(coffee) { }

    public override string GetDescription() => _coffee.GetDescription() + ", Milk";
    public override double GetCost()        => _coffee.GetCost() + 0.30;
}

public class VanillaSyrup : CoffeeDecorator
{
    public VanillaSyrup(ICoffee coffee) : base(coffee) { }

    public override string GetDescription() => _coffee.GetDescription() + ", Vanilla Syrup";
    public override double GetCost()        => _coffee.GetCost() + 0.50;
}

public class WhippedCream : CoffeeDecorator
{
    public WhippedCream(ICoffee coffee) : base(coffee) { }

    public override string GetDescription() => _coffee.GetDescription() + ", Whipped Cream";
    public override double GetCost()        => _coffee.GetCost() + 0.75;
}

Now let's see it in action:

// A plain espresso
ICoffee order = new Espresso();
Console.WriteLine($"{order.GetDescription()} => £{order.GetCost():F2}");

// Wrap it with milk
order = new Milk(order);
Console.WriteLine($"{order.GetDescription()} => £{order.GetCost():F2}");

// Wrap it with vanilla syrup on top
order = new VanillaSyrup(order);
Console.WriteLine($"{order.GetDescription()} => £{order.GetCost():F2}");

// Wrap it with whipped cream on top of that
order = new WhippedCream(order);
Console.WriteLine($"{order.GetDescription()} => £{order.GetCost():F2}");

Output:

Espresso => £1.00
Espresso, Milk => £1.30
Espresso, Milk, Vanilla Syrup => £1.80
Espresso, Milk, Vanilla Syrup, Whipped Cream => £2.55

Each line is a new layer wrapped around the previous one. The espresso never changed. The cost and description grew with every wrapper. That's the Decorator pattern.

When to Use it

Use the Decorator pattern when you want to add responsibilities to individual objects without affecting other objects of the same class.

It's also a good choice when subclassing would lead to an explosion of classes to cover every possible combination of behaviours.

And use it when you need to be able to stack behaviours in any order at runtime, independently of each other.

5. The Facade Design Pattern

Real World Example

Think of clicking "Place Order" on a shopping website. In that single click, several things happen behind the scenes: the system checks whether the item is in stock, your payment is charged, a shipping label is generated, and a confirmation email is sent to you. You don't see any of that. You click one button and get one result. The complexity of four separate systems is hidden behind a single, clean action.

That's the Facade pattern: one simple interface in front of many complex moving parts. The caller doesn't need to know what's happening behind the scenes.

Problems it solves:

• What if the client had to call each subsystem directly? Check inventory, then process payment, then generate a label, and then send an email, all in the right order, handling each failure separately. The Facade wraps all of that into one call.

• What if one of the subsystems changes? The Facade absorbs the change. The client code never needs to know. Only the Facade is updated.

• What if different clients need the same flow? They all call the same Facade method. The logic is in one place, not duplicated across every caller.

In simple terms, you provide a single, simple interface that hides the complexity of a set of subsystems behind it.

Wikipedia describes it like this:

"The facade pattern (also spelled façade) is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code."(Source)

Programming Example:

Each subsystem does its own job. The OrderFacade is the single entry point that coordinates all of them. The client only ever talks to the facade.

// Subsystem 1: checks whether the item is available
public class InventoryService
{
    public bool CheckStock(string item)
    {
        Console.WriteLine($"Inventory: Checking stock for {item}.");
        return true;
    }
}

// Subsystem 2: handles the payment
public class PaymentService
{
    public bool ProcessPayment(string cardNumber, double amount)
    {
        Console.WriteLine($"Payment: Charging £{amount:F2} to card ending {cardNumber[^4..]}.");
        return true;
    }
}

// Subsystem 3: generates a shipping label
public class ShippingService
{
    public string GenerateLabel(string item, string address)
    {
        Console.WriteLine($"Shipping: Generating label for {item} to {address}.");
        return "TRACK-29384";
    }
}

// Subsystem 4: sends the confirmation email
public class EmailService
{
    public void SendConfirmation(string email, string trackingCode)
    {
        Console.WriteLine($"Email: Confirmation sent to {email}. Tracking code: {trackingCode}.");
    }
}

// The Facade — one method, hides all four subsystems
public class OrderFacade
{
    private readonly InventoryService _inventory = new();
    private readonly PaymentService   _payment   = new();
    private readonly ShippingService  _shipping  = new();
    private readonly EmailService     _email     = new();

    public void PlaceOrder(string item, string cardNumber, double amount, string address, string email)
    {
        Console.WriteLine("=== Placing Order ===");

        if (!_inventory.CheckStock(item))
        {
            Console.WriteLine("Order failed: item out of stock.");
            return;
        }

        if (!_payment.ProcessPayment(cardNumber, amount))
        {
            Console.WriteLine("Order failed: payment declined.");
            return;
        }

        string trackingCode = _shipping.GenerateLabel(item, address);
        _email.SendConfirmation(email, trackingCode);

        Console.WriteLine($"\nOrder complete. Your tracking code is {trackingCode}.");
    }
}

Now let's see it in action:

OrderFacade store = new OrderFacade();

store.PlaceOrder(
    item:       "Wireless Headphones",
    cardNumber: "4111111111111234",
    amount:     79.99,
    address:    "42 Maple Street, London",
    email:      "customer@email.com"
);

Output:

=== Placing Order ===
Inventory: Checking stock for Wireless Headphones.
Payment: Charging £79.99 to card ending 1234.
Shipping: Generating label for Wireless Headphones to 42 Maple Street, London.
Email: Confirmation sent to customer@email.com. Tracking code: TRACK-29384.

Order complete. Your tracking code is TRACK-29384.

The client called one method. Four subsystems ran in the right order. None of that complexity was visible to the caller. That is the Facade.

When to Use it

Use Facade when you want to provide a simple interface to a complex subsystem so callers aren't burdened by its internals.

It also works well when you want to layer your system so that high-level code talks to facades, not directly to low-level subsystems.

And it's a good choice when you want a single entry point that coordinates a sequence of steps across multiple services.

6. The Flyweight Design Pattern

Real World Example

Think of a game that renders a forest. The forest has ten thousand trees. Each tree has a type name, a colour, and a texture. But most of those trees are Oaks, and all Oaks look exactly the same.

Creating ten thousand separate objects, each storing the same name, colour, and texture, wastes enormous amounts of memory. Instead, you create one shared Oak object that holds all that data. Every Oak tree in the forest points to that same shared object and only stores its own position on the map.

That's the Flyweight pattern. The data that's the same across many instances is shared. The data that's unique per instance is stored separately and passed in only when needed.

Problems it solves:

• What if you created a full object for every single tree? With ten thousand trees, you store the same name, colour, and texture ten thousand times. Flyweight stores that shared data once and reuses it everywhere.

• What if a new tree type is introduced? The factory creates one new shared object for it. Every tree of that type immediately uses it without any extra memory.

• What if the forest needs to render each tree at its own position? The position is unique per tree, so it's stored on the tree itself and passed to the shared object only at render time. The shared object never holds it.

In simple terms, you split an object's data into what's shared across many instances and what's unique per instance. Share the common part. Pass the unique part in only when needed.

Wikipedia describes it like this:

"A flyweight is an object that minimizes memory usage by sharing as much data as possible with other similar objects. It is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory." (Source)

Programming ExampleL

TreeType is the flyweight: it holds shared data. Tree holds only the unique position and a reference to a shared TreeType. The factory ensures each TreeType is created only once.

// The flyweight — holds shared intrinsic state (same for all trees of this type)
public class TreeType
{
    public string Name    { get; }
    public string Colour  { get; }
    public string Texture { get; }

    public TreeType(string name, string colour, string texture)
    {
        Name    = name;
        Colour  = colour;
        Texture = texture;
    }

    public void Render(int x, int y)
    {
        Console.WriteLine($"Rendering {Name} tree ({Colour}, {Texture}) at ({x}, {y})");
    }
}

// The flyweight factory — creates and caches tree types so they are never duplicated
public class TreeTypeFactory
{
    private readonly Dictionary<string, TreeType> _cache = new();

    public TreeType GetTreeType(string name, string colour, string texture)
    {
        string key = $"{name}_{colour}_{texture}";

        if (!_cache.ContainsKey(key))
        {
            Console.WriteLine($"Factory: Creating new TreeType for '{name}'.");
            _cache[key] = new TreeType(name, colour, texture);
        }

        return _cache[key];
    }

    public int TotalTypes => _cache.Count;
}

// The context — holds unique extrinsic state (position) and a reference to a shared flyweight
public class Tree
{
    private readonly int      _x;
    private readonly int      _y;
    private readonly TreeType _type;

    public Tree(int x, int y, TreeType type)
    {
        _x    = x;
        _y    = y;
        _type = type;
    }

    public void Render() => _type.Render(_x, _y);
}

// The forest — plants trees using shared flyweights
public class Forest
{
    private readonly List<Tree>      _trees   = new();
    private readonly TreeTypeFactory _factory = new();

    public void PlantTree(int x, int y, string name, string colour, string texture)
    {
        TreeType type = _factory.GetTreeType(name, colour, texture);
        _trees.Add(new Tree(x, y, type));
    }

    public void Render()
    {
        foreach (var tree in _trees)
            tree.Render();
    }

    public int TreeCount     => _trees.Count;
    public int TreeTypeCount => _factory.TotalTypes;
}

Now let's see it in action:

Forest forest = new Forest();

// Plant 6 trees — but only 2 unique types
forest.PlantTree(1,  5,  "Oak",  "Dark Green",  "Rough bark");
forest.PlantTree(3,  12, "Oak",  "Dark Green",  "Rough bark");
forest.PlantTree(7,  2,  "Oak",  "Dark Green",  "Rough bark");
forest.PlantTree(10, 8,  "Pine", "Light Green", "Smooth bark");
forest.PlantTree(15, 3,  "Pine", "Light Green", "Smooth bark");
forest.PlantTree(20, 14, "Pine", "Light Green", "Smooth bark");

forest.Render();

Console.WriteLine($"\nTrees planted:              {forest.TreeCount}");
Console.WriteLine($"Unique tree types in memory: {forest.TreeTypeCount}");

Output:

Factory: Creating new TreeType for 'Oak'.
Factory: Creating new TreeType for 'Pine'.
Rendering Oak tree (Dark Green, Rough bark) at (1, 5)
Rendering Oak tree (Dark Green, Rough bark) at (3, 12)
Rendering Oak tree (Dark Green, Rough bark) at (7, 2)
Rendering Pine tree (Light Green, Smooth bark) at (10, 8)
Rendering Pine tree (Light Green, Smooth bark) at (15, 3)
Rendering Pine tree (Light Green, Smooth bark) at (20, 14)

Trees planted:              6
Unique tree types in memory: 2

Six trees, but only two TreeType objects were ever created. Scale that to ten thousand trees and the factory still creates exactly two. The positions are unique per tree, and the appearance is shared. That's the Flyweight.

When to Use it

Use Flyweight when your application needs to create a very large number of similar objects that would otherwise consume too much memory.

It's also useful when most of the object's state can be made shared across instances, with only a small part being unique per instance.

And it's a good choice when the unique part of the state can be passed in externally rather than stored inside every object.

7. The Proxy Design Pattern

Real World Example

Think of a security guard at the entrance of an office building. You can't walk straight into the building. You have to go through the guard first. The guard checks your name against the authorised list, logs your visit, and only then lets you through. If you're not on the list, you're turned away. The building itself never deals with any of that. It just lets people in. All the checking, logging, and decision-making happens at the guard (the proxy) before the building ever gets involved.

That's the Proxy pattern. It sits between the caller and the real object, controls what gets through, and can add behaviour like access checks or logging without the real object knowing anything about it.

Problems it solves:

• What if anyone could walk straight into the building? There would be no access control. The proxy intercepts every request and decides whether it should be allowed through.

• What if you need to log every entry without changing the building? The proxy handles it. The real building stays simple and focused on its own job.

• What if the real object is expensive to create and you want to delay that? The proxy can hold off creating it until someone actually passes the check and needs it.

In simple terms, you place an object in front of another object to control access to it. The caller thinks it's talking directly to the real object, but the proxy is handling it first.

Wikipedia describes it like this:

"A proxy, in its most general form, is a class functioning as an interface to something else. The proxy could interface to anything: a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate." (Source)

Programming Example:

The client talks to IBuilding. The SecurityGuard is the proxy: it implements the same interface, controls access, and only lets authorised visitors through to the OfficeBuilding.

// The subject interface — the building and the proxy both implement this
public interface IBuilding
{
    void Enter(string visitorName);
}

// The real subject — the actual building, just grants entry
public class OfficeBuilding : IBuilding
{
    public void Enter(string visitorName)
    {
        Console.WriteLine($"Building: {visitorName} has entered.");
    }
}

// The proxy — the security guard controls who gets through
public class SecurityGuard : IBuilding
{
    private readonly OfficeBuilding _building          = new();
    private readonly List<string>   _authorisedVisitors = new() { "Alice", "Bob", "Carol" };

    public void Enter(string visitorName)
    {
        Console.WriteLine($"Guard: {visitorName} is requesting entry.");

        if (_authorisedVisitors.Contains(visitorName))
        {
            Console.WriteLine("Guard: ID verified. Access granted.");
            _building.Enter(visitorName);
        }
        else
        {
            Console.WriteLine($"Guard: {visitorName} is not on the list. Access denied.");
        }
    }
}

Now let's see it in action:

IBuilding entrance = new SecurityGuard();

entrance.Enter("Alice");
Console.WriteLine();
entrance.Enter("David");
Console.WriteLine();
entrance.Enter("Bob");

Output:

Guard: Alice is requesting entry.
Guard: ID verified. Access granted.
Building: Alice has entered.

Guard: David is requesting entry.
Guard: David is not on the list. Access denied.

Guard: Bob is requesting entry.
Guard: ID verified. Access granted.
Building: Bob has entered.

The client called Enter() on what it thought was the building. It was actually the security guard. The guard decided what happened. The building only ever saw the people who were allowed through. That's the Proxy.

When to Use it

Use Proxy when you need access control, like only letting certain callers through to the real object.

It's a good fit when you want to add behaviour such as logging, caching, or validation without changing the real object.

And you can use it when the real object is expensive to create and you want to delay or guard that creation until it's truly needed.

Behavioral Design Patterns

Simply put, behavioral patterns are all about how objects communicate and share responsibility. They focus on the assignment of responsibilities between objects, and how objects cooperate to get a job done.

Wikipedia describes them as:

"In software engineering, behavioral design patterns are design patterns that identify common communication patterns among objects. By doing so, these patterns increase flexibility in carrying out this communication." (Source)

Behavioral design patterns describe how objects interact and distribute responsibility, not just how they're structured. They focus on communication between objects: who talks to whom, and how much each side knows about the other.

There are 11 behavioral design patterns:

1. Chain of Responsibility: Passes a request along a chain of handlers, letting each one decide to handle it or pass it on.

2. Command: Encapsulates a request as an object, letting you parameterize clients, queue actions, and support undo.

3. Interpreter: Given a language, defines a representation for its grammar along with an interpreter that evaluates sentences in it.

4. Iterator: Provides a way to access the elements of a collection sequentially without exposing how it's built underneath.

5. Mediator: Defines an object that encapsulates how a set of objects interact, so they don't refer to each other directly.

6. Memento: Captures an object's internal state so it can be restored later, without breaking encapsulation.

7. Observer: Defines a one-to-many dependency so that when one object changes state, everything depending on it is notified automatically.

8. State: Lets an object change its behaviour when its internal state changes, as if it had changed its class.

9. Strategy: Defines a family of interchangeable algorithms and lets the client pick which one to use at runtime.

10. Template Method: Defines the skeleton of an algorithm in a method, leaving some steps for subclasses to fill in.

11. Visitor: Lets you define a new operation without changing the classes of the elements it operates on.

1. The Chain of Responsibility Design Pattern

Real World Example

Think of an expense approval process at a company. An employee submits a request to their director. If the amount is small enough, the director approves it and that's the end of it. If it's too large for the director to sign off on, it goes up to the vice president. If it's still too large, it goes up to the chief executive.

Each person in the chain only needs to know two things: what they're allowed to approve, and who to hand it to if they can't. The employee never needs to know who ends up approving it.

That's the Chain of Responsibility design pattern. A request travels along a chain of handlers until one of them deals with it, and each handler only cares about its own link in that chain.

Problems it solves:

• What if the sender had to know exactly who should handle the request? That would tie the sender to a specific handler and break the moment the approval structure changed. The chain lets the sender submit the request without knowing who will end up handling it.

• What if one handler could only ever approve or reject, with no fallback? Requests that fell outside its authority would simply fail. The chain lets a handler pass what it can't deal with further along.

• What if you needed to change the approval structure? Rewiring which handler comes after which is enough. Neither the sender nor the other handlers need to change.

In simple terms, you pass a request along a chain of handlers. Each handler decides whether to deal with it or hand it off to the next one in line.

Wikipedia describes it like this:

"In object-oriented design, the chain-of-responsibility pattern is a behavioral design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain."

(Source)

Programming Example:

Each Approver knows its own approval limit and holds a reference to the next approver in the chain. The ExpenseRequest is passed along until someone can approve it, or nobody can.

// The request that travels along the chain
public class ExpenseRequest
{
    public string Description { get; }
    public decimal Amount     { get; }

    public ExpenseRequest(string description, decimal amount)
    {
        Description = description;
        Amount      = amount;
    }
}

// The handler, every link in the chain implements this
public abstract class Approver
{
    private Approver? _next;

    public void SetNext(Approver next) => _next = next;

    public void Approve(ExpenseRequest request)
    {
        if (CanApprove(request))
        {
            Console.WriteLine($"{GetType().Name}: Approved '{request.Description}' (${request.Amount}).");
        }
        else if (_next is not null)
        {
            Console.WriteLine($"{GetType().Name}: Can't approve '{request.Description}' (${request.Amount}). Passing it up.");
            _next.Approve(request);
        }
        else
        {
            Console.WriteLine($"{GetType().Name}: No one left to approve '{request.Description}' (${request.Amount}). Request denied.");
        }
    }

    protected abstract bool CanApprove(ExpenseRequest request);
}

// Concrete handlers, each with its own approval limit
public class Director : Approver
{
    protected override bool CanApprove(ExpenseRequest request) => request.Amount <= 1000;
}

public class VicePresident : Approver
{
    protected override bool CanApprove(ExpenseRequest request) => request.Amount <= 20000;
}

public class Chief : Approver
{
    protected override bool CanApprove(ExpenseRequest request) => request.Amount <= 50000;
}

Now let's see it in action:

Approver directorApprover = new Director();
Approver vpApprover       = new VicePresident();
Approver ceoApprover      = new Chief();

directorApprover.SetNext(vpApprover);
vpApprover.SetNext(ceoApprover);

directorApprover.Approve(new ExpenseRequest("Laptop", 800));
Console.WriteLine();
directorApprover.Approve(new ExpenseRequest("Team offsite", 12000));
Console.WriteLine();
directorApprover.Approve(new ExpenseRequest("New office lease", 90000));

Output:

Director: Approved 'Laptop' ($800).

Director: Can't approve 'Team offsite' ($12000). Passing it up.
VicePresident: Approved 'Team offsite' ($12000).

Director: Can't approve 'New office lease' ($90000). Passing it up.
VicePresident: Can't approve 'New office lease' ($90000). Passing it up.
Chief: No one left to approve 'New office lease' ($90000). Request denied.

The employee only ever talked to the director. Whether the director, the vice president, or the chief ended up approving it, was decided by the chain itself, not the employee.

When to Use it

Use Chain of Responsibility when more than one object might handle a request, and the handler isn't known in advance.

It's also a good choice when you want to issue a request without specifying the receiver explicitly.

And it's helpful when the set of handlers, and their order, should be configurable rather than hard-coded.

2. The Command Design Pattern

Real World Example

Think of a universal remote control. Every button is programmed to do one specific thing: turn a light on, turn a light off, and so on. When you press a button, the remote doesn't know or care how the light actually works internally. It just triggers the action that button was set up to perform. And because each button's action is a self-contained thing, the remote can also press it in reverse, undoing what it just did.

That's the Command pattern. A request "turn the light on" is wrapped up as its own object. The thing that triggers it doesn't need to know anything about how it's carried out.

Problems it solves:

• What if the button had to know exactly how the light worked? Every button would need to be rewritten if the light's internals changed. Wrapping the action as a command means the remote never touches those details.

• What if you wanted to undo the last action? Without a command object there's nothing to reverse, only a completed side effect. Wrapping the action gives you something you can also unwind.

• What if you wanted to queue actions, log them, or trigger them later? A plain method call happens immediately and leaves nothing behind. A command is an object, so it can be stored, queued, and replayed.

In simple terms, you wrap a request up as an object, so the thing that triggers it doesn't need to know how it's carried out, and the action itself can be queued, logged, or undone.

Wikipedia describes it like this:

"The command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time." (Source)

Programming Example:

The RemoteControl is the invoker it only knows about ICommand. LightOnCommand and LightOffCommand are the concrete commands, each wrapping the Light receiver and the action to perform on it.

// The command interface, every action implements this
public interface ICommand
{
    void Execute();
    void Undo();
}

// The receiver, the object that actually does the work
public class Light
{
    private readonly string _room;

    public Light(string room) => _room = room;

    public void On()  => Console.WriteLine($"{_room} light: turned on.");
    public void Off() => Console.WriteLine($"{_room} light: turned off.");
}

// Concrete commands, each wraps a receiver and an action
public class LightOnCommand : ICommand
{
    private readonly Light _light;

    public LightOnCommand(Light light) => _light = light;

    public void Execute() => _light.On();
    public void Undo()    => _light.Off();
}

public class LightOffCommand : ICommand
{
    private readonly Light _light;

    public LightOffCommand(Light light) => _light = light;

    public void Execute() => _light.Off();
    public void Undo()    => _light.On();
}

// The invoker, it holds a command and triggers it without knowing what it does
public class RemoteControl
{
    private ICommand? _command;

    public void SetCommand(ICommand command) => _command = command;

    public void PressButton() => _command?.Execute();
    public void PressUndo()   => _command?.Undo();
}

Now let's see it in action:

var livingRoomLight = new Light("Living Room");
var remote          = new RemoteControl();

remote.SetCommand(new LightOnCommand(livingRoomLight));
remote.PressButton();

remote.SetCommand(new LightOffCommand(livingRoomLight));
remote.PressButton();

Console.WriteLine();
Console.WriteLine("Undoing last action...");
remote.PressUndo();

Output:

Living Room light: turned on.
Living Room light: turned off.

Undoing last action...
Living Room light: turned on.

The remote never called _light.On() or _light.Off() directly. It called Execute() and Undo() on whatever command it was holding. That's the Command pattern: the request itself became an object.

When to Use it

Use the Command pattern when you want to parameterize objects with an action to perform, rather than hard-coding it.

Reach for it when you need to queue, log, or support undo for requests.

And consider it when you want to decouple the object that invokes an action from the object that knows how to perform it.

3. The Interpreter Design Pattern

Real World Example

Think of a basic calculator reading an expression like (5 + 3) - 2. Nobody hardcodes a single method that handles every possible expression. Instead, the expression is broken down into small pieces: numbers and operation buttons, each of which knows how to evaluate itself and combine with the others. (5 + 3) - 2 becomes a subtraction of two things: the number 2, and the result of adding 5 and 3. Each piece only needs to know how to interpret itself.

That's the Interpreter pattern. A grammar is represented as a tree of small objects, and each one knows how to evaluate its own little piece of it.

Problems it solves:

• What if you tried to evaluate an entire expression in one big method? It would grow unmanageable the moment the grammar got more complex. Breaking the grammar into small classes, one per rule, keeps each piece simple.

• What if the grammar needed to grow? Adding a new operation, like multiplication, is just a new class. The existing pieces don't need to change.

• What if the same expression needed to be evaluated more than once, or in different contexts? Because each piece is just an object, the same tree can be interpreted again without rebuilding it.

In simple terms, you represent a grammar as a tree of small objects, where each object knows how to interpret its own piece of the expression.

Wikipedia describes it like this:

"In computer programming, the interpreter pattern is a design pattern that specifies how to evaluate sentences in a language. The basic idea is to have a class for each symbol (terminal or nonterminal) in a specialized computer language." (Source)

Programming Example:

Number is the terminal expression, a plain value. Add and Subtract are non-terminal expressions, each combining two other expressions. Every node, terminal or not, knows how to Interpret() itself.

// The abstract expression, every node in the grammar implements this
public abstract class Expression
{
    public abstract int Interpret();
}

// A terminal expression, a plain number that needs no further interpretation
public class Number : Expression
{
    private readonly int _value;

    public Number(int value) => _value = value;

    public override int Interpret() => _value;
}

// Non-terminal expressions, each combines other expressions
public class Add : Expression
{
    private readonly Expression _left;
    private readonly Expression _right;

    public Add(Expression left, Expression right)
    {
        _left  = left;
        _right = right;
    }

    public override int Interpret() => _left.Interpret() + _right.Interpret();
}

public class Subtract : Expression
{
    private readonly Expression _left;
    private readonly Expression _right;

    public Subtract(Expression left, Expression right)
    {
        _left  = left;
        _right = right;
    }

    public override int Interpret() => _left.Interpret() - _right.Interpret();
}

Now let's see it in action:

// (5 plus 3) minus 2
Expression expression = new Subtract(
    new Add(new Number(5), new Number(3)),
    new Number(2)
);

Console.WriteLine($"Result: {expression.Interpret()}");

// (10 minus 4) plus (2 plus 2)
Expression another = new Add(
    new Subtract(new Number(10), new Number(4)),
    new Add(new Number(2), new Number(2))
);

Console.WriteLine($"Result: {another.Interpret()}");

Output:

Result: 6
Result: 10

Nothing ever evaluated the whole expression at once. Subtract asked its own _left and _right to interpret themselves, and those asked their own children, all the way down to plain numbers. That's the Interpreter pattern: the grammar interprets itself, one small piece at a time.

When to Use it

Use Interpreter when you have a simple language or grammar to evaluate, and representing it as a tree of expressions keeps it manageable.

It also works well when the grammar is relatively stable. For example, adding new rules means adding new classes, not rewriting existing ones.

And it's useful when you would rather have many small, focused classes than one large method trying to parse and evaluate everything at once.

4. The Iterator Design Pattern

Real World Example

Think of a bookshelf. You want to go through it one book at a time, from left to right, without needing to know whether the books are held in an array, multiple piles and stacks, or something else entirely. All you need is a way to ask "what's next?" and to know when you've reached the end. How the shelf actually stores its books internally is none of your concern.

That's the Iterator pattern. It gives you a consistent way to step through a collection, one element at a time, without exposing how that collection is built underneath.

Problems it solves:

• What if the client had to know how the collection was stored internally to loop over it? Any change to that internal structure would break every piece of code that loops over it. The iterator hides that structure behind a simple "get next" interface.

• What if you needed more than one traversal in progress at the same time? A single shared position wouldn't work. Each iterator keeps its own position, so multiple traversals can happen independently.

• What if you wanted to loop over the collection using the language's own foreach? Implementing the iterator interface the language expects means your custom collection gets that support for free.

In simple terms, you give a collection a way to be walked through, one element at a time, without exposing how it's actually built underneath.

Wikipedia describes it like this:

"In object-oriented programming, the iterator pattern is a design pattern in which an iterator is used to traverse a container and access the container's elements." (Source)

Programming Example:

Bookshelf is the aggregate it exposes an IEnumerator<string> without revealing that it stores books in a List<string> internally. BookshelfIterator is the iterator that walks through them one at a time.

// The aggregate, exposes an iterator without revealing how books are stored
public class Bookshelf : IEnumerable<string>
{
    private readonly List<string> _books = new();

    public void Add(string title) => _books.Add(title);

    public IEnumerator<string> GetEnumerator() => new BookshelfIterator(_books);

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();
}

// The iterator, walks the collection one book at a time
public class BookshelfIterator : IEnumerator<string>
{
    private readonly List<string> _books;
    private int _position = -1;

    public BookshelfIterator(List<string> books) => _books = books;

    public string Current => _books[_position];

    object IEnumerator.Current => Current;

    public bool MoveNext()
    {
        _position++;
        return _position < _books.Count;
    }

    public void Reset() => _position = -1;

    public void Dispose() { }
}

Now let's see it in action:

var bookshelf = new Bookshelf();
bookshelf.Add("Clean Code");
bookshelf.Add("The Pragmatic Programmer");
bookshelf.Add("Design Patterns");

foreach (var book in bookshelf)
{
    Console.WriteLine($"On the shelf: {book}");
}

Output:

On the shelf: Clean Code
On the shelf: The Pragmatic Programmer
On the shelf: Design Patterns

The foreach loop never touched the List<string> inside Bookshelf directly. It called MoveNext() and Current on the BookshelfIterator, one step at a time. That's the Iterator pattern: the traversal logic lives outside the collection itself.

When to Use it

Use Iterator when you want to traverse a collection without exposing its internal structure.

It's also a good choice when you need to support multiple simultaneous traversals over the same collection.

And try it when you want your custom collection to work with the language's built-in iteration syntax, like foreach.

5. The Mediator Design Pattern

Real World Example

Think of an air traffic control tower. Planes don't radio each other directly to negotiate who lands first. That would be chaos: dozens of pilots all trying to coordinate with each other at once.

Instead, every plane talks only to the tower. The tower knows the state of the runway and tells each plane what to do. The planes never need to know how many other planes are around, or what they're doing.

That's the Mediator pattern. Instead of objects talking to each other directly, they all talk to one central object that coordinates them.

Problems it solves:

• What if every aircraft had to communicate directly with every other aircraft? The number of connections would explode as more aircraft joined, and each one would need to know about all the others. The mediator means each aircraft only needs to know about the tower.

• What if the coordination logic was scattered across every object involved? Changing how landings get prioritised would mean touching every aircraft. With a mediator, that logic lives in one place.

• What if you wanted to add a new aircraft to the system? It only needs to know how to talk to the tower. It doesn't need to be introduced to every other aircraft already in the sky.

In simple terms, instead of letting objects talk to each other directly, you route all communication through one central object that knows how to coordinate them.

Wikipedia describes it like this:

"In software engineering, the mediator pattern defines an object that encapsulates how a set of objects interact. This pattern is considered to be a behavioral pattern due to the way it can alter the program's running behavior." (Source)

Programming Example:

ControlTower is the mediator. It's the only thing an Aircraft ever talks to. It decides whether a plane can land based on the state it holds, and no aircraft ever contacts another aircraft directly.

// The mediator interface
public interface IControlTower
{
    void RequestLanding(Aircraft requester);
}

// The concrete mediator, coordinates all the aircraft instead of letting them talk to each other
public class ControlTower : IControlTower
{
    private readonly List<Aircraft> _aircraft = new();
    private bool _runwayFree = true;

    public void Register(Aircraft aircraft) => _aircraft.Add(aircraft);

    public void RequestLanding(Aircraft requester)
    {
        if (_runwayFree)
        {
            _runwayFree = false;
            Console.WriteLine($"Tower: Runway clear. {requester.Name}, you are cleared to land.");
        }
        else
        {
            Console.WriteLine($"Tower: Runway occupied. {requester.Name}, please hold your position.");
        }
    }
}

// The colleague, only ever talks to the mediator, never to other aircraft directly
public class Aircraft
{
    public string Name { get; }

    private readonly IControlTower _tower;

    public Aircraft(string name, IControlTower tower)
    {
        Name   = name;
        _tower = tower;
    }

    public void RequestLanding()
    {
        Console.WriteLine($"{Name}: Requesting permission to land.");
        _tower.RequestLanding(this);
    }
}

Now let's see it in action:

var tower = new ControlTower();

var flight101 = new Aircraft("Flight 101", tower);
var flight202 = new Aircraft("Flight 202", tower);

tower.Register(flight101);
tower.Register(flight202);

flight101.RequestLanding();
flight202.RequestLanding();

Output:

Flight 101: Requesting permission to land.
Tower: Runway clear. Flight 101, you are cleared to land.
Flight 202: Requesting permission to land.
Tower: Runway occupied. Flight 202, please hold your position.

Flight 101 and Flight 202 never spoke to each other. Neither one even knows the other exists. Both only ever talked to the tower, and the tower decided what happened next. That's the Mediator pattern.

When to Use it

Use Mediator when a group of objects communicate in complex, tangled ways, and you want to centralise that communication.

It's also helpful when you want to reuse objects independently, without them being locked together by direct references to each other.

And reach for it when the way objects interact changes often, and you'd rather change it in one place than in every object involved.

6. The Memento Design Pattern

Real World Example

Think of the undo history in a text editor. Every so often, the editor quietly takes a snapshot of what the document looks like. It doesn't ask the document to expose its internals to do this. It just captures a copy of the content at that moment.

When you press undo, the editor hands that snapshot back, and the document restores itself to exactly how it was. The history keeps a pile of these snapshots, but it never looks inside them or changes them. It only stores them and hands them back.

That's the Memento pattern. It lets you capture and restore an object's state without exposing how that state is structured internally.

Problems it solves:

• What if undo required exposing every private field of the document? That would break encapsulation, and any change to the document's internals would ripple out to whatever handles undo. The memento hides that structure inside an object only the document itself knows how to read.

• What if the history needed to inspect or modify old snapshots? It shouldn't be able to. The caretaker only stores and returns mementos, it never reads or changes what's inside them.

• What if you needed several restore points, not just one? Because each memento is just an object, they can be stacked, listed, or discarded, giving you as many restore points as you want to keep.

In simple terms, you capture an object's state in a snapshot you can restore later, without exposing how that state is put together internally.

Wikipedia describes it like this:

"The memento pattern is a software design pattern that provides the ability to restore an object to its previous state (undo via rollback)."

(Source)

Programming Example:

TextEditor is the originator: it creates EditorMemento snapshots of itself and can restore from one. History is the caretaker: it stores mementos on a stack without ever looking inside them.

// The memento, an immutable snapshot of the editor's state
public class EditorMemento
{
    public string Content { get; }

    public EditorMemento(string content) => Content = content;
}

// The originator, creates and restores from mementos of its own state
public class TextEditor
{
    public string Content { get; private set; } = string.Empty;

    public void Write(string text) => Content += text;

    public EditorMemento Save() => new(Content);

    public void Restore(EditorMemento memento) => Content = memento.Content;
}

// The caretaker, stores mementos without ever looking inside them
public class History
{
    private readonly Stack<EditorMemento> _snapshots = new();

    public void Save(EditorMemento memento) => _snapshots.Push(memento);

    public EditorMemento Undo() => _snapshots.Pop();
}

Now let's see it in action:

var editor  = new TextEditor();
var history = new History();

editor.Write("Hello");
history.Save(editor.Save());

editor.Write(", world");
history.Save(editor.Save());

editor.Write("!!!");
Console.WriteLine($"Current: {editor.Content}");

editor.Restore(history.Undo());
Console.WriteLine($"After undo: {editor.Content}");

editor.Restore(history.Undo());
Console.WriteLine($"After undo: {editor.Content}");

Output:

Current: Hello, world!!!
After undo: Hello, world
After undo: Hello

History never read or changed the text inside a snapshot. It just pushed mementos on and popped them off. Only TextEditor knew what to do with the content inside one. That's the Memento pattern.

When to Use it

Use Memento when you need undo/redo functionality and want to capture state without exposing an object's internals.

It's also a good choice when taking a snapshot directly would break encapsulation by exposing private fields.

And it's helpful when you want the object that stores history to stay dumb: like holding snapshots without knowing or caring what's inside them.

7. The Observer Design Pattern

Real World Example

Think of subscribing to a YouTube channel. You don't sit there refreshing the page, checking if a new video has been uploaded. You subscribe once, and the moment the channel uploads something, you get notified automatically.

The channel doesn't know or care what each subscriber does with that notification. It just knows it has a list of subscribers, and when something changes, it tells all of them.

That's the Observer pattern. One object holds a list of dependents, and whenever its state changes, it notifies every one of them automatically.

Problems it solves:

• What if every subscriber had to keep checking the channel for updates? That would waste effort and add delay. The channel notifying its subscribers directly means they find out the moment it happens.

• What if the channel had to know exactly what each subscriber wanted to do with a new video? It shouldn't need to. The channel only calls Notify(), each subscriber decides for itself what that means.

• What if you wanted to add or remove subscribers at runtime? The channel doesn't need to change. It just keeps a list, and subscribing or unsubscribing only ever affects that list.

In simple terms, one object keeps a list of dependents and automatically notifies all of them whenever its own state changes.

Wikipedia describes it like this:

"The observer pattern is a software design pattern in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods." (Source)

Programming Example:

YouTubeChannel is the subject: it keeps a list of ISubscribers and notifies all of them whenever a video is uploaded. Subscriber is the concrete observer, deciding for itself what to do with that notification.

// The observer interface, every subscriber implements this
public interface ISubscriber
{
    void Notify(string channelName, string videoTitle);
}

// The concrete observer
public class Subscriber : ISubscriber
{
    private readonly string _name;

    public Subscriber(string name) => _name = name;

    public void Notify(string channelName, string videoTitle)
    {
        Console.WriteLine($"{_name}: {channelName} just uploaded '{videoTitle}'!");
    }
}

// The subject, keeps track of its subscribers and notifies them of changes
public class YouTubeChannel
{
    private readonly string _name;
    private readonly List<ISubscriber> _subscribers = new();

    public YouTubeChannel(string name) => _name = name;

    public void Subscribe(ISubscriber subscriber)   => _subscribers.Add(subscriber);
    public void Unsubscribe(ISubscriber subscriber) => _subscribers.Remove(subscriber);

    public void UploadVideo(string title)
    {
        Console.WriteLine($"{_name}: Uploaded '{title}'.");

        foreach (var subscriber in _subscribers)
        {
            subscriber.Notify(_name, title);
        }
    }
}

Now let's see it in action:

var channel = new YouTubeChannel("Code With Isaiah");

var alice = new Subscriber("Alice");
var bob   = new Subscriber("Bob");

channel.Subscribe(alice);
channel.Subscribe(bob);

channel.UploadVideo("Design Patterns Explained");

channel.Unsubscribe(bob);
channel.UploadVideo("Understanding the Observer Pattern");

Output:

Code With Isaiah: Uploaded 'Design Patterns Explained'.
Alice: Code With Isaiah just uploaded 'Design Patterns Explained'!
Bob: Code With Isaiah just uploaded 'Design Patterns Explained'!
Code With Isaiah: Uploaded 'Understanding the Observer Pattern'.
Alice: Code With Isaiah just uploaded 'Understanding the Observer Pattern'!

Once Bob unsubscribed, he stopped hearing about new uploads entirely. The channel never singled him out, it just no longer had him on the list it notifies. That's the Observer pattern.

When to Use it

Use Observer when a change to one object should automatically update an unknown number of others.

It's also useful when you want objects to stay loosely coupled: the subject only knows about an observer interface, never concrete details.

And it's a good option when the number of dependents can grow or shrink at runtime, such as subscribing and unsubscribing.

8. The State Design Pattern

Real World Example

Think of an online order moving through its lifecycle: pending, then shipped, then delivered. What "moving to the next step" actually means is different at every stage. From pending it means handing the package to a courier. From shipped it means marking it as received. From delivered, there's nowhere left to go. Rather than one giant method full of if checks for every possible stage, each stage can just know what comes after it.

That's the State pattern. The object's behaviour changes based on its current state, and each state knows how to transition to the next one.

Problems it solves:

• What if one method had to handle every stage with a long chain of conditionals? It would grow harder to follow every time a new stage was added. Giving each stage its own class keeps the logic for that stage self-contained.

• What if adding a new stage meant editing that same giant method? It's easy to introduce a bug in an unrelated stage while doing so. A new state is just a new class, dropped in alongside the others.

• What if the object needed to behave completely differently depending on where it was in its lifecycle? Delegating to the current state object means the context doesn't need to know the details. It just asks the current state what to do.

In simple terms, you let an object change its behaviour by changing which state object it's currently holding, so the object appears to change how it acts as its state changes.

Wikipedia describes it like this:

"The state pattern is a behavioral software design pattern that allows an object to alter its behavior when its internal state changes. This pattern is close to the concept of finite-state machines." (Source)

Programming Example:

Order is the context: it holds whatever IOrderState it's currently in and delegates to it. Each concrete state, PendingState, ShippedState, DeliveredState, knows what the next state should be.

// The state interface, every state implements this
public interface IOrderState
{
    void Next(Order order);
    string Name { get; }
}

// The context, delegates behaviour to whatever state it currently holds
public class Order
{
    public IOrderState State { get; set; } = new PendingState();

    public void Next()
    {
        Console.WriteLine($"Order is currently: {State.Name}");
        State.Next(this);
    }
}

// Concrete states, each knows what comes after it
public class PendingState : IOrderState
{
    public string Name => "Pending";

    public void Next(Order order) => order.State = new ShippedState();
}

public class ShippedState : IOrderState
{
    public string Name => "Shipped";

    public void Next(Order order) => order.State = new DeliveredState();
}

public class DeliveredState : IOrderState
{
    public string Name => "Delivered";

    public void Next(Order order)
    {
        Console.WriteLine("Order has already been delivered. Nothing left to do.");
    }
}

Now let's see it in action:

var order = new Order();

order.Next();
order.Next();
order.Next();
order.Next();

Output:

Order is currently: Pending
Order is currently: Shipped
Order is currently: Delivered
Order has already been delivered. Nothing left to do.

Order never checked "if pending, do this, if shipped, do that." It just asked its current state what to do next, and the state itself decided what came after. That's the State pattern.

When to Use it

Use State when an object's behaviour depends on its state, and it must change that behaviour at runtime as the state changes.

It's also helpful when you have large conditional blocks that branch on the object's current state or type.

And choose it when transitions between states should be explicit and self-contained, rather than scattered across one big method.

9. The Strategy Design Pattern

Real World Example

Think of checking out of an online store. You can pay by credit card, or you can pay through PayPal. The shopping cart doesn't care which one you pick. It just knows the total, hands it to whichever payment method you chose, and lets that method handle the details of actually charging you. Swap the payment method, and the cart's own code never changes.

That's the Strategy pattern. An algorithm (in this case "how to pay") is pulled out into its own interchangeable object, and the client just picks which one to use.

Problems it solves:

• What if the cart had a big if/else for every payment method? Adding a new one would mean editing that method every time. Pulling each payment method out into its own class means the cart never needs to change.

• What if you wanted to swap the algorithm at runtime? A hardcoded method can't be swapped. A strategy object can simply be replaced with another one that implements the same interface.

• What if two different payment methods needed to share a common interface but nothing else? Each one implements the strategy interface, but its internal details (a card number here, an email there) stay private to it.

In simple terms, you pull an algorithm out into its own interchangeable object, so the class using it doesn't need to know or care which specific version is running.

Wikipedia describes it like this:

"The strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime." (Source)

Programming Example:

ShoppingCart is the context: it holds an IPaymentStrategy and delegates the actual payment to it. CreditCardPayment and PayPalPayment are concrete strategies, each a different way to pay.

// The strategy interface, every payment method implements this
public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

// Concrete strategies, each a different way to pay
public class CreditCardPayment : IPaymentStrategy
{
    private readonly string _cardNumber;

    public CreditCardPayment(string cardNumber) => _cardNumber = cardNumber;

    public void Pay(decimal amount)
    {
        Console.WriteLine($"Charged ${amount} to credit card ending in {_cardNumber[^4..]}.");
    }
}

public class PayPalPayment : IPaymentStrategy
{
    private readonly string _email;

    public PayPalPayment(string email) => _email = email;

    public void Pay(decimal amount)
    {
        Console.WriteLine($"Charged ${amount} via PayPal account {_email}.");
    }
}

// The context, holds a strategy and delegates the actual payment work to it
public class ShoppingCart
{
    private readonly decimal _total;
    private IPaymentStrategy? _paymentMethod;

    public ShoppingCart(decimal total) => _total = total;

    public void SetPaymentMethod(IPaymentStrategy method) => _paymentMethod = method;

    public void Checkout()
    {
        if (_paymentMethod is null)
        {
            Console.WriteLine("No payment method selected.");
            return;
        }

        _paymentMethod.Pay(_total);
    }
}

Now let's see it in action:

var cart = new ShoppingCart(59.99m);

cart.SetPaymentMethod(new CreditCardPayment("4111 1111 1111 1111"));
cart.Checkout();

cart.SetPaymentMethod(new PayPalPayment("isaiah@example.com"));
cart.Checkout();

Output:

Charged $59.99 to credit card ending in 1111.
Charged $59.99 via PayPal account isaiah@example.com.

ShoppingCart never knew how a payment actually got processed. It just called Pay() on whatever strategy it was holding at the time. That's the Strategy pattern: the algorithm is swapped out, the class using it stays exactly the same.

When to Use it

Use Strategy when you have several variants of an algorithm, and want to switch between them at runtime.

It's also helpful when you want to avoid a class full of conditionals that pick behaviour based on a type or flag.

And it's a solid choice when related classes only differ in the behaviour they use, and that behaviour should be interchangeable.

10. The Template Method Design Pattern

Real World Example

Think of making a hot drink, tea or coffee. Both follow the exact same basic steps: boil water, brew, pour into a cup, and add something to taste. What differs is only two of those steps: tea gets steeped, and coffee gets brewed through grounds. Tea gets lemon, and coffee gets sugar and milk. The overall recipe never changes, only the specific details of a couple of steps within it.

That's the Template Method pattern. A base class defines the fixed skeleton of an algorithm, and subclasses only fill in the steps that are actually allowed to vary.

Problems it solves:

• What if every beverage repeated the entire recipe from scratch? Boiling water and pouring into a cup would be duplicated in every single class. The template method keeps those steps in one place, written once.

• What if a subclass could reorder the steps, or skip one entirely? That would let each beverage break the overall recipe. Because the algorithm's skeleton lives in the base class as a single method, the order and structure stay fixed.

• What if you wanted to add a new beverage? Only the steps that differ, brewing and condiments, need to be written. Everything else is already handled by the base class.

In simple terms, you define the fixed skeleton of an algorithm in a base class, and let subclasses fill in only the steps that are actually allowed to differ.

Wikipedia describes it like this:

"In object-oriented programming, the template method is one of the behavioral design patterns identified by Gamma et al. in the book Design Patterns. The template method is a method in a superclass, usually an abstract superclass, and defines the skeleton of an operation in terms of a number of high-level steps." (Source)

Programming Example:

Beverage defines Prepare() as the template method: the fixed sequence of steps. Tea and Coffee only override Brew() and AddCondiments(), the two steps that are actually allowed to vary.

// The abstract class, defines the skeleton of the algorithm
public abstract class Beverage
{
    // The template method, the steps and their order never change
    public void Prepare()
    {
        BoilWater();
        Brew();
        PourInCup();
        AddCondiments();
    }

    private void BoilWater() => Console.WriteLine("Boiling water.");
    private void PourInCup() => Console.WriteLine("Pouring into cup.");

    // Steps left for subclasses to fill in
    protected abstract void Brew();
    protected abstract void AddCondiments();
}

// A concrete class, fills in the steps specific to tea
public class Tea : Beverage
{
    protected override void Brew() => Console.WriteLine("Steeping the tea bag.");
    protected override void AddCondiments() => Console.WriteLine("Adding lemon.");
}

// Another concrete class, fills in the steps specific to coffee
public class Coffee : Beverage
{
    protected override void Brew() => Console.WriteLine("Brewing the coffee grounds.");
    protected override void AddCondiments() => Console.WriteLine("Adding sugar and milk.");
}

Now let's see it in action:

Beverage tea    = new Tea();
Beverage coffee = new Coffee();

tea.Prepare();
Console.WriteLine();
coffee.Prepare();

Output:

Boiling water.
Steeping the tea bag.
Pouring into cup.
Adding lemon.

Boiling water.
Brewing the coffee grounds.
Pouring into cup.
Adding sugar and milk.

Both drinks boiled water and poured into a cup in exactly the same way, because Prepare() in the base class handled that. Only brewing and condiments changed, because those were the steps each subclass was actually responsible for. That's the Template Method pattern.

When to Use it

Use Template Method when several classes share the same overall algorithm, but differ in a few specific steps.

It's a good choice when you want to enforce a fixed sequence of steps, while still letting subclasses customise parts of it.

And it's helpful when you want to avoid duplicating the parts of an algorithm that never change across every subclass.

11. The Visitor Design Pattern

Real World Example

Think of a shopping cart with different kinds of items: books and electronics, each taxed differently at checkout. You don't want to bake pricing logic into the Book and Electronic classes themselves, especially if you'll need other operations on them later too, like generating a shipping label or a warranty summary. Instead, each item just accepts a visitor and hands itself over. The visitor is the one that actually knows how to price a book differently from an electronic.

That's the Visitor pattern. The operation lives outside the objects it acts on, and each object just lets the visitor know what it needs to know: what type of thing it actually is.

Problems it solves:

• What if pricing logic was written directly inside Book and Electronic? Every new operation (tax, shipping, warranty) would mean editing both classes again and again. The visitor keeps each new operation in its own self-contained class instead.

• What if you needed to add a new operation without touching the existing item classes? Normally that means modifying every class the operation applies to. A new visitor is a new class, while Book and Electronic never change.

• What if a generic loop had to guess the concrete type of each item? That usually means a chain of type checks. Accept() calling Visit(this) lets the compiler pick the right overload automatically, without a single if or type check.

In simple terms, you move an operation out of the objects it acts on and into its own class. Each object just accepts a visitor and lets it know what concrete type it is.

Wikipedia describes it like this:

"The visitor design pattern is a way of separating an algorithm from an object structure on which it operates." (Source)

Programming Example:

Book and Electronic both implement IItem and simply call visitor.Visit(this). PricingVisitor implements IVisitor with an overload for each concrete type, so the right pricing logic runs automatically.

// The element interface, every item in the cart implements this
public interface IItem
{
    void Accept(IVisitor visitor);
}

// Concrete elements, each accepts a visitor and hands itself over
public class Book : IItem
{
    public string Title { get; }
    public decimal Price { get; }

    public Book(string title, decimal price)
    {
        Title = title;
        Price = price;
    }

    public void Accept(IVisitor visitor) => visitor.Visit(this);
}

public class Electronic : IItem
{
    public string Name { get; }
    public decimal Price { get; }

    public Electronic(string name, decimal price)
    {
        Name  = name;
        Price = price;
    }

    public void Accept(IVisitor visitor) => visitor.Visit(this);
}

// The visitor interface, one Visit overload per concrete element
public interface IVisitor
{
    void Visit(Book book);
    void Visit(Electronic electronic);
}

// A concrete visitor, adds a new operation without touching Book or Electronic
public class PricingVisitor : IVisitor
{
    public decimal Total { get; private set; }

    public void Visit(Book book)
    {
        Console.WriteLine($"Book: {book.Title} — ${book.Price:F2} (no tax).");
        Total += book.Price;
    }

    public void Visit(Electronic electronic)
    {
        var priceWithTax = electronic.Price * 1.15m;
        Console.WriteLine($"Electronic: {electronic.Name} — ${priceWithTax:F2} (with 15% tax).");
        Total += priceWithTax;
    }
}

Now let's see it in action:

var cart = new List<IItem>
{
    new Book("Design Patterns", 45.00m),
    new Electronic("Headphones", 120.00m)
};

var pricingVisitor = new PricingVisitor();

foreach (var item in cart)
{
    item.Accept(pricingVisitor);
}

Console.WriteLine($"Total: ${pricingVisitor.Total:F2}");

Output:

Book: Design Patterns — $45.00 (no tax).
Electronic: Headphones — $138.00 (with 15% tax).
Total: $183.00

Neither Book nor Electronic contained a single line of pricing logic. Each one only knew how to Accept() a visitor. PricingVisitor was the one that actually decided how each type gets priced. That's the Visitor pattern: the operation lives outside the object structure, not inside it.

When to Use it

Use Visitor when you need to perform operations across a group of unrelated classes, without polluting each class with that logic.

It's also helpful when you want to add new operations often, but the object structure itself rarely changes.

And it's a good choice when you'd otherwise need type checks or casting to figure out what to do with each object in a collection.

Conclusion

That covers all 23 classic design patterns across the three families: Creational, Structural, and Behavioral.

None of them are rules you must follow. They're answers to problems that show up again and again in software: how to create objects without hard-coding their exact type, how to compose bigger structures out of smaller ones, and how to let objects communicate without being tightly bound to each other.

A few things worth remembering:

• You won't use most of these patterns most of the time. Recognising when a problem calls for one is the actual skill. Forcing a pattern onto a problem that doesn't need it usually makes the code harder to follow, not easier.

• The real world analogies exist to build intuition, not to be taken literally. Once a pattern's shape clicks in a story you understand, spotting it in real code becomes far easier.

• Patterns compose. A Factory Method might produce objects that are themselves Decorators. A Composite tree might be built with a Builder. Real systems mix and layer patterns rather than using them in isolation.

• The language doesn't matter. Every example here is in C#, but the same shapes exist in Python, Java, TypeScript, Go, Rust, and beyond. If you understand the problem a pattern solves, translating it to any language is straightforward.

The goal isn't to memorise 23 names. It's to recognise the recurring problems underneath them, so that when one shows up in your own code, you already know a proven shape for solving it.

"Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

Source: Christopher Alexander, A Pattern Language — the architectural work that originally inspired software design patterns.

If this handbook was useful, the source lives at github.com/Clifftech123/design-patterns-handbook. Star it, fork it, or open a PR with a pattern you think is missing.

With the release of Swift 6 and its new Embedded Swift compilation mode, developers now have access to a modern, memory-safe, and performant alternative that’s tailored specifically for resource-constrained systems.

While languages like Rust have also emerged to address these issues, Embedded Swift brings the clarity and safety of Swift to microcontroller environments, without giving up on determinism, binary size, or hardware access.

This article introduces Embedded Swift and explores how it compares to traditional C/C++ development. We’ll cover its key features, programming and memory models, how to set up the toolchain for STM32 microcontrollers, and how to link Swift with existing C drivers.

Along the way, we’ll examine performance trade-offs, growing ecosystem support, and the broader industry movement toward memory-safe languages. As I hope you’ll see, Swift is a serious contender in the future of embedded development.

Prerequisites

To get the most out of this article, you should have a basic understanding of programming in Swift and C. Familiarity with embedded hardware platforms and firmware development concepts will also be helpful.

If you're new to embedded systems, consider reviewing this introductory guide to embedded firmware to build foundational knowledge before diving into Embedded Swift.

Scope

This article is intended as a practical introduction to Embedded Swift. It covers:

• An overview of Embedded Swift and its key language features

• Swift’s programming and memory model in an embedded context

• Setting up the Embedded Swift toolchain on macOS for STM32 microcontrollers

• Interoperability with C code and linking to existing low-level drivers

• A look at memory and instruction-level performance

• Future directions and use cases for Embedded Swift

Note that this article does not provide a full tutorial on the Swift language itself. While the primary focus is on STM32, similar principles apply to other supported platforms such as ESP32, Raspberry Pi Pico, and nRF52.

Table of Contents:

• What is Swift? What is Embedded Swift?

• Swift Programming Model

• Swift Memory Management

• Memory and Instruction Cycle Comparison

• How to Setup Embedded Swift

• C-Swift Linkages:

• Future Work

• Conclusion

What is Swift? What is Embedded Swift?

Swift is a modern programming language developed by Apple that combines the performance of compiled languages with the expressiveness and safety of modern language design. While Swift was originally created for iOS and macOS development, it has evolved into a powerful general-purpose language used in server-side development, systems programming, and increasingly, embedded systems.

Embedded Swift is a special compilation mode introduced in Swift 6 that brings the benefits of Swift to resource-constrained platforms like microcontrollers. It lets developers use a safe, high-level language while still producing compact, deterministic, and performant binaries suitable for embedded applications.

Key Features of Swift

Embedded Swift retains many of the powerful language features that make Swift an attractive alternative to C/C++ in embedded development:

Type Safety: Swift uses a strong static type system, which prevents many programming errors at compile time. Unlike C, where type mismatches can result in undefined behavior, Swift ensures all types are used correctly before code even runs.

Strict Type Checking: Swift doesn't allow implicit type conversions that could lose data or cause unexpected behavior. For example:

// This won't compile in Swift
let integer: Int = 42
let decimal: Double = 3.14
let result = integer + decimal  // Error: Cannot convert value of type 'Int' to expected argument type 'Double'

// You must be explicit about conversions
let result = Double(integer) + decimal  // Correct

Non-nullable Types by Default: In C, pointers can be null by default, which introduces risk. In Swift, variables cannot be nil unless explicitly marked as optionals:

var name: String = "John"
name = nil  // Compile error - String cannot be nil

var optionalName: String? = "John"
optionalName = nil  // This is allowed

Memory Safety via ARC (Covered in detail later):

Swift manages memory automatically using Automatic Reference Counting (ARC). Unlike manual memory management in C/C++, ARC handles object lifecycles efficiently without unpredictable garbage collection pauses. We'll cover ARC and its impact in embedded contexts in a dedicated section later.

Modern Syntax:
Swift's syntax is clean, consistent, and designed for readability. It supports modern paradigms including:

• Functional programming (map, filter, reduce)

• Generics (type-safe abstractions)

• Protocol-Oriented Programming (discussed in the next section)

These features allow you to write more expressive and maintainable code compared to procedural C or inheritance-heavy C++.

Performance:
Swift is designed to perform on par with C++ in many scenarios. Optimizations such as inlining, dead code elimination, and static dispatch help ensure that high-level abstractions don’t compromise performance. In embedded mode, Swift disables features like runtime reflection and dynamic dispatch to further reduce overhead.

To fully leverage Swift for embedded development, it's important to understand its programming model. Unlike C’s procedural approach or C++’s class-heavy design, Swift promotes protocol-oriented programming and composition, which offers both flexibility and safety in embedded system design.

Swift Programming Model

Swift embraces a multi-paradigm programming model that blends object-oriented, functional, and protocol-oriented programming, all underpinned by strong type safety and memory safety.

For embedded developers coming from C or C++, this model may feel different at first. But it provides a more modular and testable way to build complex systems, something especially valuable in embedded applications where hardware abstraction and strict reliability are critical.

Protocol-Oriented Programming (POP)

Swift emphasizes protocols over inheritance, encouraging developers to define behaviors through protocols and implement them using value types like struct and enum, rather than relying heavily on classes.

This philosophy favors composition over inheritance, allowing you to build complex functionality by combining smaller, well-defined components.

Key Concepts:

• protocol defines required behavior.

• Protocol extensions provide default behavior.

• Prefer value semantics using struct.

Example:

protocol Speakable {
    func speak()
}

extension Speakable {
    func speak() {
        print("Default sound")
    }
}

struct Dog: Speakable {
    func speak() {
        print("Woof!")
    }
}

Embedded Swift uses protocols with static dispatch. With static dispatch, the compiler knows the exact memory address of the function to call and can generate a direct jump instruction. There's no runtime lookup, no indirection, and no uncertainty.

Why POP Matters for Embedded Systems

First, you get flexible hardware extraction. Protocols make it easy to define interfaces for hardware components, allowing for mock implementations during testing or platform-specific variations.

Second, you have nice low overhead. Embedded Swift uses static dispatch for protocols, meaning there’s no runtime lookup, and calls are resolved at compile time for maximum performance.

Also, struct and enum types avoid heap allocations, making code more efficient and predictable in low-memory environments.

Now that we’ve explored how Swift’s programming model enables safer and more modular embedded code, let’s turn to another critical piece of the puzzle: memory management. Swift’s use of Automatic Reference Counting (ARC) replaces manual memory handling and offers important benefits, and tradeoffs, for embedded systems.

Swift Memory Management

One of Swift’s most impactful features, especially in the context of embedded systems, is its use of Automatic Reference Counting (ARC) for memory management. Unlike C/C++, where memory must be manually allocated and freed using malloc and free, Swift automates this process while maintaining deterministic performance.

This automation significantly reduces the risk of common memory-related bugs like leaks, dangling pointers, or use-after-free errors, all of which are notorious in low-level C code.

How ARC works

Swift supports ARC not only for the Cocoa Touch API's but for all APIs, providing a streamlined approach to memory management. Unlike garbage collection systems that can cause unpredictable pauses, ARC works deterministically at compile time and runtime to manage memory.

ARC automatically tracks and manages the lifetime of objects in memory based on how many references point to them.

• Reference Counting: Every object has a counter that tracks how many strong references point to it.

• Retain / Release: The compiler inserts retain and release calls automatically during assignment and deinitialization.

• Immediate Deallocation: When the reference count reaches zero, the object is deallocated immediately.

• Deterministic: Unlike garbage collectors, ARC doesn’t introduce unpredictable pauses or runtime scanning.

Swift offers multiple reference types to give you precise control over memory behavior and prevent cycles:

Strong References (default)

• Keeps the referenced object alive.

• Used in most cases.

class MotorController {
    var sensor: SensorData?  // Strong reference

    func updateReading(newData: SensorData) {
        self.sensor = newData  // Previous sensor data automatically deallocated
    }
}

Weak References

• Used to break reference cycles (especially in two-way object relationships).

• Automatically becomes nil when the referenced object is deallocated.

class Device {
    var controller: MotorController?

    deinit {
        print("Device deallocated")
    }
}

class MotorController {
    weak var device: Device?  // ← Weak reference breaks the cycle

    deinit {
        print("MotorController deallocated")
    }
}

func breakCycle() {
    let device = Device()
    let controller = MotorController()

    device.controller = controller
    controller.device = device  // ← This is now a weak reference

    // When this function ends, both objects are properly deallocated
}

breakCycle()
// Output:
// Device deallocated
// MotorController deallocated

Unowned References

• Non-optional version of weak.

• Assumes the object will never be deallocated while still in use.

• More lightweight than weak, but unsafe if misused.

class SensorSystem {
    unowned let controller: MotorController  // unowned reference

    init(controller: MotorController) {
        self.controller = controller
    }
}

class MotorController {
    var sensorSystem: SensorSystem?

    func setupSensors() {
        sensorSystem = SensorSystem(controller: self)
    }

    deinit {
        print("MotorController deallocated")
    }
}

func testUnowned() {
    let controller = MotorController()
    controller.setupSensors()
    // sensorSystem deallocates before controller ends
}

testUnowned()
// Output: MotorController deallocated

ARC Overhead in Embedded Systems

While ARC provides safety benefits, it does introduce some overhead compared to manual memory management:

Memory Overhead:

ARC-managed class instances in Swift typically include an additional 4 or 8 bytes to store reference count metadata, depending on the system architecture, 4 bytes on 32-bit systems and 8 bytes on 64-bit systems. This metadata allows the runtime to track how many active references exist to a given object and deallocate it when no references remain. When developers use weak or unowned references, the memory footprint increases further. These references require additional data structures, such as side tables or tracking mechanisms, to manage object liveness and cleanup. In the case of weak references specifically, Swift maintains zeroing weak reference tables that automatically null out pointers once the referenced object is deallocated, ensuring memory safety.

CPU Overhead:

ARC introduces some runtime overhead due to retain and release operations, which are inserted automatically during reference assignments. These operations involve incrementing or decrementing the reference count and are especially common in code that passes objects between functions or stores them in collections. To ensure thread safety, these updates are typically implemented using atomic operations, which add further instruction cycles. In complex object graphs, ARC may also engage in cycle detection and cleanup through the use of weak references to prevent memory leaks caused by strong reference cycles. While Swift's ARC provides deterministic and efficient memory management, it does so with both memory and CPU costs that developers should consider carefully, especially in performance-critical embedded systems.

Type Safety and Error Prevention

Swift's type system prevents many common errors that plague C/C++ programs:

• Buffer Overflows: Swift arrays are bounds-checked, preventing buffer overflow vulnerabilities that are common in C.

• Null Pointer Dereferences: Swift's optional types make null pointer dereferences impossible at compile time.

• Use After Free: Swift's ownership model prevents use-after-free errors that can cause crashes or security vulnerabilities.

Now that we’ve covered Swift's memory model and ARC behavior, let’s explore how it compares to C in terms of memory usage and instruction cycles, a crucial aspect when evaluating Embedded Swift for real-world deployment.

Memory and Instruction Cycle Comparison

Understanding the performance characteristics of Swift versus C is essential for embedded systems, where every instruction cycle and byte of memory matters. While Swift brings advantages like safety and expressiveness, these benefits come with certain trade-offs in terms of memory usage and runtime behavior that embedded developers must evaluate carefully.

Memory Management:

Swift uses Automatic Reference Counting (ARC) to manage memory. ARC tracks the number of references to each object and deallocates it when no references remain. This eliminates the need for explicit free() calls but introduces overhead.

C, in contrast, uses manual memory management. Developers allocate memory using malloc and release it using free, or rely on the stack for most short-lived data.

The table below provides the memory management comparison between Swift and C:

Swift ensures safety through deterministic cleanup and predictable memory usage. But this comes at the cost of added memory and CPU overhead.

C’s approach offers complete control over memory layout and minimal runtime cost, but increases the risk of memory leaks and fragmentation without disciplined practices.

Instruction Cycle Analysis

The safety features in Swift, such as bounds checking, optional unwrapping, and ARC updates, translate into additional CPU instructions. While this can impact performance, the Swift compiler is aggressive about optimization in release builds. For example, inlining and ARC elision can remove much of the overhead in performance-critical paths.

C has no built-in safety checks, allowing it to generate highly efficient, predictable code. Developers can even use inline assembly for tight control over performance.

The table below provides the instruction cycle comparison between Swift and C:

Although Swift inserts extra instructions for safety, much of this cost can be mitigated through compiler optimization.

C has no such features by default, making it ideal for applications where performance must be tightly controlled and the developer is willing to take full responsibility for safety.

Instruction Count Comparison: Swift vs C Loop Performance

When evaluating Swift and C for embedded use, it's helpful to analyze instruction-level performance on basic operations, such as a loop that processes an array of floating-point numbers. This gives us a concrete sense of the computational cost of each language's safety and abstraction features.

Let’s consider a simple example: summing an array of Float values and returning the average. In Swift, the code uses a high-level for-in loop over an array:

Simple loop performance:

// Swift loop with safety checks
func processData(_ data: [Float]) -> Float {
    var sum: Float = 0.0
    for value in data {  // Iterator with bounds checking
        sum += value     // Safe arithmetic
    }
    return sum / Float(data.count)  // Safe division
}
// Estimated: ~8-10 instructions per iteration

Although elegant and safe, this loop includes several safety mechanisms:

1. Bounds checking on every array access

2. Reference counting if data is passed as a reference type

3. Overflow protection in debug mode

4. Optional handling or runtime checks if data might be empty

These checks introduce runtime overhead, resulting in an estimated 8–10 instructions per iteration on most platforms (depending on optimization level and target architecture). In release builds, Swift aggressively inlines and strips redundant checks, but some level of abstraction cost remains, especially compared to raw memory access in C.

Now, compare that to its equivalent in C:

// C loop without safety checks
float process_data(float* data, int count) {
    float sum = 0.0f;
    for (int i = 0; i < count; i++) {  // Direct pointer arithmetic
        sum += data[i];                // Direct memory access
    }
    return sum / count;  // Direct division (no safety check)
}
// Estimated: ~4-5 instructions per iteration

This version performs direct memory access with pointer arithmetic, no bounds checks, and no type safety. The C code is lower-level, with fewer runtime checks, and compiles down to just 4–5 instructions per iteration, depending on the target CPU and compiler flags. It is lean and fast, ideal for cycles-per-instruction-critical scenarios.

The table below shows the comparison of single loop performance between Swift and C:

Now that we’ve compared Swift and C in terms of memory and cycle costs, let’s move into the practical side: how to set up Embedded Swift on an STM32 platform and get started with real-world development.

How to Setup Embedded Swift

In this section, we'll walk through how to configure and use Embedded Swift for development on STM32 microcontrollers. STM32 is a popular family of ARM Cortex-M–based microcontrollers, commonly used in industrial, consumer, and IoT applications.

Prerequisites

Required Software:

• Swift Development Snapshot (includes the Embedded Swift toolchain)

• Swiftly - Easiest way to manage and install swift toolchains

• Swiftc - Swift Compiler command-line tool

• Python3 - Required to run scripts to convert Mach-O to binary files

• Git (to clone sample repositories) like https://github.com/swiftlang/swift-embedded-examples

• A Unix-like development environment (macOS is currently best supported)

Target Hardware: This guide focuses on STM32 microcontrollers, which are widely used in embedded applications and have excellent community support.

This guide walks you through the full setup process, from installing the required Swift toolchain to flashing the final binary onto your board. We’ll begin by installing the Swift Development Snapshot using Swiftly, a simple command-line utility for managing Swift toolchains. From there, we’ll configure the build system, set up the correct board variant, customize the build script, and compile the Swift and C source code into a binary. Finally, we’ll flash the firmware onto the STM32 using standard tools

Install Swift Development Snapshot

The easiest way to install and manage Embedded Swift toolchains is by using the swiftly tool, which simplifies downloading and using Swift snapshots.

macOS Installation:

The below steps will help install the Swift embedded toolchain:

# Using Swiftly (Recommended)
curl -O https://download.swift.org/swiftly/darwin/swiftly.pkg
installer -pkg swiftly.pkg -target CurrentUserHomeDirectory
~/.swiftly/bin/swiftly init --quiet-shell-followup
source "${SWIFTLY_HOME_DIR:-$HOME/.swiftly}/env.sh"

# Install and use development snapshot
swiftly install main-snapshot
swiftly use main-snapshot

# Verify installation
swift --version

You can clone this Github example repository:

git clone https://github.com/swiftlang/swift-embedded-examples.git 
cd swift-embedded-examples/projects/stm32-blink

The stm32-blink contains:

• Swift code that toggles GPIOs

• A C startup file with vector table

• A build.sh script that uses swiftc, clang, and a custom linker setup

Setup the STM32 Board

Tell the build script which STM32 board is being used:

export STM_BOARD=STM32F746G_DISCOVERY

You can add your own board variant by defining the appropriate memory map and compiler flags in the script.

Modify build.sh (Optional)

Ensure the script correctly locates the following:

• swiftc: should point to the toolchain you installed with Swiftly

• clang: can be macOS’s default Clang

• libBuiltin.a, crt0.s, and macho2bin.py: used to provide minimal runtime support and convert output to flashable binaries

If needed, update these paths:

SWIFT_EXEC=${SWIFT_EXEC:-$(swiftly which swiftc)}
CLANG_EXEC=${CLANG_EXEC:-$(xcrun -f clang)}
PYTHON_EXEC=${PYTHON_EXEC:-$(which python3)}

Ensure the linker flags match your target’s flash and RAM sizes.

Build and Flash the Project:

Run:

./build.sh

This compiles Swift and C code, links them, and produces a blink.bin file.

If successful, you’ll see:

.build/blink.bin  # ready to flash Step 6: Flash the Firmware to STM32

Use ST-Link tools or openocd to flash your board. Example using st-flash:

brew install stlink
st-flash write .build/blink.bin 0x8000000

You should now see an LED blinking.

Here’s a more detailed step by step approach to writing a bare metal code on STM32. For comprehensive installation guides covering other platforms (Raspberry Pi Pico, ESP32, nRF52), detailed IDE configuration, troubleshooting, and advanced examples, you can check out the official documentation:

• Complete Setup Guide: Install Embedded Swift

• Platform Examples: Swift Embedded Examples Repository

• Getting Started Tutorial: Embedded Swift on Microcontrollers

Now that we’ve set up Embedded Swift and explored how to build and run an example project, let’s look at a critical real-world scenario: interfacing Swift with low-level C drivers.

C-Swift Linkages

In many embedded projects, low-level hardware drivers are written in C because of its close-to-metal control and widespread ecosystem support. Embedded Swift supports seamless interoperability with C, which lets you reuse existing C libraries and drivers, write hardware control logic in C, and implement higher-level application logic in Swift.

This hybrid model lets you combine Swift’s safety and productivity with C’s hardware-level control, with no runtime overhead or object translation.

Let’s walk through an example where a low-level sensor driver is implemented in C and the application logic is written in Swift.

C Header File (sensor_driver.h):

This C header file defines the public interface for a low-level sensor driver. It includes standard fixed-width integer types and declares four functions:

• sensor_init(): Initializes the hardware sensor

• sensor_read_temperature() and sensor_read_humidity(): Read raw sensor values

• sensor_delay_ms(): Delays execution for a given number of milliseconds

This interface acts as a bridge between Swift and C. Swift will link to these functions by name, no wrappers or bindings required.

#ifndef SENSOR_DRIVER_H
#define SENSOR_DRIVER_H

#include <stdint.h>

// Low-level sensor driver functions
void sensor_init(void);
uint32_t sensor_read_temperature(void);
uint32_t sensor_read_humidity(void);
void sensor_delay_ms(uint32_t milliseconds);

#endif

C Implementation (sensor_driver.c):

This implementation assumes the sensor is memory-mapped at a fixed address (0x40001000). Each register, temperature, humidity, and control, is accessed by offset from that base address.

The sensor_init() function writes 0x01 to the control register, presumably enabling or starting the sensor hardware.

The sensor_read_temperature() method and sensor_read_humidity() method reads from memory-mapped registers and return the raw ADC values from the sensor.

The sensor_delay_ms() method performs a simple busy-wait loop using nop (no-operation) instructions to approximate a delay. This is suitable for short, coarse-grained delays in bare-metal contexts.

#include "sensor_driver.h"

// Hardware register addresses
#define SENSOR_BASE_ADDR    0x40001000
#define TEMP_REG_OFFSET     0x00
#define HUMIDITY_REG_OFFSET 0x04
#define CONTROL_REG_OFFSET  0x08

void sensor_init(void) {
    // Initialize sensor hardware
    volatile uint32_t* control_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + CONTROL_REG_OFFSET);
    *control_reg = 0x01; // Enable sensor
}

uint32_t sensor_read_temperature(void) {
    volatile uint32_t* temp_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + TEMP_REG_OFFSET);
    return *temp_reg;
}

uint32_t sensor_read_humidity(void) {
    volatile uint32_t* humidity_reg = (volatile uint32_t*)(SENSOR_BASE_ADDR + HUMIDITY_REG_OFFSET);
    return *humidity_reg;
}

void sensor_delay_ms(uint32_t milliseconds) {
    // Simple delay implementation
    for (uint32_t i = 0; i < milliseconds * 1000; i++) {
        __asm__("nop");
    }
}

Swift Code Using C Driver:

To use these C functions from Swift, you declare them using @_silgen_name, which tells the Swift compiler to link directly to these symbol names at runtime.

The SensorController class encapsulates sensor-related logic. In its init() method, it calls the sensor_init() function defined in C to initialize the sensor hardware.

The readSensors() method reads the raw values from the C driver, converts them into human-readable units using helper functions, stores them internally, and returns the processed values.

The convertTemperature() and convertHumidity() conversion methods apply a basic linear formula to turn raw ADC values into temperature in Celsius and humidity in percentage, respectively. These formulas would be based on the specific sensor’s datasheet.

The checkThresholds() method applies simple threshold logic, a good example of where Swift’s readability and type safety shine. You could easily expand this logic to include error bounds, state machines, or alerts.

// Import C driver functions

/*
These declarations match the C function signatures exactly. 
They allow Swift to invoke the C functions as if they were native Swift functions 
— with zero overhead.
*/
@_silgen_name("sensor_init")
func sensor_init()

@_silgen_name("sensor_read_temperature")
func sensor_read_temperature() -> UInt32

@_silgen_name("sensor_read_humidity")
func sensor_read_humidity() -> UInt32

@_silgen_name("sensor_delay_ms")
func sensor_delay_ms(_ ms: UInt32)

// Swift sensor controller using C driver
class SensorController {
    private var lastTemperature: Float = 0.0
    private var lastHumidity: Float = 0.0

    init() {
        // Initialize the C driver
        sensor_init()
    }

    func readSensors() -> (temperature: Float, humidity: Float) {
        // Read raw values from C driver
        let rawTemp = sensor_read_temperature()
        let rawHumidity = sensor_read_humidity()

        // Convert raw values to meaningful units in Swift
        let temperature = convertTemperature(rawValue: rawTemp)
        let humidity = convertHumidity(rawValue: rawHumidity)

        // Store for comparison
        lastTemperature = temperature
        lastHumidity = humidity

        return (temperature: temperature, humidity: humidity)
    }

    private func convertTemperature(rawValue: UInt32) -> Float {
        // Convert raw ADC value to Celsius
        return (Float(rawValue) * 3.3 / 4095.0 - 0.5) * 100.0
    }

    private func convertHumidity(rawValue: UInt32) -> Float {
        // Convert raw ADC value to percentage
        return Float(rawValue) * 100.0 / 4095.0
    }

    func checkThresholds() -> Bool {
        // Swift logic for threshold checking
        let tempThreshold: Float = 25.0
        let humidityThreshold: Float = 60.0

        return lastTemperature > tempThreshold || lastHumidity > humidityThreshold
    }
}

// Main application loop
func main() -> Never {
    let sensorController = SensorController()

    while true {
        // Read sensors using Swift controller with C driver
        let readings = sensorController.readSensors()

        // Process data with Swift's type safety and expressiveness
        if sensorController.checkThresholds() {
            print("Warning: Temperature: \(readings.temperature)°C, Humidity: \(readings.humidity)%")
        } else {
            print("Normal: Temperature: \(readings.temperature)°C, Humidity: \(readings.humidity)%")
        }

        // Delay using C driver function
        sensor_delay_ms(1000) // 1 second delay
    }
}

The func main() is the main event loop standard for embedded systems. It creates the sensor controller, reads sensor data in a loop, checks thresholds, and prints results accordingly. The loop includes a delay (via the C driver) to avoid hammering the sensor continuously.

In an actual embedded context, instead of using print(), you might blink an LED, send UART messages, or log data to memory.

With Embedded Swift and C now working together, let’s explore what lies ahead. The next section outlines ongoing improvements, emerging use cases, and research directions that are shaping the future of Embedded Swift.

Future Work

Embedded Swift is still a young but rapidly evolving technology. Its modern language features, type safety, and performance make it an attractive option for embedded development, and ongoing work is expanding its capabilities, reach, and ecosystem.

Ongoing Improvements

Compiler Optimizations: The Swift compiler team is actively improving code generation for embedded targets, including:

• Reducing binary size

• Minimizing ARC overhead

• Improving static dispatch performance

Hardware Support: Embedded Swift can target a wide variety of ARM and RISC-V microcontrollers, which are popular for building industrial applications. Support for additional architectures is being developed.

Tooling Enhancements: Tooling support for Embedded Swift is still evolving, but several community-driven and open-source efforts are making development more accessible:

• Build Systems: The Swift Embedded Working Group provides example projects that adapt Swift Package Manager (SwiftPM) for cross-compilation. Custom linker scripts and build helpers are available for platforms like STM32 and nRF52.

• Debugging Support: Developers can debug Embedded Swift programs using existing tools like GDB or OpenOCD, provided the build includes appropriate debug symbols. While not yet officially streamlined, this approach enables step-through debugging on real hardware.

• IDE Integration: There is no official IDE support yet, but some developers use VSCode with Swift syntax highlighting and external build tasks. These setups are still manual but serve as early prototypes for embedded workflows.

Emerging Use Cases

There are a number of emerging use cases for embedded Swift. For example, Swift’s memory safety, type guarantees, and protocol-oriented design make it ideal for secure and scalable IoT devices, especially where firmware bugs could affect user safety or privacy.

The automotive sector is also exploring Swift for infotainment systems, driver assistance features, and safety-critical logic (where deterministic execution and safety matter).

Swift’s expressive syntax and compile-time safety make it suitable for industrial automation – think real-time control loops, sensor fusion systems, and edge devices in smart manufacturing.

It’s also useful for medical devices, as it aligns well with strict medical regulations around memory safety, type guarantees, and predictable resource usage.

Community and Ecosystem

Open Source Projects

The Swift Embedded working group maintains example repositories showcasing how to use Embedded Swift on microcontrollers such as STM32, nRF52, and ESP32. Early-stage libraries for UART, GPIO, and basic peripherals are emerging, though the ecosystem is still young compared to C or Rust.

Learning Resources

While Embedded Swift is not yet widely taught in formal curricula, community tutorials and exploratory projects (for example, Swift for Arduino) are lowering the barrier for hobbyists and independent learners. As tooling matures, educational adoption is likely to follow.

Industry Interest

Embedded Swift is beginning to draw attention from developers and companies looking for safer, more maintainable alternatives to C. Although large-scale adoption remains limited, use cases like rapid prototyping, IoT development, and internal experimentation are gaining traction.

Conclusion

Embedded Swift represents a major step forward in embedded programming. By combining the power and safety of Swift with the low-level control needed for microcontrollers, it offers an exciting alternative to traditional C and C++ development.

While C will remain essential for hardware-level programming and performance-critical paths, Swift brings compelling advantages to many embedded scenarios:

• Memory safety: Swift eliminates entire categories of bugs such as buffer overflows, use-after-free, and null pointer dereferencing.

• Type safety: Many logic errors are caught at compile time, long before they can cause runtime failures.

• Modern language features: Developers can use functional paradigms, generics, and protocol-oriented design even in embedded code.

• C interoperability: Swift works seamlessly with existing C libraries, allowing gradual adoption without rewriting low-level drivers.

• Developer productivity: Clear syntax, automatic memory management, and strong tooling lead to faster development and easier maintenance.

Government and regulatory bodies are increasingly encouraging or mandating the use of memory-safe programming languages to reduce vulnerabilities in critical software systems. For example:

• In 2022, the U.S. National Security Agency (NSA) recommended moving away from unsafe languages like C/C++ for new software projects, promoting memory-safe alternatives.

• In June 2025, the NSA and CISA released a joint Cybersecurity Information Sheet titled “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development”, which emphasized that memory safety flaws remain a persistent risk, and organizations should develop strategies to adopt memory-safe programming languages in new systems.

• The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and NIST have echoed similar guidance in the context of national cybersecurity.

While these documents do not mention Swift explicitly, Swift's strong type system, ARC-based memory model, and compile-time safety guarantees align closely with the goals outlined in these recommendations. As such, it offers a practical, developer-friendly path toward safer embedded development.

Swift may not be the right fit for every embedded system. In applications where every byte of memory or instruction cycle is critical, real-time guarantees are hard requirements, or toolchain maturity is essential (for example, RTOS integration, static analyzers), C or Rust may still be preferred.

But in many modern embedded applications, especially those involving rapid prototyping, fast product iteration, safety-critical or maintainable firmware, and interoperability with existing C codebases, Swift offers a highly productive and safe development experience.

Embedded Swift is still maturing, but its momentum is undeniable. With ongoing compiler work, community-driven examples, and growing interest from developers, it’s poised to play a major role in the future of embedded systems.

Whether you're building an IoT device, a piece of industrial equipment, or a proof-of-concept wearable, Swift can help you write safer, more expressive firmware, without giving up performance or control.

Swift can be especially powerful during the prototyping phase, when the primary goal is to validate functionality quickly and safely. And with its increasing support for multiple hardware platforms, it offers a strong foundation for bringing modern software development practices to the embedded world.

A buffer overflow happens when a program writes more data into a buffer than it was allocated, leading to memory corruption, crashes, or even security vulnerabilities. A buffer corruption occurs when unintended modifications overwrite unread data or modify memory in unexpected ways.

In safety-critical systems like cars, medical devices, and spacecraft, buffer overflows can cause life-threatening failures. Unlike simple software bugs, buffer overflows are unpredictable and depend on the state of the system, making them difficult to diagnose and debug.

To prevent these issues, it's important to understand how buffer overflows and corruptions occur, and how to detect and fix them.

Article Scope

In this article, you will learn:

1. What buffers, buffer overflows, and corruptions are. I’ll give you a beginner-friendly explanation with real-world examples.

2. How to debug buffer overflows. You’ll learn how to use tools like GDB, LLDB, and memory maps to find memory corruption.

3. How to prevent buffer overflows. We’ll cover some best practices like input validation, safe memory handling, and defensive programming.

I’ll also show you some hands-on code examples – simple C programs that demonstrate buffer overflow issues and how to fix them.

What this article doesn’t cover:

1. Security exploits and hacking techniques. We’ll focus on preventing accidental overflows, not hacking-related buffer overflows.

2. Operating system-specific issues. This guide is for embedded systems, not general-purpose computers or servers.

3. Advanced RTOS memory management. While we discuss interrupt-driven overflows, we won’t dive deep into real-time operating system (RTOS) concepts.

Now that you know what this article covers (and what it doesn’t), let’s go over the skills that will help you get the most out of it.

Prerequisites

This article is designed for developers who have some experience with C programming and want to understand how to debug and prevent buffer overflows in embedded systems. Still, beginners can follow along, as I’ll explain key concepts in a clear and structured way.

Before reading, it helps if you know:

1. Basic C programming.

2. How memory works – the difference between stack, heap, and global variables.

3. Basic debugging concepts – if you’ve used a debugger like GDB or LLDB, that’s a plus, but not required.

4. What embedded systems are – a basic idea of how microcontrollers store and manage memory.

Even if you’re not familiar with these topics, this guide will walk you through them in an easy-to-understand way.

Before you dive into buffer overflows, debugging, and prevention, let’s take a step back and understand what a buffer is and why it’s important in embedded systems. Buffers play a crucial role in managing data flow between hardware and software but when handled incorrectly, they can lead to serious software failures.

Table of Contents

• What is a Buffer, and How Does it Work?

• What is a Buffer Overflow?

• Common Causes of Buffer Overflows and Corruption

• Consequences of Buffer Overflows

• How to Debug Buffer Overflows

• How to Prevent Buffer Overflows

• Conclusion

What is a Buffer, and How Does it Work?

A buffer is a contiguous block of memory used to temporarily store data before it is processed. Buffers are commonly used in two scenarios:

1. Data accumulation: When the system needs to collect a certain amount of data before processing.

2. Rate matching: When the data producer generates data faster than the data consumer can process it.

Buffers are typically implemented as arrays in C, where elements are indexed from 0 to N-1 (where N is the buffer size).

Let’s look at an example of a buffer in a sensor system.

Consider a system with a sensor task that generates data at 400 Hz (400 samples per second or 1 sample every 2.5 ms). But the data processor (consumer) operates at only 100 Hz (100 samples per second or 1 sample every 10 ms). Since the consumer task is slower than the producer, we need a buffer to store incoming data until it is processed.

To determine the buffer size, we calculate:

Buffer Size = Time to consume 1 sample / Time to generate 1 sample = 10 ms/ 2.5 ms = 4

This means the buffer must hold at least 4 samples at a time to avoid data loss.

Once the buffer reaches capacity, there are several strategies to decide which data gets passed to the consumer task:

1. Max/min sampling: Use the maximum or minimum value in the buffer.

2. Averaging: Compute the average of all values in the buffer.

3. Random access: Pick a sample from a specific location (for example, the most recent or the first).

In real-world applications, it’s beneficial to use circular buffers or double buffering to prevent data corruption.

• Circular buffer approach: A circular buffer (also called a ring buffer) continuously wraps around when it reaches the end, ensuring old data is overwritten safely without exceeding memory boundaries. The buffer size should be multiplied by 2 (4 × 2 = 8) to hold 8 samples. This allows the consumer task to process 4 samples while the next 4 samples are being filled, preventing data overwrites.

• Double buffer approach: Double buffering is useful when data loss is unacceptable. It allows continuous data capture while the processor is busy handling previous data. A second buffer of the same size is added. When the first buffer is full, the write pointer switches to the second buffer, allowing the consumer task to process data from the first buffer while the second buffer is being filled. This prevents data overwrites and ensures a continuous data flow.

Buffers help manage data efficiently, but what happens when they are mismanaged? This is where buffer overflows and corruptions come into play.

What is a Buffer Overflow?

A buffer overflow occurs when a program writes more data into a buffer than it was allocated, causing unintended memory corruption. This can lead to unpredictable behavior, ranging from minor bugs to critical system failures.

To understand buffer overflow, let's use a simple analogy. Imagine a jug with a tap near the bottom. The jug represents a buffer, while the tap controls how much liquid (data) is consumed.

The jug is designed to hold a fixed amount of liquid. As long as water flows into the jug at the same rate or slower than it flows out, everything works fine. But if water flows in faster than it flows out, the jug will eventually overflow.

Similarly, in software, if data enters a buffer faster than it is processed, it exceeds the allocated memory space, causing a buffer overflow. In the case of a circular buffer, this can cause the write pointer to wrap around and overwrite unread data, leading to buffer corruption.

Buffer Overflows in Software

Unlike the jug, where water simply spills over, a buffer overflow in software overwrites adjacent memory locations. This can cause a variety of hard-to-diagnose issues, including:

1. Corrupting other data stored nearby.

2. Altering program execution, leading to crashes.

3. Security vulnerabilities, where attackers exploit overflows to inject malicious code.

When a buffer overflow occurs, data can overwrite variables, function pointers, or even return addresses, depending on where the buffer is allocated.

Buffer overflows can occur in different memory regions:

1. Buffer overflows in global/static memory (.bss / .data sections)

   • These occur when global or static variables exceed their allocated size.

   • The overflow can corrupt adjacent variables, leading to unexpected behavior in other modules.

   • Debugging is easier because memory addresses are fixed at compile time unless the compiler optimizes them. Map files provide a memory layout of variables during the compilation and linking.

2. Stack-based buffer overflow (more predictable, easier to debug):

   • Happens when a buffer is allocated in the stack (for example, local variables inside functions).

   • Overflowing the stack can affect adjacent local variables or return addresses, potentially crashing the program.

   • In embedded systems with small stack sizes, this often leads to a crash or execution of unintended code.

3. Heap-based buffer overflow (harder to debug):

   • Happens when a buffer is dynamically allocated in the heap (for example, using malloc() in C).

   • Overflowing a heap buffer can corrupt adjacent dynamically allocated objects or heap management structures.

   • Debugging is harder because heap memory is allocated dynamically at runtime, causing memory locations to vary.

Buffer Overflow vs Buffer Corruption

Buffer overflow and buffer corruption are of course related, but refer to different situations.

A buffer overflow happens when data is written beyond the allocated buffer size, leading to memory corruption, unpredictable behavior, or system crashes.

A buffer corruption happens when unintended data modifications result in unexpected software failures, even if the write remains within buffer boundaries.

Both issues typically result from poor write pointer management, lack of boundary checks, and unexpected system behavior.

Now that we've covered what a buffer overflow is and how it can overwrite memory, let’s take a closer look at how these issues affect embedded systems.

In the next section, we’ll explore how buffer overflows and corruption happen in real-world embedded systems and break down common causes, including pointer mismanagement and boundary violations.

Common Causes of Buffer Overflows and Corruption

Embedded systems use buffers to store data from sensors, communication interfaces (like UART (Universal Asynchronous Receiver-Transmitter), SPI (Serial Peripheral Interface), I2C (Inter-integrated Circuit), and real-time tasks. These buffers are often statically allocated to avoid memory fragmentation, and many implementations use circular (ring) buffers to efficiently handle continuous data streams.

Here are three common scenarios where buffer overflows or corruptions occur in embedded systems:

Writing Data Larger Than the Available Space

Issue: The software writes incoming data to the buffer without checking if there is enough space.

Example: Imagine a 100-byte buffer to store sensor data. The buffer receives variable-sized packets. If an incoming packet is larger than the remaining space, it will overwrite adjacent memory, leading to corruption.

So why does this happen?

• Some embedded designs increment the write pointer after copying data, making it too late to prevent overflow.

• Many low-level memory functions (memcpy, strcpy, etc.) do not check buffer boundaries, leading to unintended writes.

• Without proper bound checking, a large write can exceed the buffer size and corrupt nearby memory.

Here’s a code sample to demonstrate buffer overflow in a .bss / .data section:

  #include <stdint.h>
  #include <stdio.h>
  #include <string.h>

  #define BUFFER_SIZE 300

  static uint16_t sample_count = 0;
  static uint8_t buffer[BUFFER_SIZE] = {0};

  // Function to simulate a buffer overflow scenario
  void updateBufferWithData(uint8_t *data, uint16_t size)
  {
      // Simulating a buffer overflow: No boundary check!
      printf("Attempting to write %d bytes at position %d...\n", size, sample_count);

      // Deliberate buffer overflow for demonstration
      if (sample_count + size > BUFFER_SIZE)
      {
          printf("WARNING: Buffer Overflow Occurred! Writing beyond allocated memory!\n");
      }

      // Copy data (unsafe, can cause overflow)
      memcpy(&buffer[sample_count], data, size);

      // Increment sample count (incorrectly, leading to wraparound issues)
      sample_count += size;
  }

  int main()
  {   
      // Save 1 byte to buffer
      uint8_t data_to_buffer = 10;
      updateBufferWithData(&data_to_buffer, 1);

      // Save an array of 20 bytes to buffer
      uint8_t data_to_buffer_1[20] = {5};
      updateBufferWithData(data_to_buffer_1, sizeof(data_to_buffer_1));

      // Intentional buffer overflow: Save an array of 50 x 8 bytes (400 bytes)
      uint64_t data_to_buffer_2[50] = {7};
      updateBufferWithData((uint8_t*)data_to_buffer_2, sizeof(data_to_buffer_2));

      return 0;
  }

Interrupt-Driven Overflows (Real-time Systems)

Issue: The interrupt service routine (ISR) may write data faster than the main task can process, leading to buffer corruption or buffer overflow if the write pointer is not properly managed.

Example: Imagine a sensor ISR that writes incoming data into a buffer every time a new reading arrives. Meanwhile, a low-priority processing task reads and processes the data.

What can go wrong?

• If the ISR triggers too frequently (due to a misbehaving sensor or high interrupt priority), the buffer may fill up faster than the processing task can keep up.

• This can result in one of two failures:

  1. Buffer Corruption: The ISR overwrites unread data, leading to loss of information.

  2. Buffer Overflow: The ISR exceeds buffer boundaries, causing memory corruption or system crashes.

So why does this happen?

• In real-time embedded systems, ISR execution preempts lower-priority tasks.

• If the processing task doesn't not get enough CPU time, the buffer may become overwritten or overflow beyond its allocated scope.

System State Changes & Buffer Corruption

Issue: The system may unexpectedly reset, enter low-power mode, or changes operating state, leaving the buffer write pointers in an inconsistent state. This can result in buffer corruption (stale or incorrect data) or buffer overflow (writing past the buffer’s limits.

Example Scenarios:

1. Low-power wake-up issue (Buffer Overflow risk): Some embedded systems enter deep sleep to conserve energy. Upon waking up, if the buffer write pointer is not correctly reinitialized, it may point outside buffer boundaries, leading to buffer overflow and unintended memory corruption.

2. Unexpected mode transitions: If a sensor task is writing data and the system suddenly switches modes, the buffer states and pointers may not be cleaned up. The next time the sensor task runs, it may continue writing without clearing previous data. This can cause undefined behavior due to presence of stale data.

Now that you understand how buffer overflows and corruptions happen, let’s examine their consequences in embedded systems ranging from incorrect sensor readings to complete system failures, making debugging and prevention critical.

Consequences of Buffer Overflows

Buffer overflows can be catastrophic in embedded systems, leading to system crashes, data corruption, and unpredictable behavior. Unlike general-purpose computers, many embedded devices lack memory protection, making them particularly vulnerable to buffer overflows.

A buffer overflow can corrupt two critical types of memory:

1. Data Variables Corruption

A buffer overflow can overwrite data variables, corrupting the inputs for other software modules. This can cause unexpected behavior or even system crashes if critical parameters are modified.

For example, a buffer overflow could accidentally overwrite a sensor calibration value stored in memory. As a result, the system would start using incorrect sensor readings, leading to faulty operation and potentially unsafe conditions.

2. Function Pointer Corruption

In embedded systems, function pointers are often used for interrupt handlers, callback functions, and RTOS task scheduling. If a buffer overflow corrupts a function pointer, the system may execute unintended instructions, leading to a crash or unexpected behavior.

As an example, a function pointer controlling motor speed regulation could be overwritten. Instead of executing the correct function, the system would jump to a random memory address, causing a system fault or erratic motor behavior.

Buffer overflows are among the hardest bugs to identify and fix because their effects depend on which data is corrupted and the values it contains. A buffer overflow can affect memory in different ways:

• If a buffer overflow corrupts unused memory, the system may seem fine during testing, making the issue harder to detect.

• if a buffer overflow alters critical data variables, it can cause hidden logic errors that cause unpredictable behavior.

• If a buffer overflow corrupts function pointers, it may crash immediately, making the problem easier to identify.

During development, if tests focus only on detecting crashes, they may overlook silent memory corruption caused by a buffer overflow. In real-world deployments, new use cases not covered in testing can trigger previously undetected buffer overflow issues, leading to unpredictable failures.

Buffer overflows can cause a chain reaction, where one overflow leads to another overflow or buffer corruption, resulting in widespread system failures. So how does this happen?

1. A buffer overflow corrupts a critical variable (for example, a timer interval).

2. The corrupted variable disrupts another module (for example, triggers the timer interrupt too frequently, causing it to push more data into a buffer than intended.).

3. This increased interrupt frequency forces a sensor task to write data faster than intended, eventually causing another buffer overflow or corruption by overwriting unread data.

This chain reaction can spread across multiple software modules, making debugging nearly impossible. In real-word applications, buffer overflows in embedded systems can be life-threatening:

• In cars: A buffer overflow in an ECU (Electronic Control Unit) could cause brake failure or unintended acceleration.

• In a spacecraft: A memory corruption issue could disable navigation systems, leading to mission failure.

Now that we’ve seen how buffer overflows can corrupt memory, disrupt system behavior, and even cause critical failures, the next step is understanding how to detect and fix them before they lead to serious issues.

How to Debug Buffer Overflows

Debugging buffer overflows in embedded systems can be complex, as their effects range from immediate crashes to silent data corruption, making them difficult to trace. A buffer overflow can cause either:

1. A system crash, which is easier to detect since it halts execution or forces a system reboot.

2. Unexpected behavior, which is much harder to debug as it requires tracing how corrupted data affects different modules.

This section focuses on embedded system debugging techniques using memory map files, debuggers (GDB/LLDB), and a structured debugging approach. Let’s look into the debuggers and memory map files.

Memory Map File (.map file)

A memory map file is generated during the linking process. It provides a memory layout of global/static variables, function addresses, and heap/stack locations. It provides a memory layout of Flash and RAM, including:

• Text section (.text): Stores executable code.

• Read-only section (.rodata): Stores constants and string literals.

• BSS section (.bss): Stores uninitialized global and static variables.

• Data section (.data): Stores initialized global and static variables.

• Heap and stack locations, depending on the linker script.

If a buffer overflow corrupts a global variable, the .map file can identify nearby variables that may also be affected, provided the compiler has not optimized the memory allocation. Similarly, if a function pointer is corrupted, the .map file can reveal where it was stored in memory.

Debuggers (GDB & LLDB)

Debugging tools like GDB (GNU Debugger) and LLDB (LLVM Debugger) allow:

• Controlling execution (breakpoints, stepping through code).

• Inspecting variable values and memory addresses.

• Getting backtraces (viewing function calls before a crash).

• Extracting core dumps from microcontrollers for post-mortem analysis.

If the system halts on a crash, a backtrace (bt command in GDB) can reveal which function was executing before failure. If the overflow affects a heap-allocated variable, GDB can inspect heap memory usage to detect corruption.

The Debugging Process

Now, let’s go through a step-by-step debugging process to identify and fix buffer overflows. Once a crash or unexpected behavior occurs, follow these techniques to trace the root cause:

Step 1: Identify the misbehaving module

If the system crashes, use GDB or LLDB backtrace (bt command) to locate the last executed function. If the system behaves unexpectedly, determine which software module controls the affected functionality.

Step 2: Analyze inputs and outputs of the module

Every function or module has inputs and outputs. Create a truth table listing expected outputs for all possible inputs. Check if the unexpected behavior matches any undefined input combination, which may indicate corruption.

Step 3: Locate memory corruption using address analysis

If a variable shows incorrect values, determine its physical memory location. Depending on where the variable is stored:

1. Global/static variables (.bss / .data): Look up the memory map file for nearby buffers.

2. Heap variables: Snapshot heap allocations using GDB.

   Here’s an example of using GDB to find corrupted variables:

    (gdb) print &my_variable  # Get memory address of the variable
    $1 = (int *) 0x20001000
    (gdb) x/10x 0x20001000   # Examine memory near this address, Display 10 memory words in hexadecimal format starting from 0x20001000
   

Step 4: Identify the overflowing buffer

If a buffer is located just before the corrupted variable, inspect its usage in the code. Review all possible code paths that write to the buffer. Check if any design limitations could cause an overflow under a specific use cases.

Step 5: Fix the root cause

If the buffer overflow happened due to missing bounds checks, add proper input validation to prevent it. Buffer design should enforce strict memory limits. The module should implement strict boundary checks for all inputs and maintain a consistent state.

In addition to GDB/LLDB, you can also use techniques like hardware tracing and fault injection to simulate buffer overflows and observe system behavior in real-time.

While debugging helps identify and fix buffer overflows, prevention is always the best approach. Let’s explore techniques that can help avoid buffer overflows altogether.

How to Prevent Buffer Overflows

You can often prevent buffer overflows through good software design, defensive programming, hardware protections, and rigorous testing. Embedded systems, unlike general-purpose computers, often lack memory protection mechanisms, which means that buffer overflow prevention critical for system reliability and security.

Here are some key techniques to help prevent buffer overflows:

Defensive Programming

Defensive programming helps minimize buffer overflow risks by ensuring all inputs are validated and unexpected conditions are handled safely.

First, it’s crucial to validate input size before writing to a buffer. Always check the write index by adding the size of data to be written prior to writing data to make sure more data is not written than the available buffer space.

Then you’ll want to make sure you have proper error handling and fail-safe mechanisms in place. If an input is invalid, halt execution, log the error, or switch to a safe state. Also, functions should indicate success/failure with helpful error codes to prevent misuse.

Sample Code:

   #include <stdint.h>
   #include <string.h>
   #include <stdbool.h>
   #include <stdio.h>

   #define BUFFER_SIZE 300

   static uint16_t sample_count = 0;
   static uint8_t buffer[BUFFER_SIZE] = {0};

   typedef enum
   {
       SUCCESS = 0,
       NOT_ENOUGH_SPACE = 1,
       DATA_IS_INVALID = 2,
   } buffer_err_code_e;


   buffer_err_code_e updateBufferWithData(uint8_t *data, uint16_t size)
   {
       if (data == NULL || size == 0 || size > BUFFER_SIZE)  
       {
           return DATA_IS_INVALID; // Invalid input size
       }

       uint16_t available_space = BUFFER_SIZE - sample_count;
       bool can_write = (available_space >= size) ? true : false;

       if (!can_write)  
       {
           return NOT_ENOUGH_SPACE;
       }

       // Copy data safely
       memcpy(&buffer[sample_count], data, size);
       sample_count += size;

       return SUCCESS;
   }

   int main()
   {   
       buffer_err_code_e ret;

       // Save 1 byte to buffer
       uint8_t data_to_buffer = 10;
       ret = updateBufferWithData(&data_to_buffer, sizeof(data_to_buffer));
       if (ret)  
       {
           printf("Buffer update didn't succeed, Err:%d\n", ret);
       }

       // Save an array of 20 bytes to buffer
       uint8_t data_to_buffer_1[20] = {5};
       ret = updateBufferWithData(data_to_buffer_1, sizeof(data_to_buffer_1));
       if (ret)  
       {
           printf("Buffer update didn't succeed, Err:%d\n", ret);
       }

       // Save an array of 50 x 8 bytes, Intentional buffer overflow
       uint64_t data_to_buffer_2[50] = {7};
       ret = updateBufferWithData((uint8_t*)data_to_buffer_2, sizeof(data_to_buffer_2));  
       if (ret)  
       {
           printf("Buffer update didn't succeed, Err:%d\n", ret);
       }

       return 0;
   }

Choosing the Right Buffer Design And Size

Some buffer designs handle overflow better than others. Choosing the correct buffer type and size for the application reduces the risk of corruption.

• Circular Buffers (Ring Buffers) prevent out-of-bounds writes by wrapping around. They overwrite the oldest data instead of corrupting memory. These are useful for real-time streaming data (for example, UART, sensor readings). This approach is ideal for applications where data loss is unacceptable.

• Ping-Pong Buffers (Double Buffers) use two buffers. One buffer fills up with data. Then, once it’s full, it switches to the second buffer while the first one is processed. This approach is beneficial for application that have strict requirements on no data loss. The buffer design should be based on the speed of write and read tasks.

Hardware Protection

Memory Protection Unit (MPU)

An MPU (Memory Protection Unit) helps detect unauthorized memory accesses, including buffer overflows, by restricting which regions of memory can be written to. It prevents buffer overflows from modifying critical memory regions and triggers a MemManage Fault if a process attemps to write outside an allowed region.

But keep in mind that, an MPU does not prevent buffer overflows – it only detects and stops execution when they occur. Not all microcontrollers have an MPU, and some low-end MCUs lack hardware protection, making software-based safeguards even more critical.

Modern C compilers provide several flags to identify memory errors at compile-time:

1. -Wall -Wextra: Enables useful warnings

2. -Warray-bounds: Detects out-of-bounds array access when the array size is known at compile-time

3. -Wstringop-overflow: Warns about possible overflows in string functions like memcpy and strcpy.

Testing and Validation

Testing helps detect buffer overflows before deployment, reducing the risk of field failures. Unit testing each function independently with valid inputs, boundary cases, and invalid inputs helps detect buffer-related issues early. Automated testing involves feeding random and invalid inputs into the system to uncover crashes and unexpected behavior. Static Analysis Tools like Coverity, Clang Static Analyzer help detect buffer overflows before runtime. Run real-world inputs on embedded hardware to detect issues.

Now that we've explored how to identify, debug, and prevent buffer overflows, it’s clear that these vulnerabilities pose a significant threat to embedded systems. From silent data corruption to catastrophic system failures, the consequences can be severe.

But with the right debugging tools, systematic analysis, and preventive techniques, you can effectively either prevent or mitigate buffer overflows in your systems.

Conclusion

Buffer overflows and corruption are major challenges in embedded systems, leading to crashes, unpredictable behavior, and security risks. Debugging these issues is difficult because their symptoms vary based on system state, requiring systematic analysis using memory map files, GDB/LLDB, and structured debugging approaches.

In this article, we explored:

• The causes and consequences of buffer overflows and corruptions

• How to debug buffer overflows using memory analysis and debugging tools

• Best practices for prevention

Buffer overflow prevention requires a multi-layered approach:

1. Follow a structured software design process to identify risks early.

2. Apply defensive programming principles to validate inputs and handle errors gracefully.

3. Use hardware-based protections like MPUs where available.

4. Enable compiler flags that help identify memory errors.

5. Test extensively, unit testing, automated testing, and code reviews help catch vulnerabilities early.

By implementing these best practices, you can minimize the risk of buffer overflows in embedded systems, improving reliability and security.

In embedded systems, where reliability and safety are critical, preventing buffer overflows is not just a best practice, it is a necessity. A single buffer overflow can compromise an entire system. Defensive programming, rigorous testing, and hardware protections are essential for building secure and robust embedded applications.

One critical feature of modern web applications is their ability to store and retrieve data on the client side. This is where local storage comes into play.

In this article, we'll explore how to leverage the power of the Blazored LocalStorage NuGet package to seamlessly integrate local storage capabilities into your Blazor applications.

Table of Contents

• Prerequisites
• Understanding Local Storage
• Introducing Blazored.LocalStorage
• Advantages of Using Blazored.LocalStorage in Blazor Applications
• How to Install Blazored.LocalStorage
• Install Using Nuget Package Manager
• Install Using the .NET CLI
• How to Use Blazored.LocalStorage
• Advanced Features and Techniques
• Conclusion

Prerequisites

Make sure you have the necessary tools installed on your computer before continuing with this guide:

• To build and update Blazor projects, you'll need Visual Studio, a feature-rich Integrated Development Environment (IDE) which you can download from the official Microsoft website here.
• The .NET SDK (Software Development Kit) has everything you need to create and execute .NET apps, and it's required for Blazor projects. Make sure your computer has the .NET SDK installed.
• Basic knowledge of C# and Blazor.

With these installed, will be ready to follow along.

Understanding Local Storage

Local storage is a key-value pair storage mechanism supported by modern web browsers. It provides a simple way to store data persistently on the user's device. Unlike session storage, which is cleared when the browser session ends, local storage remains intact even after closing the browser window.

Blazored.LocalStorage is a powerful library that simplifies working with the browser's local storage API (Application Programming Interface) within Blazor applications. It provides a convenient API for storing, retrieving, and managing data in local storage.

By abstracting away the complexities of directly interacting with the localStorage API, this package provides an intuitive and type-safe interface. It lets you focus on building feature-rich Blazor applications without worrying about the underlying storage mechanisms.

Introducing Blazored.LocalStorage

Blazored.LocalStorage is an open-source library designed to provide easy and accessible local storage management in Blazor applications. This library is compatible with both Blazor WebAssembly and Blazor Server projects. This makes it a versatile choice for Blazor developers looking to enhance their applications with persistent, client-side storage capabilities.

At its core, Blazored.LocalStorage facilitates the storage and retrieval of data in the browser's local storage, allowing data to persist across browser sessions.

This is particularly useful for storing user preferences, application state, and other data that needs to persist between page reloads without the need for a database or backend storage solution.

Advantages of Using Blazored.LocalStorage in Blazor Applications

The inclusion of Blazored.LocalStorage in Blazor applications comes with a host of benefits, including:

• Simplified State Management: By leveraging local storage, applications can maintain state more effectively across user sessions, enhancing the user experience.
• Performance Improvements: Storing data locally reduces the need for frequent server requests, leading to faster application performance and reduced server load.
• Enhanced User Experience: Preferences and application states can be preserved, meaning users do not need to reconfigure settings or lose their place in the application upon returning.
• Easy Integration: The API provided by Blazored.LocalStorage is designed to be intuitive and straightforward, ensuring that developers can integrate local storage capabilities into their applications with minimal effort.
• Cross-Session Persistence: Unlike session storage or in-memory data storage, local storage ensures that data persists across browser sessions and tab closures, providing a more consistent user experience.

How to Install Blazored.LocalStorage

Integrating Blazored.LocalStorage into your Blazor project is straightforward, with support for installation via the NuGet Package Manager or the .NET CLI (Command Line Interpreter).

Install Using the NuGet Package Manager

Using Visual Studio, you can easily add Blazored.LocalStorage by following these steps:

• Open your Blazor project in Visual Studio.
• Navigate to the “Solution Explorer”, right-click on "Dependencies", and select “Manage NuGet Packages”.

• In the NuGet Package Manager, click on the “Browse” tab and search for “Blazored.LocalStorage”.

• Find the package in the list, select it, and click “Install”.

Visual Studio will handle the rest, adding the package to your project along with any dependencies.

Install Using the .NET CLI

For those who prefer using the command line or are working within a development environment other than Visual Studio, the .NET CLI provides a simple method to add Blazored.LocalStorage:

dotnet add package Blazored.LocalStorage

Run the command above in your terminal or command prompt from the root directory of your Blazor project. The CLI will download and install Blazored.LocalStorage along with any necessary dependencies.

How to Use Blazored.LocalStorage

Let's dive into some basic examples of using Blazored.LocalStorage in a Blazor application.

How to Register Blazored.LocalStorage in your Blazor Application

We will registerBlazored.LocalStorage into the root of the application, so that it will be available to use everywhere in the application.

In the program.cs file, which is our root file, we will register the Blazored.LocalStorage service by doing the following:

builder.Services.AddBlazoredLocalStorage();

The code snippet above registers the Blazored.LocalStorage into the application. For this to work, make sure you add the code below to the top of the program.cs file:

using Blazored.LocalStorage;

The code snippet above makes sure that the Blazored.LocalStorage is being imported to be used in the file. If you've added everything correctly, your program.cs file should look like this:

using BlazorApp9.Components;
using Blazored.LocalStorage;

namespace BlazorApp9;

public class Program
{
    public static void Main(string[] args)
    {
        var builder = WebApplication.CreateBuilder(args);

        builder.Services.AddRazorComponents()
            .AddInteractiveServerComponents();

        builder.Services.AddBlazoredLocalStorage();

        var app = builder.Build();

        if (!app.Environment.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();

        app.UseStaticFiles();
        app.UseAntiforgery();

        app.MapRazorComponents<App>()
            .AddInteractiveServerRenderMode();

        app.Run();
    }
}

The above is the full code that should be in your program.cs file. With this, you can now use Blazored.LocalStorage anywhere in the application to store and receive data.

How to Store and Retrieve Data in Blazored.LocalStorage

Let's consider a simple scenario where we want to store and retrieve a piece of data using local storage. We'll create a Blazor page with two buttons: one to store data and another to retrieve it.

@page "/"

@inject Blazored.LocalStorage.ILocalStorageService localStorage
@rendermode RenderMode.InteractiveServer

<h3>Local Storage Example</h3>

<input @bind-value="@inputData" />

<button @onclick="StoreData">Store Data</button>
<button @onclick="RetrieveData">Retrieve Data</button>

<p>The retrieved data from the LocalStorage: @storedData </p>

@code {
    private const string dataKey = "localStorageKey";

    private string? storedData;
    private string? inputData;

    private async Task StoreData()
    {
        if(!string.IsNullOrWhiteSpace(inputData))
        {
            await localStorage.SetItemAsync(dataKey, inputData);
            inputData = "";
        }
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            await RetrieveData();
        }
    }

    private async Task RetrieveData()
    {
        storedData = await localStorage.GetItemAsync<string>(dataKey);
    }
}

In the code snippet above, the @inject Blazored.LocalStorage.ILocalStorageService localStorage injects the local storage service to interact with the browser's local storage. The @rendermode RenderMode.InteractiveServer specifies that the page should be rendered as an interactive server-side component. Without the interactive server, the page will not be interactive.

The input field binds to inputData using the @bind-value attribute, allowing users to enter data they wish to store. The dataKey is a constant variable used to store and retrieve data from local storage. The storedData and inputData variables are used to hold the data to be stored and retrieved.

The StoreData method checks to see if inputData is not empty. If not, it stores it in local storage using dataKey, and clears the input field.

OnAfterRenderAsync is triggered after the component's first render. It retrieves data from local storage to ensure that data persists even after the page is reloaded.

RetrieveData retrieves data from local storage and assigns it to storedData for display.

The video above explains how to store and retrieve data stored in localstorage on the client-side.

Advanced Features and Techniques

In this section, we'll talk about how you can set an expiration date on your data, and how the stored data can be encrypted and decrypted for security.

How to Manage the Expiration of Stored Data

To manage the expiration of your stored data, you will create a helper class that stores data along with an expiration timestamp. Create a file called StorageItem.cs which will contain the code below:

public class StorageItem<T>
{
    public required T Data { get; set; }
    public DateTime Expiry { get; set; }
}

The code snippet above is a StorageItem<T> class, which is a generic class that can hold data of any type T and an expiry date DateTime. The Data property is required to be set when an instance of StorageItem is created or initialized, ensuring that it always has a valid value. The Expiry property represents the expiration date of the stored data.

Next, you'll create a file which will be a class that contains methods to set and get from the LocalStorage, with an expiration time. Create a file called LocalStorageHelper.cs:

using Blazored.LocalStorage;

namespace BlazorApp9.Components.Helpers;

public static class LocalStorageHelper
{
    public static async Task SetItemAsyncWithExpiry<T>(ILocalStorageService localStorageService, string key, TimeSpan expiry, T data)
    {
        StorageItem<T> storageItem = new StorageItem<T>
        {
            Data = data,
            Expiry = DateTime.UtcNow.Add(expiry)
        };

        await localStorageService.SetItemAsync(key, storageItem);
    }

    public static async Task<T?> GetItemAsyncWithExpiry<T>(ILocalStorageService localStorageService, string key)
    {
         var storageItem = await localStorageService.GetItemAsync<StorageItem<T>>(key);

        if(storageItem is null) {
            return default;
        }

        if (storageItem.Expiry < DateTime.UtcNow)
        {
            await localStorageService.RemoveItemAsync(key);
            return default;
        }
        return storageItem.Data;
    }
}

In the code above, you can see the necessary using directive for the Blazored.LocalStorage library. It provides easy access to the browser's local storage from Blazor applications.

This is followed by the declaration of the namespace BlazorApp9.Components.Helpers. This organizes the code and indicates that this helper is part of a specific component's helpers within the Blazor application.

Next, the LocalStorageHelper class is defined as a static class. A static class is one that cannot be instantiated and can only contain static members (using non static methods or properties will not be accepted).

Within the LocalStorageHelper class, two static asynchronous methods are defined: SetItemAsyncWithExpiry and GetItemAsyncWithExpiry.

The SetItemAsyncWithExpiry method is responsible for storing an item in the local storage with an associated expiry time. It accepts an ILocalStorageService instance for interacting with local storage, a key string to identify the stored item, a TimeSpan value representing the expiry duration, and the actual data to be stored.

Inside the method, a StorageItem<T> object is created, where T is the type of data being stored. This object includes the data and the expiry time, which is calculated by adding the specified TimeSpan to the current UTC time.

This StorageItem object is then serialized and saved in local storage under the given key using the SetItemAsync method of ILocalStorageService.

The GetItemAsyncWithExpiry method is responsible for retrieving an item from local storage and checking if it has expired. It also accepts an ILocalStorageService instance and a key string.

This method attempts to retrieve the stored StorageItem<T> object using the key. If the retrieved item is null, it returns the default value for the type T (typically null for reference types and zero or equivalent for value types).

If the item is found but its expiry time is earlier than the current UTC time, it means the item has expired. In this case, the item is removed from the local storage using the RemoveItemAsync method of ILocalStorageService, and the method returns the default value for T. If the item is valid and has not expired, the method returns the stored data.

How to Implement Encryption and Decryption

In this section, we will explore a utility file that provides encryption and decryption functionalities for a Blazor application.

The EncryptionHelper.cs class includes methods for encrypting and decrypting strings, as well as methods for serializing objects to JSON (Javascript Object Notation) and then encrypting them. This ensures that sensitive data can be securely stored and transmitted.

Let’s dive into the code to understand how these methods work and how you can use them. Add the following code for this file:

using System.Security.Cryptography;
using System.Text;
using System.Text.Json;

namespace BlazorApp9.Components.Helpers;

public static class EncryptionHelper
{
    private static readonly string EncryptionKey = "your-encryption-key";

    private static byte[] GetKeyBytes(string key)
    {

        byte[] keyBytes = Encoding.UTF8.GetBytes(key);
        Array.Resize(ref keyBytes, 32);
        return keyBytes;
    }

    public static string Encrypt(string plainText)
    {
        byte[] iv = new byte[16];
        byte[] array;

        using (Aes aes = Aes.Create())
        {
            aes.Key = GetKeyBytes(EncryptionKey);
            aes.IV = iv;

            ICryptoTransform encryptor = aes.CreateEncryptor(aes.Key, aes.IV);

            using (MemoryStream memoryStream = new MemoryStream())
            {
                using (CryptoStream cryptoStream = new CryptoStream((Stream)memoryStream, encryptor, CryptoStreamMode.Write))
                {
                    using (StreamWriter streamWriter = new StreamWriter((Stream)cryptoStream))
                    {
                        streamWriter.Write(plainText);
                    }

                    array = memoryStream.ToArray();
                }
            }
        }

        return Convert.ToBase64String(array);
    }

    public static string Decrypt(string cipherText)
    {
        byte[] iv = new byte[16];
        byte[] buffer = Convert.FromBase64String(cipherText);

        using (Aes aes = Aes.Create())
        {
            aes.Key = GetKeyBytes(EncryptionKey);
            aes.IV = iv;

            ICryptoTransform decryptor = aes.CreateDecryptor(aes.Key, aes.IV);

            using (MemoryStream memoryStream = new MemoryStream(buffer))
            {
                using (CryptoStream cryptoStream = new CryptoStream((Stream)memoryStream, decryptor, CryptoStreamMode.Read))
                {
                    using (StreamReader streamReader = new StreamReader((Stream)cryptoStream))
                    {
                        return streamReader.ReadToEnd();
                    }
                }
            }
        }
    }

    public static string SerializeAndEncrypt<T>(T data)
    {
        var jsonString = JsonSerializer.Serialize(data);
        return Encrypt(jsonString);
    }

    public static T DecryptAndDeserialize<T>(string cipherText)
    {
        var json = Decrypt(cipherText);
        return JsonSerializer.Deserialize<T>(json);
    }
}

The EncryptionHelper class is a static helper class designed for encrypting and decrypting data. This is particularly useful for securing sensitive information in a Blazor application.

The class above defines a static readonly field EncryptionKey which holds the encryption key. This key is crucial for both the encryption and decryption processes. It's important to use a strong and securely stored key.

The GetKeyBytes method converts the string key into a byte array and ensures its length is 32 bytes. This is because the AES encryption algorithm requires a 256-bit key, which is 32 bytes long.

The Encrypt method encrypts a plaintext string using AES encryption. It first creates an initialization vector (IV) of 16 bytes, which is required by the AES algorithm. The method then sets up an AES object with the encryption key and IV, and uses a CryptoStream to write the encrypted data to a memory stream. This encrypted data is then converted to a base64 string for easy storage and transmission.

The Decrypt method performs the reverse operation. It converts a base64 string back to a byte array, sets up the AES object with the same key and IV, and uses a CryptoStream to read the decrypted data from the memory stream. The result is the original plaintext string.

The EncryptionHelper class provides two methods for handling complex data structures: SerializeAndEncrypt and DecryptAndDeserialize. The SerializeAndEncrypt method first serializes an object to a JSON string using JsonSerializer.Serialize, and then encrypts this JSON string using the Encrypt method. This allows complex objects to be securely stored in an encrypted format.

The DecryptAndDeserialize method decrypts an encrypted JSON string back into its original form and then deserializes it into an object of type T using JsonSerializer.Deserialize. This combination of decryption and deserialization ensures that complex data can be securely retrieved and used within the application.

How to Connect the Expiration and Encryption to the User Interface

Now we'll walk through a Blazor component (Home.razor) that allows users to store and retrieve encrypted data in the browser's local storage. This ensures that sensitive information is protected and automatically expires when no longer needed.

This approach combines the ease of local storage with the security of encryption, providing a robust solution for managing user data in web applications. Let's dive into the code to see how it works.

 @page "/"
@using BlazorApp9.Components.Helpers

@inject Blazored.LocalStorage.ILocalStorageService localStorage
@rendermode RenderMode.InteractiveServer

<h3>Local Storage Example</h3>

<input @bind-value="@inputData" />

<button @onclick="StoreData">Store Data</button>
<button @onclick="RetrieveData">Retrieve Data</button>

<p>The retrieved data from the LocalStorage: @storedData </p>

@code {
    private const string dataKey = "localStorageKey";

    private string? storedData;
    private string? inputData;

    bool isDataLoaded = false;

    private async Task StoreData()
    {
        if (!string.IsNullOrWhiteSpace(inputData))
        {
            string encryptData = EncryptionHelper.SerializeAndEncrypt(inputData);
            await LocalStorageHelper.SetItemAsyncWithExpiry(localStorage, dataKey, TimeSpan.FromMinutes(30), encryptData);
            inputData = "";
        }
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender && !isDataLoaded)
        {
            await RetrieveData();
            isDataLoaded = true;
            StateHasChanged();
        }
    }

    private async Task RetrieveData()
    {
        string encryptData = await LocalStorageHelper.GetItemAsyncWithExpiry<string>(localStorage, dataKey);
        storedData = encryptData != null ? EncryptionHelper.DecryptAndDeserialize<string>(encryptData) : "Data not found or expired.";
    }
}

In the code above, the StoreData method checks if inputData is valid, encrypts it using EncryptionHelper.SerializeAndEncrypt, and stores it in local storage with a thirty-minute expiry using LocalStorageHelper.SetItemAsyncWithExpiry. The input field is then cleared.

The OnAfterRenderAsync method retrieves data from local storage after the component's initial render. This ensures previously stored data is loaded when the page first displays. It runs once, setting isDataLoaded to true and calling StateHasChanged to update the user interface (UI).

The RetrieveData method fetches data from local storage using LocalStorageHelper.GetItemAsyncWithExpiry. If the data is found and valid, it decrypts and deserializes it using EncryptionHelper.DecryptAndDeserialize. If not, it sets storedData to "Data not found or expired."

The video above demonstrates how you can implement the concepts discussed in this guide in a web application.

Conclusion

Blazored.LocalStorage offers a powerful and easy-to-use solution for managing user information in Blazor applications. Its integration brings numerous benefits, including enhanced state management, improved performance, and a better user experience.

After reading through this article and trying out the code for yourself, you should be able to incorporate local storage capabilities into any Blazor project. This will help you unlock the full potential of client-side storage in your web applications.

In this article, we'll explore:

• What LINQ is.
• How to use it.
• Examples of some common LINQ methods.

Table of Contents

• Language Level Query Syntax
• Method Syntax
• Common LINQ API Methods
  • OrderBy Method
  • First Method
  • Single/SingleOrDefault Method
  • Select Method
• How to Combine Methods
• Deferred Execution
• How to Chain IQueryable API Methods
• Conclusion

We'll be utilizing an Animal class in this article:

public class Animal
{
    public string Name { get; set; }
    public int Age {get;set;}
    public string Sound { get; set; }
}

Language Level Query Syntax

You may see something that resembles a SQL query in some code snippets. For example:

var animals = new List<Animal>
{
    new Animal { Name = "Dog", Age = 2, Sound = "Bark" },
    new Animal { Name = "Cat", Age = 2, Sound = "Meow" },
    new Animal { Name = "Fox", Age = 5, Sound = "Bark" }
};


var barkingAnimals =
    from animal in animals
    where animal.Sound == "Bark"
    select animal;

You can build queries similar to SQL for complex tasks, but this can be excessive. You can simplify these queries using the LINQ API methods syntax.

Method Syntax

The LINQ API methods utilizes a predicate (in the form of a lambda extension) to determine the criteria.

We can write the above query using the method syntax like so:

var barkingAnimals = animals.Where(x=> x.Sound == "Bark").ToList();

It's a lot easier to write and much more concise for such a simple query.

It reads a lot better too: barking Animals equals all the animals where the sound property equals Bark.

LINQ querying methods all return an IQueryable object. This informs the compiler that the variable is not the result of the query, but the definition of the query. [see deferred execution later in this article.]

In order to use the results of the query we can either:

• Iterate over the "queryable" object (for example: using a ForEach loop)
• Convert to an IEnunerable type. For example: a List/Array.

Common LINQ API Methods

OrderBy Method

OrderBy is a useful LINQ API method that lets you order any IEnumerable object.

We can use it like so:

var orderedByAge = people.OrderBy(x=>x.Age);

// or

var orderedByAgeDescending = people.OrderByDescending(x=>x.Age);

The above shows examples of ordering by Age in both ascending and descending order.

First Method

var first = animals.First(x=> x.Sound == "Bark");

This will return the first object from the list that matches the criteria.

Single and SingleOrDefault Method

This is used when you know/expect that there will be only one object that matches your criteria.

Example:

var cat = animals.Single(x=>x.Name == "Cat");

Data can change over time, leading to unexpected results. Writing defensive code is important. If multiple objects named "Cat" are found, an uncaught error will occur. To prevent this, use the SingleOrDefault method, which returns a default value (null for strings) on error. Then check if the cat variable is not null.

var cat = animals.SingleOrDefault(x=> x.Name=="Cat");

if(cat != null){
  Console.WriteLine("A single cat was found");
}

Select Method

Let's say that you wish to return only the types of animal, from the Animal object. This can be accomplished with the Select method. This will create a new object for each element in the list/array.

var typesOfAnimal = animals.Select(x=>x.Name).ToList();

But what if you want to return their name and sound? That's just as easy with the Select method. However, you'll have to create an anonymous object instead of just returning the property.

var animals = animals.Select(x=> { Name = x.Name, 
Noise = x.Sound}).ToList();

This should now return a list of anonymous objects, with a Name and a Sound property.

How to Combine Methods

Using the People class:

public class Person
{
    public string Name { get; set; }
    public string Address { get; set; }
}

var people = new List<Person>()
{
    new() { Name = "Harry Potter", Address = "123 Privet Drive, Hogwarts, United Kingdom" },
    new() { Name = "Alex the Kidd", Address = "Rock Paper Scissors Avenue, United Kingdom" },
    new() { Name = "Donkey Kong", Address = " The Monkey Temple, Jungle" }
};

You can combine LINQ API methods to carry out multiple actions. Take the following scenario as an example:

We want to find all the people in a list whose address contains "United Kingdom".

To accomplish this, you can utilize a combination of Where()and Contains(), passing the Contains() function as part of the predicate.

var ukResidents = peopleList.Where(p => p.Address.Contains("United Kingdom")).ToList();

Deferred Execution

LINQ queries use what's called deferred execution. This means that the query will not be executed immediately when it is defined.

Instead, it is executed when the query results are iterated or when certain operators trigger the execution explicitly. This deferred execution enables optimizations and improves performance by avoiding unnecessary computations.

This goes back to what I discussed earlier with the conversion of IQueryable to another object. For example, a list using .ToList(). It's the ToList()that converts the IQueryable object to a list and actually executes the query.

Lets take a look at an example:

var people = new List<Person>()
{
    new() { Name = "Harry Potter", Address = "123 Privet Drive, Hogwarts, United Kingdom" },
    new() { Name = "Alex the Kidd", Address = "Rock Paper Scissors Avenue, United Kingdom" },
    new() { Name = "Donkey Kong", Address = " The Monkey Temple, Jungle" }
};

// then we'll define the query
var peopleCalledHarryPotter = people.Where(x => x.Name == "Harry Potter");

// this will create the query object, You could write other code here.

// now convert the IQueryable query object to a List, thus invoking the actual query.

var list = peopleCalledHarryPotter.ToList();

Though a basic example, this demonstrates that you can create a queryable object and execute additional code before actually running the query using the .ToList() extension method.

How to Chain IQueryable API Methods

Similar to combining Where and Contains, you can further enhance your queries by chaining LINQ API methods.

For example, using Where() and GroupBy() together allows you to filter and then group data by a property.

Let's apply what we've learned and chain these methods. Instead of using .ToList() to create a new variable with the results, we can utilize the query object within a ForEach loop to execute the query and iterate over the results simultaneously.

Update the Person class to have a Age property:

public class Person
{
    public string Name { get; set; }
    public string Address { get; set; }    
    public int Age { get; set; }
}

Then look at the following code, which will first filter the list of people, and then group them based on Age.

using System;
using System.Collections.Generic;
using System.Linq;

public class Program
{
    public static void Main()
    {
        List<Person> people = new List<Person>
        {
            new Person { Name = "John", Age = 30 },
            new Person { Name = "Alice", Age = 25 },
            new Person { Name = "Bob", Age = 30 },
            new Person { Name = "Charlie", Age = 25 },
            new Person { Name = "Eve", Age = 35 }
        };

        var groupsOfPeople = people
            .Where(p => p.Age >= 30)  // Filter people with age >= 30
            .GroupBy(p => p.Age);    // Group people by their age

        foreach (var group in groupsOfPeople)
        {
            Console.WriteLine($"Age Group: {group.Key}"); // output the Age
            foreach (var person in group)
            {
                Console.WriteLine($"Name: {person.Name}, Age: {person.Age}");
            }
        }
    }
}

This combination of LINQ methods allow us to define more complex quieries without using the Language Level Query Syntax.

Sometimes it can based on personal preference, but I believe the method syntax is much more readable.

Conclusion

In this article, we've explored the power of LINQ in .NET, comparing its language-level query syntax and method syntax. We've demonstrated how to simplify complex queries using LINQ API methods and discussed common methods like OrderBy, First(), Single(), SingleOrDefault(), and Select.

We highlighted the importance of writing defensive code and the concept of deferred execution, which optimizes performance. By combining and chaining LINQ methods, you can create complex, readable queries efficiently.

LINQ is a versatile tool that enhances your ability to handle data in .NET applications. Whether using query syntax or method syntax, LINQ provides a powerful way to write efficient and maintainable code.

You can find some useful examples on the Microsoft website here

As always I'd welcome comments, or discussion on the topic. You can follow me on Twitter

Dr. Charles "Chuck" Severance is also creator of many popular free learning resources like his Python for Everyone and C for Everyone, which millions of students have taken over the past decade.

We talk about:

• What separates a Master Programmer from an average developer, and how to become one

• Dr. Chuck's mission to make programming knowledge freely available

• The fundamental shortcomings of how Computer Science is currently taught at universities – even elite universities like the one he's a professor at

• Dr. Chuck's theories on recent tech layoffs and what he thinks the near future holds

• Dr. Chuck's love of racing $2,500 cars that he revives from the junk yard, and flying planes

Can you guess what song I'm playing on my bass during the intro? It's a 2015 song from an Australian musician.

Be sure to follow The freeCodeCamp podcast in your favorite podcast app. And share this podcast with a friend. Let's inspire more folks to learn to code and build careers for themselves in tech.

Also, I want to thank the 9,331 kind people who support our charity each month, and who make this podcast possible. You can join them and support our mission at: https://www.freecodecamp.org/donate

You can watch the interview on YouTube:

Or you can listen to the podcast in Apple Podcasts, Spotify, or your favorite podcast app. You can also listen to the podcast below, right in your browser:

Links we talk about during our conversation:

• Dr. Chuck's latest freeCodeCamp course on C programming: https://www.freecodecamp.org/news/complete-c-programming-course-from-dr-chuck/

• Dr. Chuck's Python for Everyone freeCodeCamp Course: https://www.freecodecamp.org/news/python-for-everybody/

• Kylie Ying's popular Machine Learning for Everyone course inspired by Dr. Chuck: https://www.freecodecamp.org/news/machine-learning-for-everybody/

• Dr. Chuck's website with his free interactive coursework: https://online.dr-chuck.com/

About the Course

In this comprehensive course, Dr. Chuck uses the classic book "The C Programming Language" by Brian Kernighan and Dennis Ritchie, often referred to as K&R, to guide you through the fundamentals of C. This book, first published in 1978, has been instrumental in shaping modern programming languages and provides a solid foundation for learning C.

Here are the sections in this course:

• K&R 0: Historical Context: Understand the historical significance of C and its impact on computing.

• From Python to C: Transition smoothly from Python to C, comparing and contrasting the two languages.

• K&R 1: A Tutorial Introduction: Get an introduction to the basics of C programming.

• K&R 2: Types, Operators, and Expressions: Learn about data types, operators, and expressions in C.

• K&R 3: Control Flow: Explore control flow constructs like loops and conditionals.

• K&R 4: Functions and Program Structure: Understand how to structure programs and write functions.

• K&R 5: Pointers and Arrays: Dive deep into pointers and arrays, key concepts in C.

• K&R 6: Structures: Learn about structures and their uses in C programming.

• Object-Oriented Programming: Discover the underpinnings of object-oriented concepts in C-based languages.

• Encapsulation and Abstraction: Improve your understanding of these critical programming principles.

• Tree Maps and Hash Maps: Implement complex data structures.

• Epilogue: Reflect on the journey and the evolution of programming languages.

In the Epilogue of this course, Dr. Chuck interviews Guido van Rossum, the creator of Python, providing unique insights into the development of modern programming languages and their relationship with C.

About Dr. Chuck

Dr. Charles Severance is a clinical associate professor at the University of Michigan School of Information. Known for his engaging teaching style and deep expertise in programming, Dr. Chuck has made significant contributions to online education. He is the instructor of the popular "Python for Everybody" course series and has authored several influential textbooks.

Why Learn C in 2024?

Learning C in 2024 can be incredibly beneficial for several reasons:

1. Foundational Knowledge:

   • Understanding Low-Level Programming: C provides a deep understanding of how computers work at a low level, including memory management, pointers, and system calls. This knowledge is crucial for grasping how software interacts with hardware.

   • Strong Foundation for Other Languages: Many modern programming languages, including C++, Java, and Python, have their roots in C. Learning C can make it easier to pick up these languages and understand their underlying mechanisms.

2. Performance and Efficiency:

   • High Performance: C is known for its efficiency and performance. It is often used in performance-critical applications, such as operating systems, embedded systems, and game development.

   • Resource Management: C allows fine-grained control over system resources, which is essential for writing efficient and optimized code.

3. System-Level Programming:

   • Operating Systems and Kernels: C is the language of choice for developing operating systems and kernels. Learning C is essential if you are interested in systems programming or contributing to open-source projects like Linux.

   • Embedded Systems: C is widely used in embedded systems programming. If you are interested in developing firmware or working with microcontrollers, C is a must-know language.

4. Career Opportunities:

   • Job Market Demand: C remains in demand in various industries, including systems programming, embedded systems, telecommunications, and game development.

   • Versatility: Knowledge of C can open doors to various career paths, from software development to cybersecurity and beyond.

5. Legacy Systems:

   • Maintenance of Existing Codebases: Many legacy systems and critical software are written in C. Understanding C can be crucial for maintaining and updating these systems.

   • Interoperability: C code is often integrated with other languages and systems. Knowing C can help you work on projects that require interfacing with existing C codebases.

6. Educational Value:

   • Algorithm and Data Structure Implementation: C is excellent for learning and implementing fundamental algorithms and data structures. This experience can enhance your problem-solving skills and algorithmic thinking.

   • Understanding Computer Science Concepts: C is often used in academic settings to teach core computer science concepts, such as operating systems, compilers, and networking.

Conclusion

Whether you're a beginner looking to grasp the basics of C or an experienced programmer wanting to refresh your knowledge, this course is perfect for you. Watch the full course on the freeCodeCamp.org YouTube channel (19-hour watch).

• 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!

In this article, you will learn some of the different techniques to print strings in C.

What is a String in C?

A string is a sequence of characters, like letters, numbers, or symbols, that are grouped together. It is used to represent text in programs.

Strings are not a built-in data type in C. Instead, they are represented as arrays of characters, terminated with a special character called the null terminator, \0.

Here is an example of how to create a string in C:

char greeting[] = "Hello world!";

In the code above, I declared a character array named greeting, and initialized it with the string Hello world! enclosed within double quotes, " ".

The C compiler automatically includes the null terminator, \0, at the end of Hello world!.

How to Print a String in C Using the printf() Function

The printf() function is one of the most commonly used ways of printing strings in C.

It stands for "print formatted", and belongs to the standard input/output library, stdio.h. So, in order to use it, you need to first include the stdio.h header file at the beginning of your program.

Let’s take the following example:

#include <stdio.h>

int main(void) {
  char greeting[] = "Hello world!";

  printf("%s\n", greeting);
}

// Output:
// Hello world!

In the example above, I first included the stdio.h header file at the beginning of my program, which contains the declaration of the printf() function.

Next, I declared a character array named greeting and initialized it with the text Hello world! wrapped in double quotes.

Lastly, I used the printf() function to print the text Hello world!.

When printing a string using the printf() function, you need to use a format specifier.

A format specifier acts as a placeholder that tells the printf() function how to format and print specific types of data. They begin with a percent sign %, followed by a character that specifies the type of data to be formatted. The format specifier for strings is %s.

So, in the line printf("%s\n", greeting);, the %s format specifier tells printf() to print the string stored in the greeting variable followed by a newline character, \n.

Note that the %s format specifier doesn’t include the null terminator, \0, when printing strings. It prints the characters in the string until it encounters it.

How to Print a String in C Using the puts() Function

Another function used for printing strings is puts().

Let’s take the following example:

#include <stdio.h>

int main(void) {
  char greeting[] = "Hello world!";

  puts(greeting);
}

// Output
// Hello world!

In the example above, I first included the stdio.h header file which contains the puts() declaration.

Then, I declared a character array and initialized it with the text Hello world!. The string automatically ends with the null terminator, \0.

Lastly, I used the puts() function to print the string to the console and passed the string variable greeting as an argument.

The puts() function automatically adds a newline character, \n, at the end of the string.

Note that the puts() function is used to print null-terminated strings. A null-terminated string is a sequence of characters stored in memory followed by a character called the null terminator \0.

So far, all the examples have used only null-terminated strings, such as char greeting[] = "Hello world!";. In memory, it would be represented as ['H', 'e', 'l', 'l', 'o', 'w', 'o', 'r', 'l', 'd', '!', '\0'].

Creating non-null-terminated strings intentionally is not common in C.

Here is an example of a non-null-terminated string: char greeting[] = {'H', 'e', 'l', 'l', 'o'};This array of characters does not include the null terminator, \0, so it is a non-null-terminated string.

If you try to print a non-null-terminated string using puts(), you will end up getting undefined behavior, such as garbage characters at the end of the string:

#include <stdio.h>

int main(void) {
  char greeting[] = {'H', 'e', 'l', 'l', 'o'};

  puts(greeting);
}

// Ouput when I run the code the first time:
// Helloq

// Ouput when I run the code a second time:
// Hellop

// Ouput when I run the code a thrid time:
// Hellow

The printf() Function VS the puts() Function – What's the Difference?

You may be wondering what the difference is between printf() and puts().

The puts() function prints the text as it is, without any formatting. It also automatically adds a newline character at the end of the string.

The printf() function doesn’t automatically add a new line - you have to do it explicitly.

However, it allows for formatted output, and gives you more control and flexibility over where and how you insert different data types into the format string:

#include <stdio.h>

int main(void) {
    char name[] = "John";
    int age = 30;

    // Printing strings using puts()
    puts("Using puts():");
    puts("My name is John and I'm 30 years old.");

    // Printing strings usingprintf()
    printf("\nUsing printf():\n");
    printf("My name is %s and I'm %d years old. \n", name, age);
}

In the example above, the puts() function prints a simple string without any formatting. It also automatically adds a newline character, \n, at the end of the string.

On the other hand, the printf() function formats the string and embeds two variable values. It uses format specifiers, such as %s for strings and %d for integers, to specify the type of data the variables hold, and where the variables should be inserted into the string. It also adds a newline character at the end.

Conclusion

In this article, you learned about the two most commonly used functions in C for printing strings.

The printf() function is commonly used for printing formatted text to the console. It allows you to format your output and print strings, numbers and characters.

The puts() function is more simple compared to printf(). It is great for basic text output and automatically adds a newline character, \n, to the printed string.

Thank you for reading, and happy coding!

In this article, you'll learn the basics of defining functions in C.

What is a Function in C?

In programming, a function is a block of code that performs a specific task.

Functions take inputs, process them, perform operations, and produce an output.

Functions are important because they organize your code and promote code reusability.

Instead of writing the same code again and again and repeating yourself, you write code once and then can use it whenever you want to perform that specific task.

In C, there are generally two types of functions:

• Standard library functions. Standard library functions are provided by the C standard library and defined in header files. Examples of standard library functions include printf() for printing formatted output to the console and scanf() for reading formatted input from the user. Both are defined in the stdio.h header file.

• User-defined functions. User-defined functions are defined by you, the programmer. These functions are tailored to your program’s needs and requirements. For example, a user-defined function may calculate the sum of two numbers or check if a number is even or odd.

In this article, you will learn how to create user-defined functions.

Syntax of Functions in C

Here is the general syntax of a function in C:

return_type function_name(parameter) {
  // function body with the code to be executed
  return value;
}

Let’s break it down:

• The return_type lets the C compiler know the type of data of the value the function will return after its execution. It can be any valid C data type such as int, float, char, or void if the function doesn’t return a value.

• The function_name is the name you give the function. It should be meaningful and accurately describe what the function does. You will later use this to call the function.

• The parameter is optional. A parameter is a variable a function accepts as input inside parentheses. A function can receive zero or more parameters. If the function accepts multiple parameters, they are separated by commas. Each parameter consists of the data type followed by a name.

• Inside the curly braces, {}, is the function’s body. Here is the actual code, the instructions that perform a specific task.

• Inside the function body, there can be an optional return value. You use the return keyword followed by the value you want to return. If the function has a voidreturn_type, you don't need to specify a return value.

How to Call a Function in C

Here is the syntax for calling a function in C:

function_name(arguments);

Let's break it down:

• function_name is the name of the function you want to call. It should be the same name you used to define your function.

• arguments are the values you pass to the function. If the function accepts any parameters, you pass the arguments in parentheses when you call the function. Each argument is separated by a comma.

If the function returns a value, you can store it in a variable for later use:

data_type result = function_name(arguments);

How to Define and Call a Function in C Example

Let's look at a simple function that adds two numbers:

#include <stdio.h>
int add(int num1, int num2) {
    return num1 + num2;
}

int main(void) {
    int num1, num2, result;

    printf("Enter first number: ");
    scanf("%d", &num1);

    printf("Enter second number: ");
    scanf("%d", &num2);

    result = add(num1, num2);

    printf("The sum of %d and %d is %d\n", num1, num2, result);

    return 0;
}

// Output: 

// Enter first number: 2
// Enter second number: 3
// The sum of 2 and 3 is 5

Let’s break down the code step by step.

Include the Header File

I first included the library stdio.h with the line #include <stdio.h>.

This line includes the standard input-output library (<stdio.h>), which gives you access to the printf() and scanf() functions. Now, you can receive user input and print text to the console.

Define the add Function

Next, I defined the following function:

int add(int num1, int num2) {
    return num1 + num2;
}

This function has an int return type, which indicates that it will return an integer value after execution.

The function is named add, and inside parentheses, it accepts the integer parameters num1 and num2.

Within the curly braces, the function body contains the function code. In this case, the function code consists of only the return statement return num1 + num2;. This code calculates the sum of num1 and num2 using the + operator, and returns the result.

The add() function is defined before being used in the main() function later on. In C, functions must be defined before they are used. By placing the add() function definition above the main() function, the compiler knows about it when it encounters the function call in main().

Define the main() Function

Next, I defined the main() function, which is the starting point of every C program:

int main(void) {
    int num1, num2, result;

    printf("Enter first number: ");
    scanf("%d", &num1);

    printf("Enter second number: ");
    scanf("%d", &num2);

    result = add(num1, num2);

    printf("The sum of %d and %d is %d\n", num1, num2, result);

    return 0;
}

Inside the main() function, I first declared the integer variables num1, num2, and result.

Note that num1 and num2 variables are different from the num1 and num2 parameters that the add() function receives. These two variables will store the numbers that the user will enter.

Then, I prompted the user to enter the first number using the printf() function, and used the scanf() function to read the input and store it in the variable num1. The %d format specifier is used to indicate that scanf() should expect an integer input.

I followed the exact same procedure for receiving and storing the second number.

Next, I called the add() function with the num1 and num2 as arguments. The add() function will add the two numbers together. The result of the calculation is then stored in the result variable.

Following that, I used the printf() function to print the num1, num2 and result variables to the console. The format specifier %d is used to print integer values.

Lastly, the line return 0; is a statement that indicates that the program executed successfully. When a C program terminates, it returns an exit status to the operating system, with 0 typically indicating the program executed without any errors.

Execute the Program

When the program is executed, the main() function is called first.

You first see the prompt Enter first number:. In my case, I entered 2 as the first number.

Once you enter a number, you will see the second prompt: Enter second number:. I entered the number 3 as the second number.

Then, the add() function is called, which adds the numbers 2 and 3.

Lastly, the line The sum of 2 and 3 is 5 is printed to the console.

Conclusion

In this article, you learned the very basics of defining functions in C.

Specifically, you learned about the two different types of functions in C, and the general syntax for defining your own functions.

Lastly, you saw an example of a simple function that added two numbers and returned the result.

Thanks for reading, and happy coding!

We just posted a course on the freeCodeCamp.org YouTube channel that will help you master this versatile language. This beginner's course guides you through the basics to advanced C# programming concepts, complete with engaging mini-projects to cement your learning. Aba from CoffeeNCode created this course.

Here is an overview of the different key sections of this course:

Introduction and Environment

Learn about the course and set up your dev environment by installing Visual Studio 2022, the premier IDE for C# development. Follow step-by-step instructions to set up your environment efficiently.

Your First Steps in C

Embark on your programming adventure by creating your first project and writing the iconic "Hello World" program, laying the foundation for your C# skills.

Understanding Data Types and Operators

Explore various data types like numeric, text-based, and Boolean, and learn how to manipulate them using different operators. Understand the significance of the var and const keywords in C#.

Practical Exercises

Solidify your understanding through practical exercises, ranging from storing user data to building a simple odd/even number checker.

Mastering Input/Output and Control Structures

Gain proficiency in handling console input/output and making decisions in your code with if and switch statements. Learn to control the flow of your programs with loops and understand the nuances of the conditional operator.

Advanced Concepts

Delve into advanced topics like numeric formatting, the TryParse function, and various string operations. Enhance your programming toolkit with knowledge about arrays, lists, and dictionaries.

Functions and Exception Handling

Discover how to create and utilize functions, handle exceptions gracefully, and employ debugging tools to troubleshoot your code.

Object-Oriented Programming

Step into the world of object-oriented programming with lessons on structures, classes, and their components. Learn how to define class functions, fields, properties, and more.

Capstone Mini-Projects

Apply what you've learned in real-world scenarios through mini-projects, including a times table generator, a Fizz Buzz game, a password checker, and more. These projects are designed to challenge you and enhance your problem-solving skills

C# is a valuable skill that will open numerous doors in your career. Watch the full course on the freeCodeCamp.org YouTube channel (8-hour watch).

C# 12 has just been released, and it continues the long tradition of improvements in the safety of the language's software design and execution.

One of these improvements relates to manipulating null references, a programming concept that many developers don't really love.

Using null references in your code can cause all kinds of issues, like exceptions and a lack of information.

This article will teach you how to cope with null references in the latest version of the C# programming language and .NET. The name of the game: let no null pass unattended.

This demonstration will have several stages, each with its own small demo. If you wish to skip through, please use the table of contents below.

Table of Contents

1. Prerequisites
2. How to Use Nullable Reference Types
3. How to Use the is null and is not null Patterns
4. How to Use Type-Test-and-Set Patterns
5. How to Use Property Patterns
6. How to Use the Null Propagation and Null Coalescing Operators
7. How to Work with Optional Objects
8. Final Notes

Prerequisites

There are a few prerequisites you will need to meet before proceeding. I assume that you've written enough C# code to see null references in their natural habitat. And I expect you to understand that they can threaten the code's design and stability.

This article will clarify these concepts and identify the issues and solutions using C# syntax and libraries.

If you are ready, we can get started with nullable reference types. That will allow us to set up the working environment and get up to speed for the more complex demos that will follow.

How to Use Nullable Reference Types

Nullable reference types were introduced in C# 8 and quickly became a mainstay.

The short story is that you can either declare a reference nullable (for example, string? s) or non-nullable (string s).

Note the plot twist: what used to be just a reference before C# 8 (string s was an ordinary reference to a nullable string) has now become something more: a reference that should never be set to null.

That was the breaking change, maybe the first in a decade of C# syntax evolution!

The compiler will do its best to check if all the assignments to a non-nullable reference (the one without the question mark) set it to a proper object. If it finds an execution path that might set it to null, the compiler will issue a compile-time warning. This is called "definite assignment analysis," as the compiler tries to prove that each non-nullable reference is definitely assigned to an object.

If you have already grown accustomed to nullable reference types, I have a question: would you consider not using them today? Probably not.

Let's start with some code. Below, you see two records – one deriving from another. Record types came with C# 9. I am using them here only for brevity. Consider these two types as just the base and the derived class.

record Person(string FirstName, string LastName);

record Celebrity(string FirstName, string LastName, string KnownFor)
    : Person(FirstName, LastName);

We can either instantiate a record and assign the instance to a reference, or assign a reference to null.

This is where the definite assignment analysis comes to the table. If there is a sequence of instructions in which the reference ends up being null, we must use the question mark to indicate that the reference can be null.

Person? left = null;
Person? bob = new Person("Bob", "Coder");
Person fowler = new Celebrity("Martin", "Fowler", "famous books");
Person martin = new Celebrity("Bob", "Martin", "SOLID principles");

You can see that the second reference (bob) is assigned to a proper object but is still declared nullable. That is perfectly fine in scenarios where an object is coming from the outside, and you might not know whether it will be there or not.

Make sure you don't assign a nullable reference to a non-nullable one, though. That would cause a compile-time warning, which you can raise to the level of compile-time error if you prefer.

It is essential to understand that nullability is not the property of the type but rather a hint given to the compiler. Nullable reference types are only used during the compile-time analysis and are never stored in the compiled type itself.

One consequence is that you cannot declare a nullable type parameter in a generic type. That wouldn't make sense because the compiler has no place to put that information in the compiled type!

But then comes a twist because we are free to indicate any reference of the generic parameter type as nullable, as in the code below. Such a reference is subject to definitive assignment analysis as any other.

void Showcase<T>(string caption, Action<T?> action, params T?[] objects)
{
    Console.WriteLine($"Showcasing {caption}:".ToUpper());
    foreach (T obj in objects) action(obj);
    Console.WriteLine();
}

We have defined the utility function to showcase all situations incorporating null references in the rest of this article. As I already pointed out, it would be a compile-time error to declare this generic function as Showcase<T?>, while accepting a nullable T? in the argument list would be perfectly valid. Makes your head spin around!

An even greater mystery is to come: why not remove nullable from the argument list? What would that mean?

void Showcase<T>(string caption, Action<T> action, params T[] objects)
{
    Console.WriteLine($"Showcasing {caption}:".ToUpper());
    foreach (T obj in objects) action(obj);
    Console.WriteLine();
}

That would leave it to the caller to determine nullability because – now pay attention! – a concrete generic parameter type can be nullable. It determines the nullability of references, which is a real thing during compilation.

I hope you have started to grasp these concepts more now. Unfortunately, it would take a lot of space to explain this concept in-depth, but I would certainly advise you to learn more about nullability of types. It is now part of C# and is here to stay.

Let me give you a quick demo showcasing the two possible choices:

Showcase<Person?>("Nullable reference types", Console.WriteLine,
                  left, bob, fowler, martin);
Showcase<Person>("Non-nullable reference types", Console.WriteLine,
                  fowler, martin);

The first call above allows null references in the arguments, while the second call forces non-nullable references. So the compiler would check the references passed as arguments in that case and raise a warning if any of them is, or could be, null.

That concludes our crash course on nullable reference types in C#. We are ready to proceed with more advanced matters.

Before that, here is the output produced by the code as we have it so far:

SHOWCASING NULLABLE REFERENCE TYPES:
                                                    <-- null is here!
Person { FirstName = Bob, LastName = Coder }
Celebrity { FirstName = Martin, LastName = Fowler, KnownFor = famous books }
Celebrity { FirstName = Bob, LastName = Martin, KnownFor = SOLID principles }

SHOWCASING NON-NULLABLE REFERENCE TYPES:
Celebrity { FirstName = Martin, LastName = Fowler, KnownFor = famous books }
Celebrity { FirstName = Bob, LastName = Martin, KnownFor = SOLID principles }

Pay attention to the empty line in the output. That is where we have passed null to the Console.WriteLine. The WriteLine method accepts null and treats it the same way it treats an empty string.

How to Use the is null and is not null Patterns

Once we get nullability right, we can start doing logic around it. The simplest of all operations is asking if a reference is equal to null.

void IsNull(Person? person)
{
    if (person is null)
        Console.WriteLine("Sad to see you leaving.");

    if (person is not null)
        Console.WriteLine($"Everybody say hello to {person}"!);
}

Showcase("is null and is not null patterns", IsNull,
         left, bob, fowler, martin);

The is operator is testing an object against a pattern. We'll meet this operator several more times in the upcoming sections.

In this demo, you can see its simplest use: testing against the null pattern. There are two possibilities there, is null and is not null, with the meaning that appears to require no further explanation. Oh, but that would be a big mistake!

A corner case is covered by is null and is not null patterns, which might be the core reason for introducing these patterns in the first place. Both patterns will avoid calling any overload of the == and != operators.

So, in theory, a class could overload the == and != operators and, in doing so, declare that a particular object should be considered equal to a null reference. But the is null pattern will not call the operator overload – thus, it will flatly reject comparing that same non-null object to null.

That is a minor corner case, but it teaches how C# operates under the hood. The bottom line is: you should favor is null over ==, and is not null over != when testing for null/non-null.

Here is the printout produced when we run the function above on a few references, one of them being null.

SHOWCASING IS NULL AND IS NOT NULL PATTERNS:
Sad to see you leaving.
Everybody say hello to Person { FirstName = Bob, LastName = Coder }
Everybody say hello to Celebrity { FirstName = Martin, LastName = Fowler, KnownFor = famous books }
Everybody say hello to Celebrity { FirstName = Bob, LastName = Martin, KnownFor = SOLID principles }

How to Use Type-Test-and-Set Patterns

The time has come to raise the bar and use some of the more complex methods of processing nullable references. We will remain with the is operator, but this time, we'll use its more potent form: testing type patterns.

Each reference in C# resolves into an object (or a lack of – a null), and each object we reference possesses the type descriptor. That is at the core of any object-oriented language.

So it's pretty easy for the .NET runtime to check whether a reference is pointing to an object – and, if so, whether that object's runtime type derives from a specific type, directly or indirectly.

That was a mouthful, wasn't it? Let's split that up into bits:

• To test whether a reference references an actual object, that is the person is not null pattern.
• To add the test whether that object is assignable to a particular type, we use the type pattern instead: person is Celebrity.
• Finally, to capture the reference to the desired type and use it in subsequent statements and expressions, we use the full-blown type-test-and-set expression: person is Celebrity celeb.

These are the three stages of extracting information from a reference, each more potent than the other.

Without further ado, here is the method that exercises the most detailed form: testing against null and downcasting, all packed in one condensed expression:

void TypeTestAndSet(Person? person)
{
    string report = person switch
    {
        Celebrity celebrity =>
            $"{celebrity.FirstName} {celebrity.LastName} known for {celebrity.KnownFor}",
        Person commonPerson =>
            $"{commonPerson.FirstName} {commonPerson.LastName}",
        _ => string.Empty,
    };
    if (!string.IsNullOrEmpty(report)) Console.WriteLine(report);

    if (person is Celebrity celeb) Console.WriteLine("*** Did you see a celebrity?");
}

Showcase("Type test and set patterns", TypeTestAndSet,
         left, bob, fowler, martin);

You may have noticed that these expressions are effectively implementing safe downcasting. Downcasting was frowned upon for decades, accused (mostly rightfully) of causing code defects and design flaws.

But times they are a-changin'! Type test and set expressions are coming to software development from functional programming.

This article is not a place to discuss the differences between type testing and downcasting as we knew it in object-oriented languages of the past. I strongly encourage you to learn more about this intriguing topic before judging.

SHOWCASING TYPE TEST AND SET PATTERNS:
Bob Coder
Martin Fowler known for famous books
*** Did you see a celebrity?
Bob Martin known for SOLID principles
*** Did you see a celebrity?

Here, you can see the output produced by the function above. As you can see, each actual type is captured correctly, creating its specific output. And the dreaded null was left out – I have indeed passed a null reference to the function at one instant but hadn't matched any of the patterns, and so was ignored.

This demo would be incomplete without one crucial note. The switch expression (of C# 8) is expecting patterns in order from more specific to more general ones. It would be an error to list a more specific pattern after a more general one. The general pattern would overshadow the subsequent one, never letting its right hand execute. Therefore, the switch expression like the one below causes a compile-time error in C#.

person switch
{
    Person commonPerson =>
        $"{commonPerson.FirstName} {commonPerson.LastName}",
    Celebrity celebrity =>              // <-- error
        $"{celebrity.FirstName} {celebrity.LastName} known for {celebrity.KnownFor}",
    _ => string.Empty,
};

How to Use Property Patterns

An exciting development follows if you push pattern matching even further. One specific form is the properties pattern – one aimed to match the values and attributes of properties of an object (if the object exists!).

void PropertyPatterns(Person? person)
{
    if (person is { FirstName: "Bob"})
        Console.WriteLine($"Greet Bob, the one and only {person.FirstName} {person.LastName}!");
    else
        Console.WriteLine("Not a Bob");
}

Showcase("Property patterns", PropertyPatterns,
         left, bob, fowler, martin);

You don't have to specify the type if you are not interested in downcasting. It will be the type of the reference to the left of the is operator.

But using the is operator implies a null test. Any reference passing the is test will be non-null and safe to check its property values on the right-hand side of the expression.

Therefore, we read this if instruction's condition as follows: If person is not null, and its property FirstName has a value Bob, then...

Here is the output produced when we call the function above:

SHOWCASING PROPERTY PATTERNS:
Not a Bob
Greet Bob, the one and only Bob Coder!
Not a Bob
Greet Bob, the one and only Bob Martin!

How to Use the Null Propagation and Null Coalescing Operators

So far, we have been doing things to objects, which is awkward in an object-oriented design. Remember, in object-oriented programming, it is the object that exposes behavior, and, as the object's users, we only make calls to its methods.

The problems still come when the reference we expect to point to an object is nullable. Making an unguarded call on the null reference was the primary source of defects. But now, with nullable references and definite assignment checks done for us, we should be safe from the dreaded NullReferenceExceptions.

Consider having a method exposed by the class. We can use ToString as a simple example.

record Person(string FirstName, string LastName)
{
    public override string ToString() =>
        $"{FirstName} {LastName}";
}

record Celebrity(string FirstName, string LastName, string KnownFor)
    : Person(FirstName, LastName)
{
    public override string ToString() =>
        $"{base.ToString()} known for {KnownFor}";
}

There is a substantial difference between calling ToString on Person and on Person? types. The latter one is nullable, and therefore an unguarded call might cause dereferencing a null reference, leading to a dreaded NullReferenceException, as you can imagine.

Person a = ...;
Person? b = ...;

string x = a.ToString();      // safe
string y = b.ToString();      // unsafe

Enter the null-propagation operator (?.)! We can safely make an optional call to a method, provided the reference is non-null.

Person a = ...;
Person? b = ...;

string x = a.ToString();      // safe
string? y = b?.ToString();    // safe

But observe the consequences. If the method returns void, the call will be ignored on a null reference. If the method returns a type, then the result will be the nullable version of that type. You cannot expect a string from ToString on a nullable reference, you see? The compiler can only promise a nullable string instead.

And what if we really wanted a string, a true one? Enter the null-coalescing operator (??)! We can easily convert a nullable reference to a non-nullable one by supplying a default to take when the actual value is null at run time.

void NullPropagationAndCoalescing(Person? person)
{
    string report = person?.ToString() ?? string.Empty;
    if (!string.IsNullOrEmpty(report)) Console.WriteLine(report);
}

Showcase("Null propagation and null coalescing operators",
         NullPropagationAndCoalescing,
         left, bob, fowler, martin);

In this example, we make an optional call to the ToString method first but then short-circuit the result to an empty string if the reference were null. The result is that any null reference would produce an empty string for printout.

SHOWCASING NULL PROPAGATION AND NULL COALESCING OPERATORS:
                            <-- An empty string printed here
Bob Coder
Martin Fowler known for famous books
Bob Martin known for SOLID principles

How to Work With Optional Objects

The last method of addressing nulls in this article will actually not use nulls. Another riddle! The idea is to avoid nulls altogether by modeling the objects as possibly missing. Mind the word "possibly" – that will become part of the type declaration the same way nullability was.

If you are new to optional objects, then this short explanation will be anything but sufficient to learn about them. C# has no native support for optional objects. You can choose one of the many implementations available on NuGet, the most popular one being the LanguageExt library.

dotnet add package LanguageExt.Core

An optional object of some type is an object that either exists or does not exist. Whichever the case, the optional object itself will always exist. Another riddle for you to solve!

Here is how we would declare a few optional objects:

using LanguageExt;

Option<Person>[] maybePeople = 
{
    Option<Person>.None,
    Option<Person>.Some(bob),
    Option<Person>.Some(fowler),
    Option<Person>.Some(martin),
};

The two shapes of an optional object are usually referred to as None and Some. The Some variant must contain an actual object. That completes the creation of optional objects and the code that will never have a null reference.

But what is the difference compared to nullable references? Why should we use optional objects at all?

The short story is that optional objects let us apply functions to the optional object's content – if present. The optional object will either invoke the function and pass the content to it or skip calling it altogether if there is no content.

Therefore, an optional type is a single place where that calling protocol is now implemented, the protocol in many ways equivalent to safely dereferencing nullable references.

void Optional(Option<Person> maybePerson)
{
    string report = maybePerson.Match(
        person => person.ToString(),
        string.Empty);
    maybePerson.Do(Console.WriteLine);
}

Showcase("Optional objects", Optional, maybePeople);

The Match method covers both possibilities: It either maps the Person object to a string or substitutes an empty string if the person is missing. The Do method will only pass content to the console if content exists.

Here is the printout produced by the Do method:

SHOWCASING OPTIONAL OBJECTS:
Bob Coder
Martin Fowler known for famous books
Bob Martin known for SOLID principles

You will only see the Some variants printed out. The only missing object in the input array has produced no output because that optional instance has ignored the action passed to its Do method.

The most significant benefit of using optional objects over nullable references is their ability to apply other functions. We might already have many different classes and methods implemented in our codebase, all methods working on non-nullable references. Optional objects can bridge the gap between potentially missing objects and the common methods that are only operational when nothing is missing.

Final Notes

In this tutorial, we started by declaring nullable objects and testing their existence using the is operator.

Then, we extended the example by displaying the richness of pattern-matching expressions: type test and set and property pattern expressions.

We then moved the focus from consuming objects to calling their behavior from the null-propagation operator over the null-coalescing operator, landing in the vast field of functional programming and optional objects.

I hope you enjoyed the ride. In place of farewell, I will invite you to learn more about optional objects in C# by watching my recent video How to Avoid Null Reference Exceptions: Optional Objects in C#.[

This professional certification includes 35 hours of training from Microsoft and an online certification exam by freeCodeCamp.

By the end of this process, you'll have earned your very own verified certification that you can add to your Résumé, LinkedIn, or CV.

A sample Foundational C# certification.

Without further ado, here are the skills this new free professional certification will teach you:

1. Creating your first C# app
2. Coding simple C# apps
3. Creating methods in your C# apps
4. Adding logic to your C# apps
5. Working with variable data in your C# apps
6. Debugging C# apps

Then you'll sign freeCodeCamp's Academic Honesty pledge and take our 1-hour 80-question certification exam. If you receive a passing score, you'll earn your certification.

How to Earn the Foundational C# Certification

Here are the steps for earning this certification, which will take an estimated 35 hours of studying, plus 1 to 2 hours to pass the exam.

1. Go to the Foundational C# Certification path on freeCodeCamp. Here you'll find the training content under "Courses". Press "Expand course" to find all the modules within each course. Each module in the path correlates to a piece of C# training content on Microsoft Learn.
2. Click on each module in the course to find the link to the training content for that module.
3. Complete the training content on Microsoft Learn. (Note: If you have previously completed the training content, you do not need to redo it.)
4. Once you are done with each section, complete the comprehension check question on freeCodeCamp.
5. At the end of each course, you'll receive a Trophy on Microsoft Learn. Enter the Trophy link in the Trophy page on freeCodeCamp. Each step on freeCodeCamp will also show instructions for how you can claim and submit these Trophies.

Learn together with the Microsoft Team

In addition to providing the C# training content on Microsoft Learn, the .NET team is hosting six office-hour style streaming events to help you succeed.

These streams will be every Wednesday at 2:00 pm UTC from September 20 to October 25.

During each of these session, expert presenters will review a training course, walk you through a guided project, and answer your questions.

You can also stay updated with live and on-demand sessions via the .NET YouTube channel.

We've also published a video walkthrough for the C# certification on the freeCodeCamp YouTube channel, taught by freeCodeCamp instructor and veteran C# developer Gavin Lon.

And you can ask questions and get support on the C# section of the freeCodeCamp Forum.

This is a Dream Come True for the freeCodeCamp Community

We've long encouraged campers to obtain professional certifications from tech companies – even though many of these certifications require a credit card and an exam fee.

By making this certification freely available to everyone, we can ensure that anyone – anywhere – can earn a high quality professional certification, regardless of their ability to pay.

I want to thank Microsoft who created a grant to make development of this certification possible. And I want to thank the many developers on both Microsoft's .NET team and freeCodeCamp's instructional design team that made this a reality.

Let's go get certified, shall we? Happy coding. 🏕️

In C#, types called delegates represent references to methods with specific signatures.

Developers use delegates to implement callback methods, handle events, and perform tasks where executing a method at a later time is necessary.

C# offers various delegates, and two commonly used ones are Action and Func, both defined in the System namespace.

In this tutorial, you'll learn about the Action and Func delegates in C#.

To download the source code for this article, visit this GitHub Repository.

Let’s begin by discussing the Action delegate and exploring its usage

What is the Action Delegate in C#?

The Action delegate is a predefined delegate type that encapsulates a method with zero or more input parameters that doesn't return a value. In other words, an Action delegate represents a void-returning method.

Consider this example, demonstrating the usage of an Action delegate in a simple console calculator application:

Action<int, int> ActionCalculator = (a, b) =>
{
    Console.WriteLine($"Addition result: {a + b}");
    Console.WriteLine($"Subtraction result: {a - b}");
    Console.WriteLine($"Multiplication result: {a * b}");
    Console.WriteLine($"Division result: {a / b}");
};

ActionCalculator(4, 2);

In this example, we defined an Action delegate named ActionCalculator. It takes two integer parameters and performs four basic arithmetic operations using those parameters. Then, we invoke the delegate with the values 4 and 2.

The application produced the following output upon running:

Addition result: 6
Subtraction result: 2
Multiplication result: 8
Division result: 2

As you can see, utilizing an Action delegate simplifies the process of passing a method as a parameter to another method.

What is the Func Delegate in C#?

The Func delegate is another predefined delegate type that represents a method with zero or more input parameters that returns a value. Unlike the Action delegate, the return type of a Func delegate can be any type.

Let’s consider an example of using a Func delegate in a simple console calculator application.

In this example, we define a Calculator class:

public class Calculator
{
    public int Add(int a, int b) => a + b;
    public int Subtract(int a, int b) => a - b;
    public int Multiply(int a, int b) => a * b;
    public int Divide(int a, int b) => a / b;
}

The Calculator class contains methods to perform four basic arithmetic operations.

Next, we create four Func delegates, with each delegate pointing to one of the calculator’s methods:

var FuncCalculator = new Calculator();

Func<int, int, int> add = FuncCalculator.Add;
Func<int, int, int> subtract = FuncCalculator.Subtract;
Func<int, int, int> multiply = FuncCalculator.Multiply;
Func<int, int, int> divide = FuncCalculator.Divide;

Console.WriteLine($"Addition result: {add(4, 2)}");
Console.WriteLine($"Subtraction result: {subtract(4, 2)}");
Console.WriteLine($"Multiplication result: {multiply(4, 2)}");
Console.WriteLine($"Division result: {divide(4, 2)}");

Finally, we invoke each of the delegates with the values 4 and 2 and print the results to the console.

The calculator application displayed the following output upon running:

Addition result: 6
Subtraction result: 2
Multiplication result: 8
Division result: 2

Func delegates offer a straightforward approach to defining and utilising methods by passing them as parameters and returning them as results.

Conclusion

In conclusion, Action and Func delegates provide a way to encapsulate a method call within a delegate object.

Developers use Action delegates when a method does not return a value, and Func delegates when a method returns a value.

C# is a powerful language that has continued to evolve and transform the landscape of software development. If you are a programmer with some experience in C# and looking to deepen your knowledge, then you’ve come to the right place.

We just published an advanced C# course on the freeCodeCamp.org YouTube channel. The course was developed by Gavin Lon. Gavin is an experienced developer and freeCodeCamp team member.

The course curriculum is structured to ensure a seamless learning experience, as it covers an array of sophisticated C# topics that are essential for the modern developer.

Course Overview

1. Introduction and Course Overview: The course starts with an introduction and an overview to set the stage for the exciting learning journey ahead.
2. In-Depth Study of Delegates: The delegates section is an extensive exploration that lays the foundation for understanding the role and importance of delegates in C#. You will be exposed to practical examples, learn about the different types of delegates, and understand how asynchronous programming is realized through delegates.
3. Mastering Events in C#: Following delegates, the course tackles events in C#. This sections starts with an introduction to the intricacies of events and concludes by teaching how events integrate into design patterns like the Observer Pattern.
4. Unraveling Generics: Generics are powerful features in C# that are essential for type-safe code. This section takes you through the basic concepts, constraints in generics, and how delegates and events can be used with generics. It also covers how generics play a crucial role in design patterns.
5. Asynchronous Programming with Async/Await: Here, the course delves into asynchronous programming which is fundamental for writing efficient and responsive applications. You'll learn the best practices, how to manage tasks, and handle cancellations effectively.
6. Demystifying LINQ: The Language Integrated Query (LINQ) section gives you insights into querying data effectively. This part covers the different operators available, how to create queries, and efficiently utilize LINQ for data manipulation.
7. Attributes and Reflection in C#: Gavin explores how to use attributes in C# and how reflection allows you to inspect and interact with object metadata at runtime.
8. Journey through .NET: The course concludes with a focus on the evolution of the .NET framework, from .NET Core to the newer versions of .NET, giving you insights into the direction and future of C# and .NET technology.

With hands-on examples and best practices, this course will pay dividends in your journey as a C# developer. Watch the full course on the freeCodeCamp.org YouTube channel (15-hour watch).