DEV Community: mprytula

Design by Contract in OOP with TypeScript

mprytula — Fri, 13 Mar 2026 22:08:45 +0000

What Is a Contract?

A contract is a set of rules that defines how two parties are expected to interact. It answers three questions:

what is allowed as input;
what must be produced as output;
who is responsible for what.

In real life, this is easy to understand through the example of an employment agreement. An employee agrees to work during the agreed hours, and the employer agrees to pay a salary. If both sides follow the terms, the relationship remains predictable. If not, the contract is broken.

The same idea applies to programming. One module calls another and expects certain behavior. In order for the system to remain reliable, the rules must be clear in advance:

what data may be passed in;
what result should be produced;
what conditions must always remain true.

That is exactly what Design by Contract is about.

Contracts in Programming

In practice, many bugs do not come from complicated logic, but from implicit assumptions. One module assumes it will receive valid data. Another assumes the method will validate everything on its own. As a result, behavior becomes confusing and unpredictable.

Consider this example:

class PaymentProcessingService {
    constructor(
        private moneyTransferProvider: MoneyTransferProvider,
        private commissionRate: number
    ) {}

    // The rules for using this method are not expressed explicitly
    processPayment(target: string, amount: number, currency: string): number {
        if (!isUUID(target)) {
            return 0;
        }

        if (amount <= 0) {
            return 0;
        }

        const commission = amount * this.commissionRate;
        this.moneyTransferProvider.transfer(target, amount, currency);

        return commission;
    }
}

At first glance, this code looks acceptable, but it has a serious problem: the contract of the method is hidden inside the implementation.

From the method signature alone, it is impossible to understand:

what kind of target is considered valid;
whether any string can be passed as currency;
what the return value means;
how to distinguish a successful result from an error.

To use such a method safely, the developer has to read its implementation and guess the rules. That is a bad sign: the contract should be visible in the API, not buried in the method body.

The situation becomes even worse if the system contains several similar services. One may return 0 on failure, another may throw an exception, and a third may skip validation entirely. From the outside, the methods look similar, but their actual behavior is different. This makes the system fragile.

What Design by Contract Offers

Design by Contract addresses this problem by making the rules explicit. A method should not merely perform some action; it should have a clearly defined contract.

A contract usually consists of three parts:

preconditions — what the caller must guarantee before invoking the method;
postconditions — what the method must guarantee after execution;
invariants — properties that must always remain true.

The most well-known implementation of this approach was introduced in the Eiffel programming language. In Eiffel, a contract can be declared directly alongside the method:

class
    PAYMENT_PROCESSING_SERVICE

feature 

    process_payment (target: STRING; amount: REAL_64; currency: STRING): REAL_64
        require
            target_attached: target /= Void
            target_is_uuid: is_uuid (target)
            amount_positive: amount > 0.0
            currency_attached: currency /= Void
            currency_not_empty: not currency.is_empty
            currency_supported: is_supported_currency (currency)
        local
            commission: REAL_64
        do
            commission := amount * commission_rate
            money_transfer_provider.transfer (target, amount, currency)
            Result := commission
        ensure
            calculated_correctly: Result = amount * commission_rate
            result_positive: Result > 0.0
        end

Even without knowing Eiffel, the idea is clear: before the method runs, the required conditions for the input are listed explicitly; after it runs, the guarantees about the result are also stated explicitly.

This is useful for two reasons.

First, the caller can immediately see how the method is supposed to be used.

Second, the implementation cannot behave arbitrarily: it is obligated to fulfill the promises declared in the contract.

This is especially important in inheritance. If a base class defines a contract, a subclass should not unexpectedly change the rules and require something different from the client.

How to Implement This in TypeScript

TypeScript does not have built-in contract support like Eiffel. We cannot declare invariants and postconditions directly in a method signature in the same way.

But that does not make the idea useless. It simply means the contract has to be expressed differently.

The key principle here is this: the caller is primarily responsible for satisfying the preconditions.

If every method revalidates everything internally, the code quickly turns into a mess of repeated checks. This is often called validation hell: the same validation logic is scattered across multiple layers of the system, and the boundaries of responsibility become unclear.

In TypeScript, the main tools for expressing a contract are:

parameter types;
return types;
domain objects that do not allow invalid states to be created.

The idea is simple: if a method accepts not just string and number, but UuidV4, Money, and Percentage, then part of the contract is already expressed in the signature itself.

Consider an improved version of the example:

class PaymentProcessingService {
    constructor(
        private readonly moneyTransferProvider: MoneyTransferProvider,
        private readonly commissionRate: CommissionRate
    ) {}

    processPayment(target: UuidV4, money: Money): void {
        const moneyToTransfer = this.commissionRate.apply(money);
        this.moneyTransferProvider.transfer(target, moneyToTransfer);
    }
}

Now the method is much clearer.

From the signature alone, we can already see that:

target must be a valid UuidV4;
money is not just a raw number, but an object that already contains a valid amount and a valid currency;
the service does not need to repeatedly validate raw strings and numbers.

