DEV Community

sour_grape
sour_grape

Posted on

My Take on OOP (Part 2): Requirements and Contracts

Requirements are Money

Personally, I think the most important thing in software is making money.

To make money, you have to satisfy your users or customers. And to do that, you have to satisfy their requirements. Therefore, the most critical job in software is to figure out and fulfill the requirements. Period.

OOP and Requirements

Requirements and Object-Oriented Programming are two sides of the same coin. In fact, almost everything in software—OOP, TDD, DDD, and by extension, Microservices—are all just tools to help us satisfy requirements better.

If your requirements are a mess, all those fancy acronyms are useless. But on the flip side, if you get the requirements right and truly understand the "division of labor" I talked about in Part 1, it finally clicks: all these methodologies exist to serve the requirements.

Requirements and Contracts

I'm not going to talk about how to gather good requirements here. We'll also save TDD and DDD for later. For now, let's just focus on how to implement well-defined, real-world requirements in software.

In this series, I'm going to define the methods, expressions, and promises needed to satisfy a requirement as a "Contract."

A well-designed requirement defines constraints and necessary actions. For example, a smartphone display has the following requirements:

  1. It must turn on.
  2. Its brightness must be adjustable.

This is a requirement, a contract, a constraint. When we implement this in software, it's a non-negotiable contract we have to fulfill.

And the tool that lets us express and enforce this contract in code is the Interface.

interface Display {
    void turnOn(); // It turns on.
    void setBrightness(int level); // Its brightness can be adjusted.
}
Enter fullscreen mode Exit fullscreen mode

In the example above, the display's contract can be explicitly defined in code like this. Therefore, the interface is the tool that guarantees and enforces this contract in code.

The Development Process

If you strip away the operational stuff and just focus on implementing features, the process looks like this:

  1. Listen to the requirements through meetings with the client.

  2. Flesh out the requirements through ongoing meetings.

  3. Write up the contract.

  4. Execute the project design.

  5. Translate the contract for each part into an interface in code.

  6. The implementation classes must then honor this interface contract to complete the work.

The project's design is critical, and using interfaces is an extension of that design process. That's why they are so important.

Back to Requirements and OOP

So, what does all this have to do with Object-Oriented Programming?

If the essence of OOP is the 'division of labor', then requirements are the very work that gets divided. They are the standard for that division.

We look at the requirements to decide what to split apart. We analyze the requirements to group related things together. This very process—of dividing and grouping the system appropriately based on requirements and assigning clear responsibilities to each part—is the object-oriented approach.

And the interface is the tool that enforces the promises (the contracts) between these divided, collaborating objects.

(Next time, we'll discuss this further.)

Top comments (0)