Photo by on Trent Pickering Unsplash Ask a software developer, what is ‘good code?’ They will likely answer something along the lines of, “it’s clean or elegant code.” It’s likely this person will further list principles and as a way to legitimize cleanliness or elegance. SOLID design patterns I think the way this relationship dynamic is interpreted is wrong. What I mean is that SOLID and design patterns do simply imply good code. It’s actually the other way around. Good code precedes them. But it goes much deeper than that. not Boundaries As humans, we divide reality across arbitrary boundaries in relation to a context or point of view. These divisions are used to speak and relate to each other in a correct way. Where context defines correctness, and the expectations we project, on a boundary. What I mean is that the same tree is “seen” differently by a kid and a botanist. These boundaries are abstractions on which we project expectations. This is where comes into play. object thinking Its goal is to model a computer to satisfy these expectations. It equates objects to boundaries. As boundaries, objects are the elemental way to divide reality. This is where object thinking’s superiority lies in respect of procedural thinking. Indeed, the latter wants to model every boundary with data and algorithms. In other words, it tries to reduce an arbitrary boundary to another arbitrary boundary. models boundaries to reflect computers. While models computers to reflect boundaries. Procedural thinking object thinking This is the reason why the ‘object way’ beats the procedural way. I’m not saying that the latter is absolutely wrong. I’m saying that it’s better when boundaries are defined by data and algorithms. Newsletter Demo A sage once said: “a demo is worth more than thousands of words”. So, here we are. The example comes with real example of a request from a customer. In this context, he’s a newsletter manager. At first, he said that users should be able to subscribe to the newsletter. We asked in which way. He said that they must provide an email. Using we can translate this expectation in this way: object thinking interface Newsletter {
    Newsletter subscribe(Email anEmail);
} So, given the boundary a user can subscribe to it with . The goal is to satisfy user expectations (in this context) through interfaces. Newsletter anEmail Then he said that a user can also unsubscribe in the same way: interface Newsletter {
    Newsletter subscribe(Email anEmail);

    Newsletter unsubscribe(Email anEmail);
} Obviously, he also expressed the need to broadcast news to subscribers. Then we asked if he needs to authenticate in some way. He took it for granted. And he furthermore explained that he expects to access a protected area with a passphrase. Then we discovered that, that news describes a fact with words. So, we can reflect these expectations in this way: interface Newsletter {
    Newsletter subscribe(Email anEmail);

    Newsletter unsubscribe(Email anEmail);

    ProtectedArea protectedArea(Passphrase aPassphrase);
}

interface Passphrase {
    Boolean correct(String passphrase);
}

interface ProtectedArea {
    ProtectedArea broadcast(News news);
}

interface News {
    String fact();
} This means that provides access to a . And the latter broadcasts . Newsletter ProtectedArea News After some time wanted to add the possibility to subscribe to the newsletter with a telephone number. So, we asked if and are references through which to send text to a subscriber. anEmail aPhoneNumber He agreed, and he pointed out that they also identify subscribers. Then, he expressed the needs to count subscribers. This is a way to satisfy these expectations. I added some simple classes as examples: interface Newsletter {
    Newsletter subscribe(Reference aReference);

    Newsletter unsubscribe(Reference aReference);

    ProtectedArea protectedArea(Passphrase aPassphrase);
}

interface Reference {
    String id();

    Reference send(String text);
}

class Email implements Reference {
    // implements method that sends email
}

class TelephoneNumber implements Reference {
    // implements method that sends SMS
}

interface Passphrase {
    Boolean correct(String passphrase);
}

class SHA512Passphrase implements Passphrase {
    // implements method to verify correctness
}

interface ProtectedArea {
    ProtectedArea broadcast(News news);

    Subscribers subscribers();
}

interface News {
    String fact();
}

interface Subscribers {
    Long count();
} At this point, he seems fulfilled (until the next needs). Conclusion I started this article by saying that SOLID and design patterns do not imply good code. At most, good code implies them. How ‘good’ your code is, depends only on how much it adheres and reflects the domain. After all, we code for this reason. But when we introduce extraneous abstractions we reduce the goodness. Inevitably. It isn’t important if they respect SOLID principles, a design pattern, or whatever best practice. Because they’re extraneous they don’t intrinsically exist in the domain. So, they should not be in the code. For this reason, thanks to its goal, object thinking has a great impact on good code. As I said it aims to model the computer to reflect the domain we are facing. In this optic, we start first from a domain understanding. Perhaps patterns will emerge. Spontaneously.

Uncover the Alias Pattern

Implementing an Event Loop in Java for Fun and Profit

Let's talk about OOP!

Nominated for 2022 - HackerNoon Contributor of the Year - Linux

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Java

Nominated for 2022 - HackerNoon Contributor of the Year - Docker

Too Long; Didn't Read

Make resilience your competitive advantage

Object Thinking, Boundaries, and Reality

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

How to Run Podman and Docker-Compose on Windows

Why I Switched to Table Driven Testing approach in Go

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

How to Run Podman and Docker-Compose on Windows

Why I Switched to Table Driven Testing approach in Go

Why Being Likable At Work Matters

Windows Sticky Keys Exploit: The War Veteran That Never Dies

Is ‘bias for action’ making product managers lazier?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps