DEV Community: cakoko

Open Closed Principle (OCP): Theory and Implementation in Swift

cakoko — Fri, 03 Apr 2026 11:35:40 +0000

Introduction to Open Close Principle

Open-Closed Principle (OCP) is one of the principles in SOLID that was popularized by Uncle Bob. The idea originally comes from Bertrand Meyer in Object-Oriented Software Construction (1988). In that book, Meyer defines this principle as:

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

What’s confusing about OCP

The first thing I got from the title of this principle was

we should try to predict how the code may grow from the start, so later it can be extended without modifying the existing code.

So in my head, open sounded like “prepare the code so it can be extended later,” and closed sounded like “once the code is written, it should not be modified anymore.” From that interpretation, I ended up thinking that we should predicting future changes from the beginning, creating extension points early (hole), and then extending the code through those “holes” instead of modifying the existing implementation.

I wrote an article about OCP that was published in 2023. At that time, I also did some research while writing it, and that made me think this interpretation was correct. Many articles and tutorials out there also explain it in a very similar way, so the misunderstanding can feel valid at first. But the more I code, the more confusing that way of thinking became. It is really hard to predict those things when we are just starting to write code. And when I failed to predict it correctly, I got that bad feeling, like I was breaking the principle just because I needed to modify the code. On the other hand, trying to make the right prediction from the start also gave me anxiety for making it wrong.

That confusion stayed with me for quite a while, until I started this series and tried to relearn this principle. And that is where I found an article with a comment that criticized the way the writer explained OCP. The writer basically explained it like how the old me used to understand it. The person in the comment then referenced another article written more than a decade ago, in 2013, by Jon Skeet. Here is the article: https://codeblog.jonskeet.uk/2013/03/15/the-open-closed-principle-in-review

Jon Skeet’s view about OCP

In his article, Jon Skeet explains that his issue is not really with the low-level design idea behind OCP. In fact, he says the lower-level explanation of what is good and bad in the design example is actually fine. His problem is more with the name and the high-level wording of the principle, because they do not explain the real idea clearly enough.

What I think is important from his article is, the more useful way to understand OCP is not to focus too much on the words open and closed, but to focus on how change in one part should not force other parts to keep changing too. Skeet highlights Craig Larman’s explanation that being “closed with respect to X” means that clients are not affected if X changes. Here, clients does not mean customers or end users. It means the other parts of the code that depend on that module, class, or interface.

He also points out that OCP is easier to understand when we stop thinking about just one module alone. In practice, this is usually about a relationship between pieces of code. There is one part that may change, and there is another part that depends on it. The goal is to design the boundary between them so that when the first part changes, the second part does not need to change every time as well.

One side contains the variation, and the other side depends on a stable contract so it does not need to know every concrete case.

That is also why Skeet finds another principle called Protected Variation is much clearer. The phrase he quotes is:

“Identify points of predicted variation and create a stable interface around them.”

I think this captures the idea much better, because it gives a more practical angle. First, try to see where variation is already visible, repeatedly requested, or naturally expected by the domain. Then, create a stable boundary around that part, so the rest of the code does not need to be affected by that change again and again.

But Skeet also doesn't make it sound easy. He points out that predicting variation is hard. If we predict too much, we can end up over-engineering. If we predict too little, we may still need to change a lot of code later or add a new interface after the fact.

So, for me, the most useful takeaway from his article is this:

a better way to see OCP is not as “never modify code again”, but as “find the parts that are likely to change, then design things so that those changes do not keep spreading to other parts of the system.”

Better Angle to See OCP / The Mental Model

From that perspective, the way I look at OCP now is slightly different from how I understood it before. It is not really about never modifying code again. In real software development, code will always change. Requirements change, new features appear, and old assumptions turn out to be wrong. Trying to completely avoid modification is unrealistic.

A more useful way to see OCP is to focus on the areas where variation is visible, likely, or meaningful enough to justify a stable boundary, and then design the system so that those changes do not keep forcing other parts of the system to change as well.

This does not mean we must predict every future change from the beginning. That would be hard and can easily lead to over-engineering. A more practical approach is to notice which part of the system is likely to keep changing, then place a stable boundary around that part so the rest of the code does not need to change every time too.

In many systems, some behaviors are more likely to evolve than others. For example, business rules may change, new payment methods may be added, or new output formats may be required. These are places where variation naturally appears.

Instead of letting those changes spread across many parts of the code, we try to isolate that variation behind a stable boundary. The parts we want to keep stable can then depend on that interface instead of depending directly on the concrete implementations behind it.

In many designs, one common way variation first appears is as repeatedly edited branching logic in one place. After refactoring, that variation can be moved behind a stable abstraction so new behavior is added without repeatedly editing that same part.

OCP is most useful when variation is meaningful and recurring, not when we are only imagining many future possibilities without evidence.

The more stable parts of the design stay relatively unchanged, while new behavior is added behind the same boundary.

So the mental model I use for OCP now is this:

Identify where change is likely to happen, isolate that variation, and design a stable boundary so the rest of the system does not need to change because of it.

Or in simpler questions:

Which behavior in this system is likely to vary?
Which parts of the system depend on that behavior?
Can I introduce a stable interface so those parts do not need to change every time the behavior evolves?

In the next section, we will look at a small example to see how this idea appears in actual code.

How OCP Looks in Code

Imagine we are building a checkout feature. The checkout flow needs to request a payment for an order. At first, the system only supports one payment provider, for example Stripe. Later, the business wants to add Xendit. After that, maybe another provider is added.

We can model the basic data like this:

enum PaymentProvider {
    case stripe
    case xendit
}

struct Order {
    let id: String
    let totalAmount: Decimal
    let currency: String
}

struct PaymentRequest {
    let orderId: String
    let amount: Decimal
    let currency: String
}

enum PaymentStatus {
    case success
    case failed
}

struct PaymentResult {
    let transactionId: String?
    let status: PaymentStatus
}

A common early implementation is to place both the provider selection and the provider-specific behavior inside the same checkout service

final class CheckoutService {
    func requestPayment(for order: Order, provider: PaymentProvider) async throws -> PaymentResult {
        let request = PaymentRequest(
            orderId: order.id,
            amount: order.totalAmount,
            currency: order.currency
        )

        switch provider {
        case .stripe:
            // Build Stripe-specific payload
            let providerResponse = /* call Stripe API */

            return PaymentResult(
                transactionId: providerResponse.transactionId,
                status: .success
            )

        case .xendit:
            // Build Xendit-specific payload
            let providerResponse = /* call Xendit API */

            return PaymentResult(
                transactionId: providerResponse.transactionId,
                status: .success
            )
        }
    }
}

Writer Note:
The problem is not the switch itself, but that CheckoutService becomes the place where provider variation accumulates

For now, this may still look good or acceptable. The service receives the order, checks the selected provider, and performs the payment. The problem appears when the system grows. Every time a new provider is added, the same CheckoutService must be modified again.

That means the checkout flow is doing two jobs at once:

coordinating the payment request flow
holding provider-specific integration logic

So the same class becomes the place where all provider variation keeps accumulating. This is the part that starts to violate the spirit of OCP.

The issue is not that the business requirement is wrong. The system still truly needs to use the selected provider. The issue is that the variation and the stable flow are both living inside the same class.

This is where OCP gives us a better direction. We still keep the same requirement, but we move the provider-specific behavior behind a stable abstraction.

First, we define a contract/abstraction for payment gateways

protocol PaymentGateway {
    var provider: PaymentProvider { get }
    func requestPayment(_ request: PaymentRequest) async throws -> PaymentResult
}

Then each provider can implement that contract in its own class:

final class StripePaymentGateway: PaymentGateway {
    let provider: PaymentProvider = .stripe

    func requestPayment(_ request: PaymentRequest) async throws -> PaymentResult {
        // Build Stripe-specific payload
        let providerResponse = /* call Stripe API */

        return PaymentResult(
            transactionId: providerResponse.transactionId,
            status: .success
        )
    }
}

final class XenditPaymentGateway: PaymentGateway {
    let provider: PaymentProvider = .xendit

    func requestPayment(_ request: PaymentRequest) async throws -> PaymentResult {
        // Build Xendit-specific payload
        let providerResponse = /* call Xendit API */

        return PaymentResult(
            transactionId: providerResponse.transactionId,
            status: .success
        )
    }
}

At this point, we still have the same business requirement as before

given an order and a selected provider, the system must use the correct provider to request payment.

So the goal is not to remove provider selection completely. The goal is to stop putting the selection and all provider-specific implementation details into one growing checkout service.

The Orchestration

After separating the provider-specific logic behind focused classes, we still need a way to coordinate them into one complete checkout flow. This is where orchestration comes in.

In this case, orchestration means one part of the code is responsible for:

receiving the order and selected provider
preparing the payment request
resolving the correct payment gateway
delegating the payment work

It does not take over the provider-specific responsibilities. Instead, it coordinates the flow while each concrete gateway handles its own integration details.

To support that flow, we first define a small abstraction for resolving the correct gateway.

protocol PaymentGatewayResolving {
    func resolve(for provider: PaymentProvider) throws -> PaymentGateway
}

This protocol gives the checkout flow a stable way to ask for the correct payment gateway. The checkout flow does not need to know whether the gateway comes from a dictionary, a factory, or some other setup. It only needs to know that, given a provider, it can get the correct PaymentGateway. After that we create implementation of it using registry.

enum PaymentGatewayResolverError: Error {
    case gatewayNotFound
}

final class PaymentGatewayRegistry: PaymentGatewayResolving {
    private let gateways: [PaymentProvider: PaymentGateway]

    init(gateways: [PaymentGateway]) {
        self.gateways = Dictionary(
            uniqueKeysWithValues: gateways.map { ($0.provider, $0) }
        )
    }

    func resolve(for provider: PaymentProvider) throws -> PaymentGateway {
        guard let gateway = gateways[provider] else {
            throw PaymentGatewayResolverError.gatewayNotFound
        }
        return gateway
    }
}

The responsibility of choosing the correct gateway is still present, but it is no longer mixed with provider-specific payment behavior inside the same service. PaymentGatewayRegistry stores the configured gateways and returns the correct one based on the provider. Its responsibility is to manage gateway lookup over the registered implementations. It doesn't build payment requests, it doesn't call external APIs, and it doesn't coordinate checkout. That is why this class stays focused.

The resolver needs to know which gateway implementations are available. A simplified setup can register them like this:

let gateways: [PaymentGateway] = [
    StripePaymentGateway(),
    XenditPaymentGateway()
]

let gatewayRegistry = PaymentGatewayRegistry(gateways: gateways)

This setup shows that the available gateway implementations are registered once, then made available through the registry. If a new provider is added later, we add a new PaymentGateway implementation and register it here. In this simplified example, the PaymentProvider enum also still needs to be updated. The important point is that the checkout flow itself no longer needs to accumulate provider-specific branches.

So in this example, OCP does not eliminate modification from the whole system. It mainly prevents CheckoutService from being the place that keeps changing.

With that in place, CheckoutService can focus on the business flow itself.

final class CheckoutService {
    private let gatewayResolver: PaymentGatewayResolving

    init(gatewayResolver: PaymentGatewayResolving) {
        self.gatewayResolver = gatewayResolver
    }

    func requestPayment(for order: Order, provider: PaymentProvider) async throws -> PaymentResult {
        let request = PaymentRequest(
            orderId: order.id,
            amount: order.totalAmount,
            currency: order.currency
        )

        let gateway = try gatewayResolver.resolve(for: provider)
        return try await gateway.requestPayment(request)
    }
}

Now the checkout flow no longer depends directly on concrete provider-specific integration logic. Instead, it depends on abstractions that separate the stable checkout flow from provider-specific behavior.

This is still the same use case as the original version.

The checkout flow still:

receives the order
receives the selected provider
builds the payment request
uses the correct provider
returns a payment result

The difference is in where the responsibilities now live.

Before

CheckoutService:

selected the provider
contained Stripe logic
contained Xendit logic
kept growing as variation increased

After

CheckoutService:

coordinates the checkout payment flow
asks another component to resolve the correct gateway
delegates provider-specific work to the gateway
remains relatively stable as new providers are added

StripePaymentGateway and XenditPaymentGateway:

own their own integration logic

PaymentGatewayRegistry:

knows how to find the correct gateway for a provider

That is the key improvement.

In the original version, the switch both selected the provider and contained the provider-specific implementation logic. In the refactored version, the checkout flow still works with the same provider selection requirement, but the implementation logic has been moved behind stable abstractions.

In this example, the OCP improvement is this:

instead of handling variation by repeatedly modifying the same branching logic, we handle it by adding new implementations behind a stable abstraction.

In other cases, OCP may look different. The variation might be moved into configuration, separate rule objects, plugins, handlers, factories, or another module boundary. So the point is not that OCP always means replacing switch with protocols. The point is to separate the part that changes, so the stable part does not need to be modified again and again.

What is being protected here?

In this example, the variation is the payment provider integration. The more stable part is the checkout flow that needs to request a payment for an order.

By introducing PaymentGateway, the checkout flow no longer needs to know how each provider behaves internally. By introducing PaymentGatewayResolving, CheckoutService no longer needs to know how the provider lookup is implemented.

So the business flow stays the same, but the provider-specific variation no longer keeps spreading into the same service.

Is this “true OCP”?

In my POV, this is a good practical OCP improvement.

It does not mean nothing in the whole system ever changes again. For example:

a new provider may still require a new PaymentGateway implementation
the PaymentProvider enum may still need to be updated
the list of registered gateways may still need to be updated That is okay.

The point of OCP here is that the stable checkout flow is no longer the place that must keep accumulating provider-specific branches and logic every time the variation grows. The modifications are reduced and pushed toward the variation side of the design instead.

This is only a simplified example to show the OCP boundary clearly. In a real system, the resolver may be backed by a registry, dependency injection setup, or some other composition mechanism. Those details are omitted here so the example can stay focused on the main design change, the provider variation has been moved behind a stable boundary.

Final note:

OCP here does not remove modification completely. It moves most of the modification pressure away from the stable checkout flow and toward the variation side of the design.

From the Writer

Hello, allow me to introduce myself. I’m Cakoko. We’ve reached the end of this article, and I sincerely thank you for taking the time to read it.

If you have any questions or feedback, feel free to reach out to me directly via email at cakoko.dev@gmail.com. I’m more than happy to hear your thoughts, whether they are about my English writing, the technical ideas in this article, or anything I may have misunderstood. Your feedback will help me grow.

I look forward to connecting with you in future articles. Btw, I’m a mobile developer, final year Computer Science student, and an Apple Developer Academy @ IL graduate. I’m also open to various opportunities such as collaborations, internships, or full-time positions. It would make me very happy to explore those possibilities.

Until next time, stay curious and keep learning.

Open for Feedback

This article is part of my personal learning journey. It may not be completely accurate or perfect, and that is okay. I’m sharing what I’ve learned so far in the hope that it can also help others who are exploring similar topics.

If you have any feedback, suggestions, or corrections, I would truly appreciate them. I’m always open to learning more and improving along the way.

Single Responsibility Principle (SRP): Theory and Implementation in Swift

cakoko — Sun, 29 Mar 2026 03:56:02 +0000

What is Single Responsibility Principle

SRP, or Single Responsibility Principle, states that a class should have only one reason to change. In other words, the class should represent one cohesive responsibility. If a class changes for multiple unrelated reasons, it is likely handling more than one responsibility.

When unrelated responsibilities are mixed in one class, the class becomes less cohesive. A change for one concern can affect code that serves another concern, which makes the class harder to test, maintain, and modify safely.

Mental Model

The mental model of SRP is to think about

how many reasons a class has to change.

Another way to think about it is to ask:

How many kinds of changes could be requested for this class?
How many sources of change affect this class?

In Uncle Bob’s explanation here Uncle Bob SOLID principles, these sources of change are often described in terms of different actors. An actor represents a person or group that interacts with the system and may request changes, such as business stakeholders, UI designers, database engineers, or other teams. This is a useful lens, because different actors often introduce different kinds of change. However, the deeper idea is still the same: a class should not be pulled by multiple unrelated reasons to change.

If a class needs to respond to requests from multiple unrelated actors, that can be a sign that the class is handling multiple responsibilities. Each actor may request changes for different reasons, which can cause the class to change in unrelated ways.

Because of that, a class should ideally serve one cohesive source of change. In many cases, that also means it mainly serves one actor, or one closely related group of actors.

A class is cohesive when its methods naturally belong together and tend to change together for the same reason.

Difference between SoC (Separation of Concern)

Since some of you may have come to this article from my series What I’m Learning About Writing Better Structured Code: A Learning Series may have already read about Seeing the problem: An Introduction to Separation of Concerns , you might be wondering what the difference is between SRP and SoC. This section is only a quick explanation of the difference. I will write another article about it later.

The difference is that SoC is a broader idea, while SRP is a more specific design principle.

Separation of Concerns is about separating different kinds of work in a system, so each part focuses on its own concern. For example, UI rendering, business logic, networking, and data storage are different concerns, and we usually try to keep them separated.

The Single Responsibility Principle is more specific. It helps us judge whether a particular unit, such as a class, forms one cohesive responsibility and has one reason to change, while SoC is a broader way of thinking about separating different kinds of work across a system.

So they are related, but they are not exactly the same. SoC helps us think about separating different concerns in general, while SRP helps us judge whether a specific class or unit is trying to handle too much.

OOP missconception.

lets look at this class as an example.

class PayslipProcessor {

    func calculateNetSalary(for employee: Employee) { ... }

    func generatePayslipContent(for employee: Employee)  { ... }

    func sendPayslip(to employee: Employee)  { ... }

}

This class may look fine right? Its a PayslipProcessor object, and all of its functions seem related to processing payslips.

I used to think like that too. Maybe one of the reasons is because that is how OOP (Object Oriented Programming) is often introduced in college and in many tutorials. A class is usually explained as a representation of a real-world object. Because of that, it's easy to think, “If this is a payslip processor object, then it makes sense if it contains all functions related to payslip processing”.

And if we continue with that way of thinking, it can still sound reasonable. In real life, someone in payroll might calculate salary, prepare the payslip content, and send it to the employee. So from that pov, putting all of those functions into one class can feel correct. But this is where the problem starts. The mistake is that we group things based on the fact that they look related on the surface. Yes, they are all related to payslip processing. But that does not automatically mean they are the same responsibility.

These are separate responsibilities not simply because they are different actions, but because they are affected by different kinds of changes. Salary calculation changes when payroll rules change. Payslip content changes when content or compliance requirements change. Payslip delivery changes when the delivery mechanism or integration changes.

This is why thinking about a class only as a real-world object is sometimes not enough. It can push us to put too many responsibilities into one class just because they look like they belong together. That is why SRP gives us a better way to judge it.

Instead of only asking,

“Does this function belong to this object?”

we should also ask

“How many reasons does this class have to change?”

Implementing SRP

So how do we actually implement SRP?

The main idea is not to split a class just because it has many methods, or because the file looks long. That can happen, but that is not the real point.

The real point is to look at a class and ask:

How many kinds of changes could be requested for this class?
How many sources of change affect this class?

Let’s go back to the previous example:

class PayslipProcessor {

    func calculateNetSalary(for employee: Employee) { ... }

    func generatePayslipContent(for employee: Employee)  { ... }

    func sendPayslip(to employee: Employee)  { ... }

}

At first, this class looks good because everything is still about payslips. But if we inspect it using the SRP mental model, we can see that the class is being pulled by different kinds of changes.

The salary calculation can change when payroll rules change. Maybe finance changes the overtime rule, tax rule, or deduction formula.
The payslip content can change when HR or compliance requests a different format, adds a required field, or changes the wording.
The delivery requirements can change. For example, the payslip may need to be emailed, uploaded to another system, or sent through a different channel.

These changes do not come from the same reason. They may all happen in the same feature area, but they are still different responsibilities. That is the important part. SRP is not telling us to split code randomly. It is telling us to separate parts that change for different reasons.

So instead of keeping all of those things inside one class, we can separate them by responsibility:

class SalaryCalculator {
    func calculateNetSalary(for employee: Employee) { ... }
}

class PayslipContentGenerator {
    func generatePayslipContent(for employee: Employee) { ... }
}

class PayslipSender {
    func sendPayslip(to employee: Employee) { ... }
}

This is one possible way to create clearer responsibility boundaries. In a real system, the exact split may vary depending on how the domain and workflow are designed, but the main idea stays the same:

separate parts that change for different reasons.

The exact responsibility boundary is often contextual. What matters is not following a fixed pattern, but identifying which parts of the code change together and which change independently.

Now each class has a more focused reason to change.

If payroll rules change, we know the first class is the one that should be affected.
If the payslip content changes, we know the second class is the one that should be affected.
If the delivery mechanism changes, we know the third class is the one that should be affected.

That is a much better boundary. And that is the core of implementing SRP:

we separate code based on different sources of change, not just based on whether functions look related at a glance.

This is also why SRP is not just about making classes small. A class can still have multiple methods and still follow SRP, as long as those methods support the same responsibility and are affected by the same kind of change. Different methods or steps do not automatically mean different responsibilities. If they always change together for the same reason, they may still belong in the same class.

The Orchestration

After separating responsibilities into focused classes, we still need a way to coordinate them into one complete workflow. This is where orchestration comes in.

Orchestration means one part of the code is responsible for managing the flow between these smaller classes. It does not take over their responsibilities. Instead, it calls them in the right order to complete one use case.

A simplified example might look like this:

class PayslipService {
    let salaryCalculator: SalaryCalculator
    let contentGenerator: PayslipContentGenerator
    let sender: PayslipSender

    init(
        salaryCalculator: SalaryCalculator,
        contentGenerator: PayslipContentGenerator,
        sender: PayslipSender
    ) {
        self.salaryCalculator = salaryCalculator
        self.contentGenerator = contentGenerator
        self.sender = sender
    }

    func processPayslip(for employee: Employee) {
        let salary = salaryCalculator.calculateNetSalary(for: employee)
        let content = contentGenerator.generatePayslipContent(for: employee)
        sender.sendPayslip(to: employee)
    }
}

The important point is that PayslipService coordinates the workflow, but the responsibility of calculation, content generation, and delivery still stays in their own classes.

This is only a simplified example to show the role of orchestration. In a real system, the design can be improved further depending on the architecture and the complexity of the workflow. I will cover that in another article in this SOLID series.

From the Writer

Hello, allow me to introduce myself. I’m Cakoko. We’ve reached the end of this article, and I sincerely thank you for taking the time to read it.

Until next time, stay curious and keep learning.

Open for Feedback

If you have any feedback, suggestions, or corrections, I would truly appreciate them. I’m always open to learning more and improving along the way.

SOLID Principle: Theory and Implementation in Swift

cakoko — Sun, 29 Mar 2026 03:53:26 +0000

This is a series about the SOLID principles introduced by Uncle Bob (Robert C. Martin). SOLID is a set of design principles that help us write code that is easier to understand, maintain, and evolve over time.

SOLID consists of five principles:

S - Single Responsibility Principle
- read here : https://dev.to/cakoko/single-responsibility-principle-srp-theory-and-implementation-in-swift-3f83
O - Open Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

Each of these principles tries to solve a different kind of design problem, but they all share the same goal:

helping us write code that stays manageable as the system grows.

Why I’m Writing This Series

This article series is created while I’m working on my other series:

What I’m Learning About Writing Better Structured Code

While writing that series, I realized something. Many of the ideas I want to explain are closely related to SOLID. But explaining them properly requires a deeper discussion about these principles themselves.

So instead of trying to squeeze everything into that series, I decided to write a more focused set of articles about SOLID. Later, I can reference these articles whenever the topic appears again.

A Small Personal Story

This series is also a bit personal for me.

Around three years ago, I wrote two article series on Medium about SOLID:

Looking back at them now, I can see that some parts were weak, some parts were missing important context, and some parts were simply wrong.

But honestly, that realization is actually the fun part. It means that over the past few years I’ve gone through a lot of learn, unlearn, and relearn moments. When I read those old articles now, I can clearly see how surface-level my understanding was back then.

And that also means I’ve improved.

This series is my attempt to revisit SOLID again, with a clearer understanding and better explanations.

Judging the Problem: Code Smells and Refactoring

cakoko — Wed, 25 Mar 2026 11:46:01 +0000

Introduction

After learning about Separation of Concerns, how to see a problem, and how to start separating it in the first article, now we move to the next step, learning how to judge the problem.

Once we can identify structural problems in code, the next question is not just what the problems are, but which ones need more attention. Which problems should be solved as soon as possible, and which ones are still good enough for the current context?

The main difference from the previous article is that the question is no longer just:

what concerns exist in this code?

but now becomes:

where is the code structure starting to become unhealthy?

This part is about learning how to look at working code and ask:

what kind of structural issue is happening here?
how serious is it?
what should be refactored first?
what is a real problem, and what is only a smaller imperfection?

We will learn about code smells that can be identified in code. But you need to remember its not about memorizing famous smell names. Its about learning how to judge structural risk.

What is Code Smell

Based on GeeksforGeeks article about Code Smells, The term code smell was first introduced by *Kent Beck* , an American Software Engineer and the creator of extreme programming. When we work on an application and write codes for it, we see a few patterns that are needed to be refactored. Those patterns either duplicates, or complicates, or might make code dependent on other code. Such patterns are called Code Smells and detection of such code is called Code Smelling.

So in simple terms, a code smell is a sign that something in the code structure may cause problems later, even if the code still works right now.

So smells are more like:

warnings
indicators
structural pressure points

This will help a question that came from first article

If this code grows, where will changes become more expensive than they should be?

There are many categories of code smells. Some of the main categories are Bloaters, Object-Orientation Abusers, Change Preventers, Dispensables, and Couplers. Each of these categories has its own examples. For instance, Bloaters include Long Method, Large Class, Primitive Obsession, Long Parameter List, and Data Clumps. You can read the more detailed explanation of each category on the Refactoring Guru website

To make them easier to remember, I asked ChatGPT to create a simplified version for me. After reviewing it, I think it is close enough to summarize the actual list above. So for this article, here are the code smell categories that I will use:

poor boundaries
fragile change points
duplication
shotgun surgery
large function / mixed responsibility
god object
feature envy

Code Smell Category

Poor boundaries

