Coder Legion - Recent posts tagged patterns

Platform Engineering’s patterns and anti-patterns

Tue, 17 Feb 2026 10:22:51 +0000

Platform Engineering has been around for a while. Interest recently accelerated, however, thanks to its relevance to DevOps.

For some, Platform Engineering solves a common DevOps Topologies’ problem: Embedding IT operations into DevOps teams that lack time and experience to do it well. This is an anti-pattern, also known as Anti-Type F.

Platform Engineering can help you scale the organization and reduce developer overload.

Use our Platform Engineering decision flow to find out if it’s the right solution to your problems. It also guides you to put key measurements in place early so you can track the value of your internal developer platform (IDP).

We describe the anti-patterns and positive patterns of Platform Engineering below. Let us know if you have a suggestion.

Platform Engineering anti-patterns

If familiar with Team Topologies, you’re less likely to use one of the common Platform Engineering anti-patterns. The library can still be a helpful way to describe problems to your colleagues when you find trouble.

Complex platforms

An IDP should reduce complexity and remove cognitive overload for developers. If the platform is too difficult to use, it failed at a crucial goal. There are several ways a platform can add to a developer’s burden:

It uses a configuration file format that isn’t familiar to the developer
APIs don’t have a consistent convention for methods and parameters
There’s no documentation
The platform doesn’t reduce developer pain

If you have configuration files as part of your platform, be flexible with the format. It should be trivial to parse the same data from a JSON file from web developers and a YAML or XML file from back-end teams. This means the developers can use a format familiar to them rather than one convenient to you.

When creating an API or command line interface (CLI), being meticulous and consistent with method names, parameter names, and the order of parameters can make it easier to use.

Your IDP documentation should be concise and clear, focusing on what’s available and how to use it.

Where developers don’t meet governance, risk, and compliance (GRC) objectives, adding a platform that handles these needs adds more load to development teams. Solving existing developer problems first allows you to solve external requirements without burdening developers.

If your IDP doesn’t significantly reduce developer cognitive overload, complexity, and burnout, it doesn’t work. It also fails if it transfers all the pain to the platform team.

”Field of dreams” platforms

In the 1989 movie Field of Dreams, a voice tells Ray Kinsella (Kevin Costner) that “If you build it, they will come.” In the film, building a baseball park in a cornfield reunites Kinsella with his father and produces a stream of fans coming to watch games at the farm.

If you take the same approach when building your internal developer platform, you’ll struggle to gain internal market share. You need to involve developers from the start and build a platform that solves their specific problems.

If you build the platform before talking to its potential customers, you find yourself with a product that doesn’t fit your market. Some symptoms include:

Poor technology fit: Making it easier to manage Kubernetes only to find developers moved to serverless functions.
Skill assumptions: Creating a simplified template for microservices only to find developers are microservice experts and don’t value your solution.
Forcing choices: Designing a platform with the latest and greatest technology and finding the business doesn’t want to move from stable solutions.

You can’t design your IDP on faith alone. You must talk to developers across many teams to find common pain points your platform could remove. Creating a platform in isolation guarantees low adoption rates.

The skill concentration trap

When you create a Platform Engineering team, you’ll likely add people with the most experience in areas the platform will cover. This can cause a problem when:

The platform team thinks they know better than the development teams
Development teams lose the knowledge they need to run their software
Development teams lose the people who could migrate them onto a platform

Suppose you move people from development teams to create a platform team. You need a strong succession plan and a greater focus on collaboration to upskill the development teams for self-service. You must ensure you don’t create a cognitive overload and burnout by removing skilled team members.

If people leaving the teams were the only ones who cared about operations, the remaining members might see little benefit to the platform. It would be a disaster if developers ignored operations tasks.

You may need to start your platform team with fewer people. You can then solve problems that make it easier for teams to release more people. Choosing platform team members on communication and collaboration skills, and not just technical knowledge, increases the chances of success.

Magpie platforms

People attracted to shiny objects are often called magpies. That’s because members of the crow family tend to take shiny objects belonging to their owners when kept in captivity. A magpie platform focuses on shiny new technologies and not solving problems developers face with existing systems.

Building a platform to support a greenfield project is attractive, but there are far better ways. You make more impact by helping teams with their existing production software.

You build a better platform for the new software once you can identify the areas where developers struggle. When a development team adopts new technology, it can look like they need help with everything. You should let them establish their knowledge for the actual pain points to emerge. Many of their early pains will disappear when they get used to the new tech.

You need to prove the platform’s impact, so a stable starting point is necessary for others to take your measurements seriously. Stakeholders may dismiss your improvements if they think it’s due to teams getting familiar with the technology and business domain.

Platforms must prove their impact on existing teams and the tech stacks they use. There will be many opportunities to merge technologies where teams solved a problem differently. Sometimes introducing a new tool for deployment or monitoring can remove pain from many teams at once. It’s crucial you can show the platform’s benefits.

Under-invested platforms

Once you’ve introduced a platform into your organization, it needs long-term investment to keep it usable. When a platform team disbands after delivering a product, the platform can become an anchor that adds drag to all who depend on it.

The context that led to the decisions you baked into the IDP platform can change, leaving teams stuck with old choices that no longer work. The platform will become so difficult to use that teams must migrate away from the platform to get their work done.

Platforms need to continually improve. You need to add new golden pathways and phase others out to ensure the platform continues to benefit the business.

You should limit the platform’s ambition to match the long-term investment levels.

Stretched platforms

If your organization has a fragmented technology landscape, it can be tempting to solve too many problems with the IDP. Suppose you support all existing tools and technology. In that case, the platform will become stretched too thin to be useful. Your platform team will be even more overloaded than the developers were.

A common cause of stretched platforms is measuring the platform team on internal market share. Adding more golden pathways is one way to increase market share, as the platform can help more teams. However, this defeats the goal of using the pathways to encourage consolidation around good technology choices.

MONK metrics can help balance market share with developer satisfaction and outcomes. This can help you avoid the problem of stretched platforms.

Other signs of trouble

Alongside common anti-patterns, you should watch for other signs of trouble. Common gaps can open when an IDP becomes available.

Self-service cost problems

When you make a platform with self-service options, you must ensure a strong story around how you track and control cost. If every developer spins up production-like environments, costs could rise out of control.

Any button that makes spending easy should include a feature to limit that spending automatically. This means test environments have short lifespans, and there’s a cap on concurrent environments.

There’s an opportunity for the platform team to bridge with the finance team on this subject.

General-purpose DevOps platforms

When platform decisions happen away from technical knowledge, there’s a temptation to try an all-in-one DevOps platform to solve all problems.

This doesn’t align with Platform Engineering or DevOps. If you buy a single general-purpose tool, you limit the platform’s capability and your continuous improvement abilities. The features of the tool constrain the solution for all problems.

Instead, you should design the platform as an internal product that solves specific pain points of development teams. Rather than opting for general-purpose tools, select best-in-class tools where you need them. You’re also likely to create reusable libraries that make it easier for developers to align with unified logging and telemetry design.

A golden pathway is not a tool, though it makes sense to increase the platform’s capability by leaning into specialist tools for builds, deployments, and monitoring.

Flexibility has two sharp handles

While platform teams aim to help development teams move towards a standard landscape, edge cases will always exist. A rigid platform will force development teams to exit and find alternatives. Talking with teams and listening for edge cases allows platform teams to counter edge cases and keep internal market share.

Equally, accommodating every scenario without any consolidation into golden pathways causes other problems. It could swamp the platform team with the complexity and cognitive load that Platform Engineering should remove. The best software products have a clear focus. They don’t try to do everything.

You should design the platform to allow teams to add edge cases without necessarily bringing the edge cases into support. Edge cases shouldn’t force people off the platform or increase the platform’s surface.

Don’t attempt to support every tech stack in the business. When you report on platform market share, highlight:

Total market size (all developers)
Size of the supported market (all developers using a tech stack supported by a golden path)
Market share (the number of developers using the platform)

The market share chart shows:

The total size of the internal developer market
How much of the market could use the internal developer platform
How many chose to do so.