In other words, part of the invariants has been moved out of the method body and into the types.

Invariants Inside Domain Types

For example, a valid commission can be represented as a separate type:

class CommissionRate {
    private readonly rate: Percentage;

    constructor(rate: Percentage) {
        this.rate = rate;
    }

    apply(money: Money): Money {
        return this.rate.apply(money);
    }
}

Here, CommissionRate does not check whether the percentage falls within the allowed range. That responsibility already belongs to the Percentage type. As a result, the service works only with valid values and does not duplicate validation.

Money can also be modeled as a separate type:

enum Currency {
    Euro = 'euro',
    USD = 'usd'
}

class Money {
    constructor(
        private readonly amount: PositiveNumber,
        private readonly currency: Currency
    ) {}

    withdraw(money: Money): Money {
        if (money.currency !== this.currency) {
            throw new InvalidParameterError('Cannot withdraw money of different currencies');
        }

        return new Money(
            this.amount.subtract(money.getAmount()),
            this.currency
        );
    }

    getAmount(): PositiveNumber {
        return this.amount;
    }

    getCurrency(): Currency {
        return this.currency;
    }
}

This kind of type is useful because it keeps the rules for handling money in one place. The system no longer operates on plain numbers. It operates on objects that already define their own constraints and allowed operations.

The same applies to positive numbers:

class PositiveNumber {
    private readonly value: number;

    constructor(value: number) {
        if (value <= 0) {
            throw new InvalidParameterError('Value must be positive');
        }

        if (value > Number.MAX_SAFE_INTEGER) {
            throw new InvalidParameterError(
                `Value must not exceed ${Number.MAX_SAFE_INTEGER}`
            );
        }

        this.value = value;
    }

    subtract(other: PositiveNumber): PositiveNumber {
        return new PositiveNumber(this.value - other.getValue());
    }

    getValue(): number {
        return this.value;
    }
}

Such a class prevents invalid values from being created in the first place. That means any code receiving a PositiveNumber can already rely on the basic validity of the data.

What This Gives Us

This approach makes code:

easier to understand;
more predictable;
less dependent on hidden validation logic;
more resilient at module boundaries.

Validation is concentrated where values are created, instead of being spread across the entire system. Inside business logic, there is less noise and more clarity.

The Limits of TypeScript

Of course, TypeScript does not give us the same guarantees as Eiffel.

We still cannot:

fully declare method contracts at the language level;
strictly enforce postconditions;
completely protect ourselves from subclasses changing behavior and breaking the base contract.

That is why Design by Contract in TypeScript is not a built-in language mechanism, but rather a design discipline.

Even so, this discipline is still enough to significantly improve code quality. In practice, it helps to:

make domain types as precise as possible;
avoid inheritance where composition is sufficient;
cover important contracts with tests;
document preconditions and invariants clearly in the API and documentation.

Conclusion

TypeScript cannot implement Design by Contract in its classical form. But it can get close to the same idea through types, value objects, and careful separation of responsibility.

That is the practical value of the approach: not to validate everything everywhere, but to design the system in such a way that as many invalid states as possible become impossible to represent in the first place.

A year after...

mprytula — Sun, 11 Jan 2026 21:00:50 +0000

When I was looking for a job, I was genuinely frustrated that most companies were not willing to consider developers without experience, even for Junior Developer positions. I couldn’t understand what objective advantages an experienced developer had over a beginner.

Now, after a year of working as a commercial developer, I want to share how this year has influenced my perspective.

🧠 Soft Skills

Most beginners, including my past self, significantly underestimate the importance of soft skills in modern software development. Meanwhile, they are critically important for any developer: they improve not only relationships within the team, but also personal productivity.

Effective communication — both with the team and with the business — greatly simplifies requirement clarification and task definition. In my experience, this accounts for around 65% of success in completing any task. Unfortunately, this is one of the skills that is almost impossible to develop without real work experience.

🏗️ Architectural Thinking

Architectural thinking is the ability to consider a task not in isolation, but in the context of the entire system. This skill goes far beyond theoretical knowledge of SOLID, GRASP, or other design patterns. It includes understanding a specific product: which parts of the system are critical, where the bottlenecks are, which areas require scalability, and where additional flexibility would only increase the estimate without providing real value ⚖️.

I believe this type of thinking is primarily formed through working on a specific product and deeply understanding its domain. At the same time, knowledge of general design principles such as SOLID significantly accelerates and simplifies this process.

💼 Business-Oriented Thinking

Lack of business-oriented thinking is a common issue among junior developers and beyond.

By business-oriented thinking, I mean the ability to prioritize company goals over personal preferences — for example, agreeing to speed up the development of a specific feature at the cost of temporarily reducing code quality. This approach often conflicts with internal perfectionism, but it is important to understand that the business does not care how the code is written. It cares about how it works and how much it costs to deliver a feature.

This is especially relevant for startups, where releasing new functionality provides a competitive advantage here and now 🚀. That advantage is directly tied to revenue, which in turn leads to team growth, salary increases, and — in the long term — more time for high-quality technical work.