Poor boundaries happen when different responsibilities are placed too close together, or when it is not clear where one responsibility should stop and another should begin. This usually makes the code harder to understand because input/output, state changes, business logic, and flow control start mixing in the same place. In simple terms, poor boundaries mean the code has weak separation between jobs that should be clearer.

Fragile change points

Fragile change points are parts of the code where even a small change feels risky. A simple update can accidentally affect other behavior because the code is too tightly connected, too unclear, or too overloaded with responsibility. This smell matters because it shows where the code is starting to resist change, even if it still works today.

Duplication

Duplication happens when the same logic, structure, or decision appears in more than one place. This is not only about identical lines of code. It can also mean repeating the same idea in slightly different forms. Duplication becomes a problem because when the rule changes, we may need to remember to update it in multiple places, and it becomes easy for those places to drift apart.

Shotgun surgery

Shotgun surgery happens when one small change forces us to edit many different parts of the codebase. Instead of changing one clear owner, we have to “shoot” changes across multiple files, functions, or objects. This is a strong sign that responsibility ownership is weak, because one concern is spread too widely.

Large function / mixed responsibility

A large function is not bad just because it is long. It becomes a smell when that function starts doing many unrelated jobs at once. This usually means user input, validation, business logic, state mutation, output rendering, or flow control are all being handled together. The real problem is not the size alone, but the mixed responsibility inside it.

God object

A god object is an object that knows too much, owns too much, or controls too much. Instead of having one focused responsibility, it becomes the place where many unrelated concerns gather. This kind of object often becomes a central dependency in the system, which makes the code harder to understand, harder to test, and harder to change safely.

Feature envy

Feature envy happens when a function seems more interested in another object’s data than its own. Instead of using its own responsibility well, it keeps reaching into another object and doing work that probably belongs there. This is usually a sign that behavior is living in the wrong place, and that the ownership of logic may need to be reconsidered.

Code Smell Severity

Smell severity is about how serious a code smell is in a specific codebase and context.

There are many ways to rate smell severity. A lot of research has explored this, including work that uses machine learning to detect and evaluate code smells. Different approaches may use different criteria and scales. But for this article, I will use a simpler rating system:

weak
medium
strong

Smell severity is basically about this question:

How serious is this issue in this specific codebase?

The important point is that a code smell category and its severity are not the same thing. A smell may exist, but its severity can still be weak, medium, or strong depending on the context. This means:

Not every true smell is automatically a strong smell.

Writer note:

Here is some research about it:
https://www.sciencedirect.com/science/article/abs/pii/S0950705117301880, https://www.sciencedirect.com/science/article/abs/pii/S0957417424003488, https://sol.sbc.org.br/index.php/sbes/article/view/30345
You can find more using this keyword: code smell severity, code smell prioritization, code smell risk assessment, code smell severity classification, machine learning for code smell severity

Understanding Smell Severity More

When I first tried to understand this concept, I was confused about how to actually judge the code and give a rating. If I found one issue here and another issue there, should I rate both as strong just because both are real smells? That part confused me a lot.

After doing more research and discussing it with GPT, I understood the idea better when I tested it with a simple comparison.

For example, using Bahasa Indonesia for variable names in a codebase can be a real issue. It can reduce readability, especially if the team expects one shared language. But now compare that with a public function that can mutate the database in a dangerous way. Both are still valid problems, yet they clearly do not have the same severity.

That comparison helped me see the difference more clearly. The first issue may still count as a smell, but in that context it feels weak or mild. The second one is much more serious because the risk and impact are much higher.

This made me realize an important point:

smell presence and smell severity are different judgments

In other words, recognizing that a smell exists is only the first step. After that, I still need to judge how serious it is in the current codebase. That usually means comparing things like:

risk
impact
centrality
future damage

And those depend on the context, such as:

the size of the app
how often the smell appears
how central that code is
how much future pain it may create
whether it is the main structural problem or just a side issue

It also means comparing one smell against the other smells in the same codebase, not judging it in isolation.

That was the point where the whole idea of smell severity started to make much more sense to me.

Smell Classification for ToDo App

We will still use this base code from previous article. Try to classify the smell category and its severity for this code by yourself before see my answer.

import Foundation

struct TodoItem {
    var title: String
    var isDone: Bool
}

var todos: [TodoItem] = []

func showMenu() {
    print("")
    print("=== Todo App ===")
    print("1. Show all todos")
    print("2. Add todo")
    print("3. Toggle todo")
    print("4. Remove todo")
    print("5. Exit")
    print("Choose:")
}

func showTodos() {
    if todos.isEmpty {
        print("No todos yet.")
        return
    }

    for (index, todo) in todos.enumerated() {
        let mark = todo.isDone ? "[x]" : "[ ]"
        print("\(index + 1). \(mark) \(todo.title)")
    }
}

func addTodo() {
    print("Enter todo title:")
    if let input = readLine(), !input.trimmingCharacters(in: .whitespaces).isEmpty {
        todos.append(TodoItem(title: input, isDone: false))
        print("Todo added.")
    } else {
        print("Invalid title.")
    }
}

func toggleTodo() {
    showTodos()

    if todos.isEmpty {
        return
    }

    print("Enter todo number to toggle:")
    if let input = readLine(), let number = Int(input) {
        let index = number - 1

        if index >= 0 && index < todos.count {
            todos[index].isDone.toggle()
            print("Todo updated.")
        } else {
            print("Invalid number.")
        }
    } else {
        print("Please enter a valid number.")
    }
}

func removeTodo() {
    showTodos()

    if todos.isEmpty {
        return
    }

    print("Enter todo number to remove:")
    if let input = readLine(), let number = Int(input) {
        let index = number - 1

        if index >= 0 && index < todos.count {
            let removed = todos.remove(at: index)
            print("Removed: \(removed.title)")
        } else {
            print("Invalid number.")
        }
    } else {
        print("Please enter a valid number.")
    }
}

func runApp() {
    var isRunning = true

    while isRunning {
        showMenu()

        let choice = readLine() ?? ""

        switch choice {
        case "1":
            showTodos()
        case "2":
            addTodo()
        case "3":
            toggleTodo()
        case "4":
            removeTodo()
        case "5":
            isRunning = false
            print("Goodbye.")
        default:
            print("Unknown option.")
        }
    }
}

runApp()

Smell Classification Answer

Before giving the classification, I want to repeat one important thing, this is not about memorizing famous smell names and forcing every codebase into them. The goal is to judge structural risk in context. A smell may be real, but its severity still depends on how central it is, how much damage it can create, and how strongly it affects change in the current codebase.

From my perspective, this is the smell classification I ended up with for the Todo app above.

Poor boundaries : strong

I identified poor boundaries as a strong smell.