You can use the chart to guide decisions for new golden pathways and track the platform’s appeal to its intended audience.

Platforms can’t solve culture

It’s easy to create a team. Building the interactions that make them successful is far more work. Team Topologies describe this using a combination of team and interaction modes.

If you create a platform team without paying attention to the design of interactions, it will fail.

Software delivery requires a high-trust, low-blame culture to succeed. Platform Engineering is no different. Culture is one of the biggest predictors of performance. Find out more about DevOps culture.

Building a platform isn’t a project. If you create an IDP, it must be a long-term strategy. When a platform is on-hold it limits the performance for all its users. This is worse than not creating a platform in the first place.

You need solid team design, clear interaction modes, and a platform as a product approach to build a good IDP.

How to do Platform Engineering well

Now you’ve seen many ways Platform Engineering can fail, it’s time to look at what success looks like.

In the Puppet State of Platform Engineering Report, 94% of respondents found the concept helped the organization realize the benefits of DevOps. If you have strong performance against the DORA Metrics, you’re likely to succeed with Platform Engineering too.

The internal developer platform is a product

The most critical sign of good Platform Engineering is that it’s run as a product. Developers are customers, and the platform should solve their problems to win internal market share.

If doing this well, you’ll have regular contact with developers, and measurable platform success criteria. If you have a product manager, the don’t only maintain a backlog. They should raise awareness of the platform and network with other departments to incorporate their needs. They help developers satisfy security, governance, risk, and compliance needs.

The platform needs a strong vision that inspires good decision-making. The platform shouldn’t support bad choices to gain internal market share. The product manager should capture decisions to refer to later on. It’s common for good decisions to get reversed when everyone’s forgotten the reason. A register of decisions can prevent mistakes.

By treating the platform as a product, you must ensure documentation quality stays high. High-quality documentation is crucial to product adoption.

Having a product-based approach and running a competitive product are vital signs of good Platform Engineering.

Use DevOps to build the platform

DevOps combines the following to increase software delivery performance:

Transformational leadership
Lean product management
Continuous Delivery
Organizational culture

The same capabilities will increase the likelihood of creating a valuable platform.

You don’t need to create a fully formed golden pathway immediately. Instead, solve 1 wide-reaching problem and iterate to success.

A typical pattern is to make it easy to:

Deploy common approved tech stacks
Provision infrastructure and create environments
Collect telemetry and error logs and track systems in Production

The underlying pattern is to find and abstract a complex area so the development team doesn’t get lost in the weeds. In some cases, an off-the-shelf tool will help with this. In other cases, the platform team might create a facade to simplify a tricky area.

The goal should be to start with the thinnest viable platform that supports developers where they most need it. It’s better to expand features slowly. Pick the areas with the most significant impact rather than trying to solve all problems.

For example, if your toolset has large JSON, YAML, and XML configuration sets, you could provide a unified format offering fewer options. Developers then only need to adjust 1 small file in a single format instead of many large files in different formats. You should provide considered default options for all the settings you don’t expose through the platform.

Another popular option is putting different tools and workflows behind a simple API for developers.

Make good build or buy decisions

Successful platform teams know when to build something from scratch and when to bring in a specific tool for the job. Many best-in-class tools for Continuous Integration, deployment automation, and monitoring offer features to the IDP.

It would be best to avoid general-purpose solutions that try to do everything, as they can become a limiting factor. A crucial platform capability is swapping out a tool without creating work for developers. Imagine changing your event logging tool. Without Platform Engineering, it may involve a list of applications to update and schedule many similar changes. The internal developer platform should lower the cost to change this by managing the swap behind the platform API.

No matter how you compose off-the-shelf and custom components, aim to:

Keep the developer in their preferred place, usually a text editor or IDE.
Make everything work seamlessly together
Provide snap-in solutions to common problems (authentication, logging, monitoring, for example)

A team that brings in specialized tools will create a more robust platform faster than when building everything from scratch.

Create the network