At the same time, it is important to maintain a delicate balance. Development interests cannot be ignored. If short-term acceleration through smelly code leads to significant slowdowns in the medium term, it is the developer’s responsibility to warn the business about the consequences. Otherwise, this would conflict with the company’s long-term interests in growth and sustainable development.

🌱 Conclusion

A year of commercial development helped me realize that experience is not an innate advantage, but a set of skills and approaches that gradually form through practice. Communication, architectural thinking, and business-oriented thinking all develop over time and do not automatically appear with the first job.

For developers without experience, this means that the gap is not insurmountable 💪. A conscious focus on these aspects, genuine interest in the product, and a willingness to learn can significantly shorten the distance and help transition faster from a beginner to a full-fledged member of the team.

Macroservices

mprytula — Sun, 02 Nov 2025 18:27:20 +0000

Essence

Macro-services emerge from incorrect microservice decomposition and significantly complicate development. They are oversized microservices responsible for too many processes that could have been separated.

Macroservice

A macroservice appears when a single service combines multiple loosely related business processes.

To identify weak coupling, clearly define what the service actually does — the specific business problem it solves in one sentence. If that sentence contains an “and”, it’s a clear sign the service handles unrelated processes.

When these processes are decoupled, a new business model can emerge that differs from the original one.

Symptoms

The model becomes large and difficult to develop
Several teams work on the same service simultaneously
Many dependencies on external services

How to fix it

Define the service’s area of responsibility and design the minimal model needed to function within it.

Let’s look at a messenger application and its user service.

This service manages the user: their chats, contacts, account settings, blacklist, etc.

But why does managing account settings require knowledge about chats? Why should the blacklist involve chat groups?

A key problem is the growing complexity of the model — for example, if we want to add a whitelist, split contacts into “registered” and “spontaneous,” or introduce a message deletion timer, the user model would become even heavier.

That’s how weak coupling becomes visible. Let’s decompose the user service.

Decomposition

I split the services into three, each with its own responsibility:

user account management — handles account settings
social — handles interactions between users
chat — handles messaging

With this structure, the processes and dependencies inside each service are easier to understand. By increasing granularity, each team can own a separate service without overlapping in their work.

Low Coupling and High Cohesion: simple with diagrams

mprytula — Fri, 08 Aug 2025 22:00:05 +0000

Short description

Low coupling and high cohesion have been around for a long time as part of the GRASP patterns. However, the difference between coupling and cohesion is subtle. Many developers tend to mix them up, or understand only one (usually coupling) but not the other.
Please, keep in mind, that this article reflects my own interpretation of the concepts of cohesion and coupling as presented in Clean Code by Robert C. Martin.

This note covers following questions:

What’s the difference between coupling and cohesion?
When does coupling become cohesion?
Why can’t coupling exist without cohesion?

Coupling and Cohesion

Coupling and cohesion are closely related concepts. The confusion often comes from the language itself — the words sound similar and are sometimes used interchangeably in everyday conversation.

Both measure communication or dependency between entities. The difference lies in the level at which the communication happens:

Cohesion: interaction between elements inside the same module.
Coupling: interaction between different modules.

When Does Coupling Become Cohesion?

Remember:

Cohesion = communication between elements inside a module
Coupling = communication between a module and something outside it As abstraction level raises, so does the definition of the module. So in the scope of the package, what used to be a coupling in the scope of the classes - becomes cohesion.

Low Coupling, High Cohesion

That's why the pattern is called Low Coupling, High Cohesion because the two are linked — you can’t have one without the other — but coupling introduces risk.

The goal is to keep coupling as low as possible. That means minimizing and controlling the points where modules depend on each other(coupling points), while keeping cohesion high within each module so it’s internally well-organized.

Real life Examples:

Low coupling: Other departments communicate with IT only through the CTO. This creates a single, stable point of contact, reducing miscommunication and making the system more resilient. The main risk is if the CTO changes, but that’s a controlled and infrequent event.
High coupling case: Other departments talk directly to individual developers. This increases risk and instability because many points of dependency can change frequently. It’s far harder to guarantee stability here.

Why Not Reduce Both?

You might think: If coupling (the bad guy) and cohesion are tied together, why not lower cohesion to reduce coupling?

Because low cohesion breaks the Single Responsibility Principle (SRP). Cohesion between internal elements ensures each part has a clear, minimal responsibility.

Imagine merging the Sales and IT departments into one hybrid “Sales-IT” team. Technically, there’s no coupling between them anymore — they’re one module. But now the team violates SRP, and the risks of having unrelated responsibilities mixed together outweigh the benefits.

So, the better approach is:

Keep high cohesion inside your modules
Keep loose coupling between modules

Sum up

Cohesion - communication inside one module
Coupling - communication between different modules
Coupling and Cohesion are linked, one does not exists without the other.
Keep coupling low by reducing the number of coupling points.

Information and inspiration source

Clean Code by Robert C. Martin