My reasoning connects directly to the first article. In Module 1, I used boundaries such as input/output, state, data, app flow, and business logic as the main lens for reading the code. In this Todo app, functions like addTodo(), toggleTodo(), and removeTodo() mix several of those together in the same place.

For example, addTodo() mixes:

input
output
state mutation
todo-related logic/business logic

That means the function does not have clear responsibility boundaries.

The important refinement here is that this smell is not strong just because “there are many things inside one function”. It is strong because those responsibilities can change for different reasons. The UI text may change. The input mechanism may change. The todo rules may change. Those should not all force edits in the same function. That is why poor boundaries is a real strong smell here.

Fragile change points : strong

I also identified fragile change points as strong.

One example that helped me see this was imagining a model change. If I add something like priority to TodoItem, that could force changes to:

object creation
input flow
output display
maybe sorting or filtering later

I also connected this to changing the medium of the app itself, for example moving from a CLI app to a graphical UI. Because input and output are mixed directly into the logic, changing the interface would be more painful than it should be.

The important refinement here is that the model changing is not bad by itself. The pain happens because that change ripples into multiple mixed places. That is why fragile change points are strong in this codebase: one concept change can leak through many parts of the current structure.

Duplication : medium

I noticed duplication in:

repeated empty checking
repeated input validation
the repeated overall shape between toggleTodo() and removeTodo()

At first, I was unsure whether duplication might actually be strong, because repeated validation across multiple places can create real pain if I forget to update one of them. But after re thinking the severity, I think that the duplication here is medium.

Why not strong? Because the larger structural problems in this codebase are still:

poor boundaries
mixed responsibilities
weak ownership

So duplication definitely exists, but it is not the most central problem yet.

One important lesson I got from this is that duplication is not only about copy-paste text. It can also appear as duplicated control-flow shape. That helped me see the smell more broadly.

Shotgun surgery : medium

I understood shotgun surgery as one conceptual change forcing many small edits across multiple places.

I connected this to things like:

model changes
validation changes
input flow changes

The smell is present, but in this app I would rate it as medium, not strong.

The reason is contextual. The app is still small, so the edit points are visible and manageable. The conditions for shotgun surgery already exist, but they have not exploded yet. So the smell is real, but at this stage it looks more like a visible structural risk than the most dominant pain point.

This was a useful reminder that smell severity always depends on context.

Writer Note:

Shotgun surgery is related to fragile change points, but they are not the same. Fragile change points focus on how risky and unstable a change location already is, while shotgun surgery focuses on how widely one conceptual change must spread across the code. In this Todo app, the core functions are already fragile because they mix multiple responsibilities, which is why fragile change points can be rated strong. But the codebase is still small, so although one change may spread to several functions, that spread is still limited and manageable. That is why shotgun surgery is better rated as medium here, not strong.

Large function / mixed responsibility : strong

This was one of the most important corrections for me.

At first, I thought the functions were not very large by line count, so maybe the smell was only mild. But that turned out to be the wrong lens.
The key lesson here was:

line count is not the main issue
responsibility load is

Even though addTodo(), toggleTodo(), and removeTodo() are still short functions, they mix:

output and prompting
input
validation
mutation
feedback

So the real smell is not “large function” in a superficial line-count sense. The real smell is mixed responsibility, and that is strongly present.

This was an important calibration point for me, because it connects to a recurring weakness from Module 1 too: I sometimes underestimate mixed responsibility when the function is still short. After correcting that, I now rate this smell as strong.

God object : weak / not really present

I rated god object as weak or not really present.

The reason is simple, this app is still too small to honestly call anything a god object. There is no single giant object that owns everything in a meaningful object-oriented sense. The bigger problems here are still poor boundaries and mixed responsibilities.

Feature envy : weak / not really present

I also rated feature envy as weak or not really present.

Again, the reason is that this is not the main pattern in the current structure. The app is too small, and the code is not interacting in a way that makes feature envy the most useful label.

Create Refactoring Plan

After identifying the smells and their severity, we can start creating a refactoring plan based on which problems matter most. Let me ask you first: what do you think should be the first priority? Try answering that in your own mind, along with the reasoning behind it.

For me, the first priority is poor boundaries. The reason is that this is the smell most closely connected to the deeper structural problem in the Todo app. Input, output, state mutation, and business logic are still too mixed together. As long as those boundaries remain unclear, other problems like fragile change points and duplication will keep appearing more easily.

Because of that, my first refactor direction was to create a store that holds state and business logic.

The idea is to introduce something like this:

final class TodoStore {
    private var todos: [TodoItem] = []

    var items: [TodoItem] {
        todos
    }

    func addTodo(title: String) throws {

    }

    func toggleTodo(at index: Int) throws {

    }

    func removeTodo(at index: Int) throws -> TodoItem {

    }
}

This felt like a good first move because it:

gives state a clearer owner
centralizes mutation
separates todo-related logic from input/output
reduces ripple effects
makes future changes safer

So this became the first refactor direction I chose.

How to refactor?

If this part feels a little jumpy because I suddenly introduced TodoStore and showed the code without walking through the full refactoring process, that is completely fair.

I will cover the actual refactoring process in the next article of this series (What I’m Learning About Writing Better Structured Code). The next article is “Guide to Solve the Problem: Introduction to SOLID Principles.” In that article, I will focus more on how I gradually moved from the original Todo app into a structure with clearer ownership, better boundaries, and more focused responsibilities, using the SOLID principles as a guide.

From the Writer

Hello, allow me to introduce myself. I’m Cakoko. We’ve reached the end of this article, and I sincerely thank you for taking the time to read it.

Until next time, stay curious and keep learning.

Open for Feedback

If you have any feedback, suggestions, or corrections, I would truly appreciate them. I’m always open to learning more and improving along the way.

Seeing the problem: An Introduction to Separation of Concerns

cakoko — Tue, 24 Mar 2026 04:14:08 +0000

Separation of concerns is one of the first topics that comes up when we want to move from writing code that simply works to writing code that is structured well. At first, I thought it only meant splitting code into smaller functions so it looked cleaner, was easier to reuse, and had less duplication. If a function looked too long, I would cut some lines out and move them into another function. If a piece of code looked too complex, I would do the same.

For years, I wrote code mostly based on instinct and personal preference without really asking whether there was a better way to think about structure. I did not seriously question where a responsibility should live, what a function should truly own, or whether splitting code actually improved the design. Then I started my journey in LUR to rethink the way I write code, and relearning separation of concerns became one of the first things I focused on. From that learning process, i made an article series ”What I’m Learning About Writing Better Structured Code.” and this is the first part.

Seeing the Problem

Working code is not the same as well-structured code. A program can work correctly for the current problem, current input, and current environment, yet still become difficult to change later. As the app grows, the code also needs to grow without creating unnecessary friction for the programmer or the system itself.