When developers adopt your platform, they should also become part of your customer network. The teams using the platform can help each other when they get stuck. Your long-term customers can share how they have used the platform to solve their problems. That can inspire other developers to adopt or extend their use of the IDP.

You can also create opportunities for different teams to discuss typical pain points the platform could solve.

Run like open source

Let the platform’s users contribute to it; they are all developers, after all! This is ‘inner sourcing.’

This means more than accepting code contributions. It also means you need to:

Publish contribution guidelines
Keep contribution documentation up to date
Think about how a suggested change may impact other customers

You can find more ideas at InnerSource Commons.

Keep an eye on progress

You need to track the platform’s impact to inform product management and ensure continued investment.

The MONK metrics are an excellent place to start. The MONK metrics are:

Market share
Onboarding time
Net Promoter Score (NPS)
Key customer metrics

Read more about the Platform Engineering MONK metrics.

Summary

There are several anti-patterns as well a strong pattern of successful Platform Engineering.

You’ll be more likely to succeed if you run the IDP as a product with lean product management techniques. You should capture the positive outcomes development teams achieve to encourage long-term funding from the organization.

Platform Engineering solves a particular set of problems. Team topologies provide many ways to design your team structures if Platform Engineering isn’t the right approach for you.

State Pattern: Transforming Objects Through Internal States

Wed, 07 May 2025 21:42:59 +0000

State Pattern: Transforming Objects Through Internal States

In software development, we often encounter objects whose behavior must change based on their internal state. Think of a document (draft, under review, published), an order (new, paid, shipped, delivered), or as we'll explore, a student moving through academic stages.

However, with the advancement of programming and the complexity of the problems we face, we discovered that every object has two types of attributes: "static attributes" and "state attributes," which will be the focus of our discussion now. Because these attributes have behavior and state rather than a fixed value, dealing with them can be complex. Changing an object's state may result in a change in its behavior. For example, a person's behavior when they were children differs from their behavior when they became adolescents, even though they remain the same "human."

Therefore, it was found preferable to isolate these attributes in an abstract interface. Within the abstract interface, there are functions known as "state functions," which cause states to change and are similar to rules. In some cases, they are called "state operator functions." Each state then executes these functions, but according to the implementation appropriate for that state.

When handled improperly, state-dependent behavior leads to complex, difficult-to-maintain code filled with conditional statements. The State Pattern offers an elegant solution to this problem.

What is the State Pattern?

The State Pattern allows an object to change its behavior when its internal state changes. The pattern makes the object appear to change its class by encapsulating state-specific behavior in separate state classes and eliminating complex conditional statements.

As defined by the Gang of Four, this pattern:

Encapsulates state-specific behavior in separate classes
Delegates state-specific behavior to the current state object
Allows for easy addition of new states with minimal changes to existing code

The Problem: Evolving Student States

Let's consider a concrete example: a Student class that handles different behaviors as the student progresses through exam preparation:

Preparing: Student is studying for the exam
ExamTaken: Student has taken the exam and is awaiting results
Passed: Student has passed and completed the course

Traditional Approach with Conditionals

Here's how this might be implemented traditionally:

public class Student {
    // State constants
    public static final int PREPARING = 0;
    public static final int EXAM_TAKEN = 1;
    public static final int PASSED = 2;

    private int state;
    private String name;

    public Student(String name) {
        this.name = name;
        // Initial state is PREPARING
        this.state = PREPARING;
    }

    public void study() {
        System.out.println(name + " is attempting to study.");

        if (state == PREPARING) {
            System.out.println("Studying harder to be prepared for the exam!");
        } else if (state == EXAM_TAKEN) {
            System.out.println("Already took the exam! Waiting for results...");
        } else if (state == PASSED) {
            System.out.println("Studying for the next course!");
        } else {
            System.out.println("Unknown state!");
        }
    }

    public void takeExam() {
        System.out.println(name + " is attempting to take the exam.");

        if (state == PREPARING) {
            System.out.println("Taking the exam now...");
            state = EXAM_TAKEN;
        } else if (state == EXAM_TAKEN) {
            System.out.println("Cannot take the exam again! Already taken.");
        } else if (state == PASSED) {
            System.out.println("Already passed this exam! Moving to next course.");
        } else {
            System.out.println("Unknown state!");
        }
    }

    public void receiveResults(boolean passed) {
        System.out.println(name + " is receiving exam results.");

        if (state == PREPARING) {
            System.out.println("Cannot receive results yet - haven't taken the exam!");
        } else if (state == EXAM_TAKEN) {
            System.out.println("Receiving exam results...");
            if (passed) {
                state = PASSED;
                System.out.println("Passed the exam!");
            } else {
                state = PREPARING;
                System.out.println("Failed the exam. Need to prepare again!");
            }
        } else if (state == PASSED) {
            System.out.println("Already received the results. Passed!");
        } else {
            System.out.println("Unknown state!");
        }
    }

    public String getStateName() {
        if (state == PREPARING) {
            return "Preparing for exam";
        } else if (state == EXAM_TAKEN) {
            return "Waiting for results";
        } else if (state == PASSED) {
            return "Passed the exam";
        } else {
            return "Unknown";
        }
    }

    @Override
    public String toString() {
        return name + " - Current state: " + getStateName();
    }
}

Problems with the Traditional Approach

This implementation has several issues:

Code Duplication: The same state checks are repeated in every method
Complex Conditionals: Each method contains multiple if-else branches
Scattered State Transitions: State changes are dispersed throughout the code
Poor Maintainability: Adding a new state requires modifying every method
Error Prone: Easy to miss updating a condition when adding states
Hard to Read: Understanding all possible state transitions is difficult
Violation of OCP: The class must be modified to add new states
Violation of SRP: The Student class is responsible for all state behaviors

The Solution: Applying the State Pattern

Instead of managing state transitions with conditionals, we can use the State Pattern to separate each state's behavior into its own class:

1. Define the State Interface

interface StudentState {
    void study(Student student);
    void takeExam(Student student);
    void receiveResults(Student student, boolean passed);
    String getStateName();
}

2. Implement Concrete States

class PreparingState implements StudentState {
    @Override
    public void study(Student student) {
        System.out.println("Studying harder to be prepared for the exam!");
    }

    @Override
    public void takeExam(Student student) {
        System.out.println("Taking the exam now...");
        student.setState(new ExamTakenState());
    }

    @Override
    public void receiveResults(Student student, boolean passed) {
        System.out.println("Cannot receive results yet - haven't taken the exam!");
    }

    @Override
    public String getStateName() {
        return "Preparing for exam";
    }
}

class ExamTakenState implements StudentState {
    @Override
    public void study(Student student) {
        System.out.println("Already took the exam! Waiting for results...");
    }

    @Override
    public void takeExam(Student student) {
        System.out.println("Cannot take the exam again! Already taken.");
    }

    @Override
    public void receiveResults(Student student, boolean passed) {
        System.out.println("Receiving exam results...");
        if (passed) {
            student.setState(new PassedState());
            System.out.println("Passed the exam!");
        } else {
            student.setState(new PreparingState());
            System.out.println("Failed the exam. Need to prepare again!");
        }
    }

    @Override
    public String getStateName() {
        return "Waiting for results";
    }
}

class PassedState implements StudentState {
    @Override
    public void study(Student student) {
        System.out.println("Studying for the next course!");
    }

    @Override
    public void takeExam(Student student) {
        System.out.println("Already passed this exam! Moving to next course.");
    }

    @Override
    public void receiveResults(Student student, boolean passed) {
        System.out.println("Already received the results. Passed!");
    }

    @Override
    public String getStateName() {
        return "Passed the exam";
    }
}

3. Refactor the Context Class

class Student {
    private StudentState state;
    private String name;

    public Student(String name) {
        this.name = name;
        // Initial state is Preparing
        this.state = new PreparingState();
    }

    public void setState(StudentState state) {
        this.state = state;
    }

    public void study() {
        System.out.println(name + " is attempting to study.");
        state.study(this);
    }

    public void takeExam() {
        System.out.println(name + " is attempting to take the exam.");
        state.takeExam(this);
    }