To see that difference more clearly, let’s look at a small Todo CLI app. At first glance, nothing seems obviously wrong with it. It runs, it accepts input, and it performs the features it promises. But if we look past the result and inspect the structure, we can start to see the real problem.

import Foundation

struct TodoItem {
    var title: "String"
    var isDone: Bool
}

var todos: [TodoItem] = []

func showMenu() {
    print("")
    print("=== Todo App ===")
    print("1. Show all todos")
    print("2. Add todo")
    print("3. Toggle todo")
    print("4. Remove todo")
    print("5. Exit")
    print("Choose:")
}

func showTodos() {
    if todos.isEmpty {
        print("No todos yet.")
        return
    }

    for (index, todo) in todos.enumerated() {
        let mark = todo.isDone ? "[x]" : "[ ]"
        print("\(index + 1). \(mark) \(todo.title)")
    }
}

func addTodo() {
    print("Enter todo title: "\")"
    if let input = readLine(), !input.trimmingCharacters(in: .whitespaces).isEmpty {
        todos.append(TodoItem(title: "input, isDone: false))"
        print("Todo added.")
    } else {
        print("Invalid title.")
    }
}

func toggleTodo() {
    showTodos()

    if todos.isEmpty {
        return
    }

    print("Enter todo number to toggle:")
    if let input = readLine(), let number = Int(input) {
        let index = number - 1

        if index >= 0 && index < todos.count {
            todos[index].isDone.toggle()
            print("Todo updated.")
        } else {
            print("Invalid number.")
        }
    } else {
        print("Please enter a valid number.")
    }
}

func removeTodo() {
    showTodos()

    if todos.isEmpty {
        return
    }

    print("Enter todo number to remove:")
    if let input = readLine(), let number = Int(input) {
        let index = number - 1

        if index >= 0 && index < todos.count {
            let removed = todos.remove(at: index)
            print("Removed: \(removed.title)")
        } else {
            print("Invalid number.")
        }
    } else {
        print("Please enter a valid number.")
    }
}

func runApp() {
    var isRunning = true

    while isRunning {
        showMenu()

        let choice = readLine() ?? ""

        switch choice {
        case "1":
            showTodos()
        case "2":
            addTodo()
        case "3":
            toggleTodo()
        case "4":
            removeTodo()
        case "5":
            isRunning = false
            print("Goodbye.")
        default:
            print("Unknown option.")
        }
    }
}

runApp()

At first, this code looked fine to me because it worked. But the point of the lesson was not just to check whether the program ran. The real goal was to inspect the structure behind it.

If you cannot spot the problem yet, that is completely fine. I also did not see it clearly at first. In the next part, I will break down what separation of concerns actually means and the lens I started using to notice where the boundaries in this code were mixed.

Introduction to Separation of Concern

Separation of concerns simply means different parts of a program should handle different responsibilities. Instead of letting one place do everything, we try to give each part a clearer job. This becomes important as an app grows, because code that feels manageable at the beginning can quickly become hard to understand and harder to change.

When responsibilities are mixed together, one part of the program starts doing too many things at once. A small change in one feature can affect unrelated code. It becomes harder to tell where a piece of logic should live. Input and output, state changes, business rules, and app flow can all end up too close to each other. The code may still work, but its structure starts resisting change.

So the goal of separation of concerns is not to split everything into tiny pieces just for the sake of cleanliness. The real goal is to make responsibilities easier to understand, easier to change, and easier to reason about.

Supporting Concepts

To understand separation of concerns more clearly, we also need to look at several related concepts in software engineering. They help us see what separation of concerns is really trying to achieve, why mixed responsibilities become a problem, and what better boundaries can look like in code.

Responsibility ownership

Each part of the code should have a clearer job. For example, displaying things should mainly focus on displaying. State mutation should have a clearer owner. Input handling should not also become the place where all business rules live.

Cohesion

Things that belong together should stay together. A function can still do several small steps, but those steps should feel like one meaningful responsibility rather than unrelated tasks grouped in the same place.

Coupling

Different parts of the code should not know too much about each other. If everything can directly touch everything else, the code becomes harder to understand, change, and grow.

Modularity

Modularity means breaking a system into understandable pieces. This does not mean creating many files just for style. It means organizing code into parts that can be understood and changed more independently.

Abstraction

Abstraction means hiding detail behind a simpler and more meaningful idea. For example, toggleTodo(at:) is a more useful abstraction than repeating low-level mutation logic in many places.

Boundaries

Boundaries are the lines between different responsibilities.

data
state
input/output
business logic
flow control

All of these concepts are useful as foundational knowledge for writing well-structured code, especially when trying to notice and apply separation of concerns. They are also closely connected. Responsibility ownership helps us ask which part of the code should own a job. Cohesion helps us check whether related work stays together. Coupling helps us see when different parts of the code depend on each other too much. Modularity and abstraction help organize those responsibilities into clearer pieces. Boundaries tie all of these ideas together by showing where one responsibility should stop and another should begin.

From my learning journey, the idea of boundaries was the most practical lens for noticing whether code was applying separation of concerns well. It helped me see how responsibilities were placed, where they were mixed, and where the structure started to become unclear. So in the next part, I will use boundaries as the main lens to inspect the legacy code above, while still supported by the other concepts.

Reading the Todo App Through Boundaries

Now that we have introduced boundaries as a lens, we can use them to inspect whether the Todo app mixes responsibilities that leads to poor separation of concern.

For example, in addTodo(), we can already see several different responsibilities living in the same place: user input, todo-related logic (business logic), state mutation, and output rendering. The function does not only add a todo. It also asks for input, validates it, updates shared state, and prints feedback to the user.

Without looking at the next code, try to copy the code and paste to your code editor then mark it based on the data, state, input/output, business logic and flow control.

From my perspective, i found this

TodoItem → data model
todos → app state
showMenu() → output rendering
showTodos() → output rendering
addTodo() → user input + todo operations (business logic) + output rendering
toggleTodo() → user input + todo operations (business logic) + output rendering
removeTodo() → user input + todo operations (business logic) + output rendering
runApp() → app flow / menu loop + some user input

As you can see from the code above, several functions contain more than one kind of responsibility. That means the boundaries between responsibilities are blurred, and this is where mixed responsibilities start to appear. Because of that, the code does not follow separation of concerns very well.

The problem is not that the app has input, output, state, and logic. Of course it needs all of them. The problem is that too many of them are handled in the same place. When one function reads input, validates it, changes state, applies logic, and renders output at the same time, its responsibility becomes less clear.

The mental model

After noticing that, try asking yourself this question:

If this app changes, what kind of change should force this piece of code to change?

That question helps reveal the real point of separation of concerns. A well-structured piece of code should ideally change for one clear reason, not for many unrelated ones. If a single function has to change because of UI changes, input changes, validation changes, and business rule changes all at once, that is usually a sign that too many concerns are mixed together.

For example, imagine I want to change how input is taken. Maybe today the app uses readLine(), but later I want input to come from another interface. Functions like addTodo(), toggleTodo(), and removeTodo() would all need to change, because input handling is mixed directly into them. The same thing happens if I want to change how messages are shown to the user. Since those functions also print feedback directly, a display change would again force the same functions to change. Even a change in validation rules or todo behavior could affect those same places. One function ends up changing for multiple unrelated reasons, and that is the main sign that the boundaries are not clear enough.

So the point of separation of concerns is not just to split code into smaller pieces. The real point is to place responsibilities in clearer boundaries, so each part of the code has a more focused job and a more understandable reason to change.

From Noticing to Separating

After noticing code that does not apply separation of concerns well and understanding the pain it can create, the next question becomes: how should we start improving it?

This was the part that felt the most subjective to me. Even after seeing that responsibilities were mixed, I still did not know how to judge whether something should actually be separated. The hard part was that not everything inside a function deserves to become its own unit. Some parts are truly separate concerns, while others are just details of the same responsibility.

Then i found the most useful principle after looking to a lot of articles:

A separate concern is something that can change independently.
A detail is something that usually changes together with its parent responsibility.

In practical terms, this means I should not extract something just because it exists as a smaller step inside a function. I should ask whether that part could realistically need to change on its own.

For example, in addTodo(), input handling could change independently if the app later stops using readLine(). Validation could also change independently if the app starts enforcing stricter rules for todo titles. Output rendering could change independently if the way feedback is shown to the user changes. These are good signs that input handling, validation, and output rendering may deserve clearer boundaries instead of all living inside the same function.

But this judgment depends on the level we are looking at. A concern can be separate at one level, while still containing smaller details that should stay inside it. For example, in showTodos(), the line that chooses between "[x]" and "[ ]" is still part of the rendering job. It is a formatting detail inside rendering, not automatically a separate concern by itself. If the display style changes, that line would likely change together with the rest of the rendering logic.

That changed the question completely. I stopped asking only whether a function looked long or complicated. The better question became:

Is this part likely to evolve on its own?
Or is it just one small detail of the function’s main job?

From there, the most useful rule I learned was:

Extract only when the thing being extracted has its own meaningful reason to change.

Before this, I used to think about structure with a much simpler rule:

1 function = 1 purpose

But over time, I realized that the better version is this:

A function should have one cohesive responsibility at the level of abstraction it owns.

This idea was very important for me, because it helped me stop treating every small detail as a separate concern.

From Noticing to Separating, then Overthinking it

This new way of thinking also triggered a lot of overthinking for me. By this point, I would not be surprised if some readers are also starting to feel the same thing.

Most of that overthinking came from doubting my own judgment. In the example above, we are trying to think about how the code might need to change in the future. But once I started thinking in terms of future changes, the possibilities felt endless. What if the input changes? What if the output changes? What if validation becomes more complex? What if the app grows in another direction?

That is where my mind started branching too much. If every possible future scenario can be used as a reason to separate something, then it becomes easy to overthink the design and lose confidence in my own judgment.

Then I remembered something I once asked my Apple Developer Academy mentor, Gerson. His answer was

Your code is growing. Let it grow based on the need.

I understood that as a reminder that I do not need to predict the perfect architecture too early. Looking back, I think I had started to treat future change as something dangerous, as if needing to refactor later automatically meant I had failed (validating the overthinking above).

After that, I read more about this idea and realized the healthier way to think about it is much simpler:

write the simplest code that solves the current problem
let the code grow with real requirements
refactor when the current shape starts resisting change

Refactoring later is not evil. It is a normal part of software development.

This connects with ideas like:

make it work
make it clear
make it flexible

It also connects with the YAGNI principle, short for You Aren’t Gonna Need It. The core idea is that we should not build for imagined needs too early. If you want to read full explanation, here is the article .

A better approach is to solve the current problem clearly, then improve the structure when real change starts to demand it. That means a design is not automatically bad just because:

it is simple
it is unfinished
it may need refactoring later

A design becomes bad when:

the problem is still small
but the code is already confusing
even small changes already feel messy
responsibility ownership is unclear right now

So the best way to think about it is not:

right design
wrong design

but rather:

good enough for now
starting to strain
needs refactor soon
too rigid and harmful

The Todo app above is currently in the “good enough for now, but future strain is visible” stage. If you want to go deeper into how to judge code like this, I wrote the next article, “Judging the Problem: Code Smells and Refactoring” which is Part 2 of my series, ”What I’m Learning About Writing Better Structured Code.”. It will be out soon, so if this topic interests you, feel free to follow me and stay tuned for the next part.

From the Writer

Hello, allow me to introduce myself. I’m Cakoko. We’ve reached the end of this article, and I sincerely thank you for taking the time to read it.

Until next time, stay curious and keep learning.

Open for Feedback

If you have any feedback, suggestions, or corrections, I would truly appreciate them. I’m always open to learning more and improving along the way.

What I’m Learning About Writing Better Structured Code: A Learning Series

cakoko — Tue, 24 Mar 2026 04:03:21 +0000

After working as a mobile developer and iOS developer for more than two years, I started seeing the same kind of problems appear again and again. Many of them came from code that worked at the time it was written, but was not structured well enough to grow without causing pain later.

I made those mistakes myself. My coworkers made them too. Sometimes the problems came from older code written by people before us. Whether we realize it or not.

Code with weak structure eventually creates friction. Small changes become harder than they should be. Responsibilities become unclear. And over time, working with the code starts to feel heavier. That experience pushed me to think more seriously about how to avoid falling into the same problems again. It also made me question my own skill in writing code. I started realizing that I had learned how to make things work, but I had not yet learned broadly, deeply, or systematically enough how to think like a software developer when it comes to structure and design.

That realization became the start of a personal learning journey. The concept that i use is LUR: Learn, Unlearn, Re-Learn. It is a mindset I was introduced to during my time at Apple Developer Academy back then. For me, it means going back to important topics, questioning what I think I already understand, and rebuilding that understanding in a better way.

The first output of this learning journey is an article series called "What I’m Learning About Writing Better Structured Code". At least until now, the draft of this is 3 article which is:

Seeing the problem: An Introduction to Separation of Concern. PUBLISHED at https://dev.to/cakoko/seeing-the-problem-an-introduction-to-separation-of-concerns-4l1
Judging the Problem: Code Smells and Refactoring
Guide to Solve the Problem: Introduction to SOLID Principles

I will be publishing the articles here on dev.to as I finish them. If this journey sounds interesting to you, feel free to follow me and stay tuned for the next parts.