    public void receiveResults(boolean passed) {
        System.out.println(name + " is receiving exam results.");
        state.receiveResults(this, passed);
    }

    public String getStateName() {
        return state.getStateName();
    }

    @Override
    public String toString() {
        return name + " - Current state: " + state.getStateName();
    }
}

Benefits of the State Pattern

Clean Code: Eliminates messy conditionals
Maintainability: State-specific code is localized
Extensibility: New states can be added easily
Flexibility: States can be swapped at runtime
Testability: Each state can be tested in isolation
Readability: State transitions are explicit
Single Responsibility: Each state class has one purpose
Open-Closed Principle: Student class is closed for modification but open for extension

State Pattern vs. Strategy Pattern: Key Differences

The State and Strategy patterns share a similar structure but have different intents:

Aspect	Strategy Pattern	State Pattern
Intent	Defines a family of interchangeable algorithms	Changes object behavior when internal state changes
Control	Client code selects strategy	States often control transitions to other states
Relationship	Strategies typically independent	States often know about and reference each other
Example	Client decides duck's flying behavior	Student automatically changes own state

When to Use the State Pattern

The State Pattern is particularly useful when:

An object's behavior depends on its state
You have multiple operations with state-dependent behavior
State transitions follow well-defined rules
You need to eliminate complex conditional logic

It might be overkill when:

You have few states or simple transitions
States rarely change
State-specific behavior is minimal

Real-World Examples

The State Pattern appears in many modern frameworks and libraries:

XState: JavaScript library implementing formal state machines to manage complex UI state transitions
RxJava: Uses Observer pattern primarily but incorporates state management for asynchronous stream processing
Unidraw: Framework for graphical editors that employs state-like behavior for tool switching

Conclusion

The State Pattern is a powerful tool for managing complex state-dependent behavior. By encapsulating each state in its own class, you create code that's easier to understand, test, and extend. Next time you find yourself writing a growing number of state-checking conditionals, consider if the State Pattern might provide a more elegant solution.

This article is inspired by concepts from "Head First Design Patterns" by Eric Freeman & Elisabeth Robson and "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

The State Pattern

Fri, 17 Jan 2025 09:32:25 +0000

Understanding the State Pattern with Calculator

Introduction

The State Pattern allows an object to change its behavior dynamically based on its internal state. It’s a powerful design pattern for handling complex, state-dependent behavior in an organized and maintainable way.

In this article, we’ll explore the State Pattern by implementing a simple Calculator with multiple states.

Calculator State Example

1️⃣ State Interface
The State interface defines the contract that all concrete state classes must implement. It contains methods that represent the state-specific behavior.

public interface ICalculatorState {
    void EnterNumber(CalculatorContext context, int number);
    void PerformOperation(CalculatorContext context, string operation);
}

2️⃣ Concrete States
Concrete states implement the State interface. Each state encapsulates the behavior for a specific condition of the Context.

NumberState: Handles behavior when the calculator expects a number.

public class NumberState : ICalculatorState {
    public void EnterNumber(CalculatorContext context, int number) {
        context.CurrentValue = number;
        Console.WriteLine($"Number entered: {number}");
    }

    public void PerformOperation(CalculatorContext context, string operation) {
        Console.WriteLine("Operation not allowed in Number State.");
    }
}

OperationState: Handles behavior when the calculator performs an operation.

public class OperationState : ICalculatorState {
    public void EnterNumber(CalculatorContext context, int number) {
        context.SecondValue = number;
        Console.WriteLine($"Second number entered: {number}");
    }

public void PerformOperation(CalculatorContext context, string operation) {
        switch (operation) {
            case "+":
                context.Result = context.CurrentValue + context.SecondValue;
                break;
            case "-":
                context.Result = context.CurrentValue - context.SecondValue;
                break;
            default:
                Console.WriteLine("Unsupported operation.");
                return;
        }
        Console.WriteLine($"Operation performed: {context.Result}");
        context.SetState(new NumberState()); // Transition back to NumberState
    }
}

3️⃣ Context: The Context is the core class that ties everything together. It keeps track of the current state and delegates behavior to the current state object.

 public class CalculatorContext {
        private ICalculatorState _state;
        public int CurrentValue { get; set; }
        public int SecondValue { get; set; }
        public int Result { get; set; }
    
        public CalculatorContext() {
            _state = new NumberState(); // Start in the NumberState
        }
    
        public void SetState(ICalculatorState state) {
            _state = state;
        }
    
        public void EnterNumber(int number) {
            _state.EnterNumber(this, number);
        }
    
        public void PerformOperation(string operation) {
            _state.PerformOperation(this, operation);
        }
    }

4️⃣ Main Program
Here’s how it all comes together in the main program:

class Program {
    static void Main(string[] args) {
        CalculatorContext calculator = new CalculatorContext();

        calculator.EnterNumber(10);
        calculator.SetState(new OperationState());
        calculator.EnterNumber(20);
        calculator.PerformOperation("+");
    }
}

Output :

Number entered: 10
Second number entered: 20
Operation performed: 30

Real-World Applications of the State Pattern

ATM Machine: Handling Idle, Processing, and Dispensing states.

Media Player: Play, Pause, and Stop states.

Order Processing: Pending, Shipped, and Delivered states.

Traffic Light System: Red, Yellow, and Green states.

Common Pitfalls & Best Practices

✅ Best Practices

Keep states separate and self-contained.

Use Factory Patterns to manage state transitions dynamically.

Apply lazy initialization to avoid unnecessary memory usage.

⚠ Common Mistakes

Overcomplicating simple problems with the State Pattern.

Not handling undefined states, leading to unexpected behaviors.

Using too many states, which can make maintenance difficult.

Tip: When implementing the State Pattern, ensure that each state is responsible for handling only the behavior relevant to that state. This separation of concerns makes your code easier to manage, extend, and debug. Avoid embedding logic for multiple states within a single class, as it defeats the purpose of using this pattern.

Caution: Be cautious when transitioning between states to avoid unexpected behavior. If a state change is not handled correctly, the program may enter an undefined or incorrect state, leading to inconsistent results. Always validate transitions and ensure that states are switched appropriately based on the application’s logic.

Note: The State Pattern is particularly useful when an object’s behavior changes frequently based on its state. However, if the number of states grows significantly, consider using a state machine framework to prevent excessive complexity and redundant code.

✅ Conclusion

The State Pattern is an effective solution for managing state-dependent behavior in software applications. By encapsulating state-specific logic within individual classes, it promotes cleaner, modular, and maintainable code.

The Calculator example demonstrates how this pattern allows dynamic state transitions, ensuring the application behaves correctly as its state evolves. This approach is especially useful in scenarios requiring flexibility and extensibility, such as games, workflows, or applications with complex user interactions.

Coder Legion - Recent posts tagged patterns

Platform Engineering’s patterns and anti-patterns

Platform Engineering anti-patterns

Complex platforms

”Field of dreams” platforms

The skill concentration trap

Magpie platforms

Under-invested platforms

Stretched platforms

Other signs of trouble

Self-service cost problems

General-purpose DevOps platforms

Flexibility has two sharp handles

Platforms can’t solve culture

How to do Platform Engineering well

The internal developer platform is a product

Use DevOps to build the platform

Make good build or buy decisions

Create the network

Run like open source

Keep an eye on progress

Summary

State Pattern: Transforming Objects Through Internal States

State Pattern: Transforming Objects Through Internal States

What is the State Pattern?

The Problem: Evolving Student States

Traditional Approach with Conditionals

Problems with the Traditional Approach

The Solution: Applying the State Pattern

1. Define the State Interface

2. Implement Concrete States

3. Refactor the Context Class

Benefits of the State Pattern

State Pattern vs. Strategy Pattern: Key Differences

When to Use the State Pattern

Real-World Examples

Conclusion

The State Pattern

Understanding the State Pattern with Calculator

Introduction

Calculator State Example

Output :

Real-World Applications of the State Pattern

Common Pitfalls & Best Practices

✅ Best Practices

⚠ Common Mistakes

✅ Conclusion

References