DEV Community: Emmanuel Valverde Ramos

🇬🇧 My Profession before my Job

Emmanuel Valverde Ramos — Fri, 07 Feb 2025 17:31:16 +0000

Today I publish a article that is not mine, but is too good to not share with others.

Is a shame that some times the companies didn’t care engough to build safe spaces where we can express ourselves. Today I give voice to someone that rather remain anonymous.

Original in Spanish https://open.substack.com/pub/emmanuelvalverderamos/p/antes-mi-profesion-que-mi-trabajo

Giuseppe Arcimboldi, THE WINTER 1563

I love my profession. I love being a software engineer and I love software. Not only software, though, I deeply enjoy everything that comes with it. I enjoy understanding the people I work with and thinking about our relations. I like who I am when I code. It stimulates me in a way that nothing else can. I love to learn. I am very happy and grateful to have found my calling.

For a long time, software has been the glue holding me together. It was the pillar upon which my self-perception was being supported. Coding made me feel good about what I was doing. Software has also been a priority in my life: I’ve made decisions based on maximising such a positive feeling. Some of them came with unpleasant consequences and some led to outcomes entirely different from what I expected. I don’t regret any of them, although I’ve learned from them and today I probably would choose differently.

Recently I was flattered when someone asked me to join an interesting project as a founder and technical lead. To my surprise, I instantly knew I would say no. I even allowed my dreamier side to sweeten my thoughts with the fantasy of success. To be honest, I just realised that probably I wouldn’t start a project from scratch again. Been there, done that. I’m simply no longer interested.

For quite a few years now, I’ve been able to choose my work. I am aware of the privilege that this is and I feel grateful every day.

So far, my career navigation strategy has always been expansive: Which is the next challenge? Which project will take me to the next level?

I had never questioned whether this way of thinking made sense—I just assumed it was what I had to do. And it worked well for me. Until it didn’t.

I ended up at a company where human relationships were different from what I’d encountered before. I found far more politics than I could handle—or wanted to. Most of the strategies I had honed over the years weren’t even applicable. In short, it was an unfamiliar environment, and more than a little reluctant to change.

For the first time, I experienced irrelevance firsthand. The bare minimum expectation for performance. The possibility of staying quiet, doing the work, and getting paid. Overpaid. Getting way too much money to create garbage. I realised I no longer thought about work in my leisure time nor wanted to do so. In short: the mediocre peace, a watered-down wine, the profitable nap.

Actually, it wasn’t quite like that. I had to crash into a wall, break my head open, and wake up from a coma dazed in the same place. I was the same but it felt entirely different.

It comes without saying, I wanted to change my environment in my own way. Like many times I did before, not caring much about the evidence. Ego? The very one.

You can’t change people nor groups of people. You can support change, even lead it, but you can’t impose it. Trying to do so is, at best, naïve but mostly futile.

Needless to say, the journey was emotionally painful and professionally counterproductive. My mental health suffered, and, to put it bluntly, I was shown the exit door.

It wasn’t a pleasant time, but it was the best thing that could have happened. As I hit rock bottom in my grieving process, a quote from Rafa Muñoz came to my rescue:

"I’ve decided to stop talking about the bad things and start talking about the good ones, because holding onto anger only hurts me and not the person who caused it."

A lifesaver, let me tell you. Like a third-act movie scene, I woke up in my own body, but everything was different: remote work, good pay, flexible hours, minimal expectations, maximum comfort. Jackpot!

The bottom of my pit was actually a wormhole to another universe where my job and my profession were distinct things. Who would’ve thought?

At work, I’m like a plant. I just exist. I only need a little water and sunlight. Plants don’t argue—they photosynthesize monitor light into money by the end of the month. My work ends in the late afternoon; my profession begins after that.

Books, katas, conferences, podcasts... Black and white turns to color, and sap becomes blood again. From then on, I become the version of myself I enjoy the most. I don’t need to be paid for that.

Perhaps someday my job and my profession will converge again—I truly hope they do—but for now, I’ve freed myself from that need. I’ve found balance on the other side of the local maximum I once thought was absolute. An unstable balance, perhaps, but one that is necessary and sufficient. For now.

🇪🇸 Antes mi profesión que mi trabajo

Emmanuel Valverde Ramos — Fri, 07 Feb 2025 17:30:59 +0000

Hoy publico un articulo que no es mio, pero me parecia demasiado bueno para no compartirlo.

Es una pena que a veces no tengamos los espacios seguro en nuestras organizaciones para poder compartir lo que pensamos, hoy le doy voz a una persona que ha preferido permanecer anonima.

Versión traducida al inglés: https://open.substack.com/pub/emmanuelvalverderamos/p/my-profession-before-my-job

Giuseppe Arcimboldi, THE WINTER 1563

Me encanta mi profesión. Me encanta el software. Pero no solo el software, ojo, también todo lo que hay a su alrededor: Me encanta dar forma y formar parte de equipos, me encanta entender a las personas con las que trabajo y examinar nuestras relaciones. Me gusta quién soy cuando programo y me estimula de una manera que ninguna otra cosa consigue. Me encanta aprender. Estoy muy feliz por haber encontrado mi vocación.

Durante mucho tiempo, esto del software ha sido uno de los pilares que sustentaban mi autopercepción y que me hacían sentir bien con lo que hacía. Ha sido algo prioritario en mi vida: he tomado decisiones basadas en maximizar este sentimiento positivo. Algunas de ellas con consecuencias desagradables y algunas con resultado totalmente distinto al esperado. No me arrepiento de ninguna aunque he aprendido de ellas y hoy elegiría distinto.

Hace poco me halagaron pidiéndome formar parte como fundador y brazo técnico de un proyecto interesante y, para mi sorpresa, tuve clarísimo que diría que no desde el principio. Incluso dejé a mi parte más soñadora darse un paseo por la fantasía del éxito. Te digo más, he tenido claro que probablemente jamás vuelva a pasar por la montaña rusa de arrancar un proyecto desde cero. Been there and done that. Simplemente ya no me interesa.

Hace bastantes años que elijo mi trabajo, eso es un privilegio que hay que apreciar cada día un poco. Mis criterios de elección siempre han sido expansivos: ¿Cuál es el siguiente reto? ¿Qué proyecto me hará llegar al siguiente nivel?

Ni siquiera me había planteado nunca si esta manera de pensar tenía sentido. Lo asumí como lo que había que hacer. Además me había funcionado bien. Hasta que dejó de hacerlo.

Aterricé en una empresa donde las relaciones humanas eran distintas a las que me había encontrado hasta ahora. Encontré mucha más política de la que sé (o quiero) manejar. La mayoría de las estrategias que me han servido y que he pulido durante años ni siquiera eran implementables. En pocas palabras, un contexto desconocido y más que un poquito reacio al cambio.

Por primera vez viví en primera persona la irrelevancia. La mínima expectativa de rendimiento en lo que hago. La posibilidad de callar, hacer y poner la mano. El cobrar por hacer basura. La sorpresa de no pensar en trabajo fuera del horario laboral y la pereza al forzarme a hacerlo. En pocas palabras: la paz mediocre, el vino aguado, la siesta rentable.

En realidad no fue así. Tuve que chocarme con un muro hasta partirme el cráneo y despertar aturdido en el mismo lugar, pero que entonces fue otro.

Obviamente quise cambiar mi contexto. A mi manera. Como lo había hecho antes. Sin prestar demasiada atención a la evidencia. Para ego, el que te dije, Diego. No se puede cambiar a las personas. Tampoco a los grupos de personas. Se puede apoyar el cambio, incluso liderarlo, pero no imponerlo. Intentarlo es, cuanto menos, ingenuo, además de inútil.

Ni que decir tiene que el camino fue doloroso en lo emocional y contraproducente en lo profesional. Mi salud mental se resintió y, dicho pronto y mal, me enseñaron la puerta.

No fue bueno, pero fue lo mejor. Mi proceso de duelo tocó fondo y una cita de Rafa Muñoz acudió a mi rescate:

Quiero dejar de hablar de las cosas malas y empezar a hablar de las buenas porque reconcentrar la mala hostia sólo me hace daño a mí y no lo sufre quien me la genera.

Mano de santo, hoyga. Como en una secuencia del tercer acto de una película mala, desperté en mi propio cuerpo pero todo era diferente: trabajo remoto, bien remunerado, horario flexible, mínima expectativa, máximo confort. Jackpot!

El fondo de mi pozo era, en realidad, un agujero de gusano a otro universo donde mi trabajo y mi profesión eran cosas distintas, ¿Quién lo hubiera dicho?

En mi trabajo soy una planta. Me limito a existir. Sólo necesito un poquito de agua y sol. Las plantas no discuten, fotosintetizan luz de monitor en dinero a final de mes. Mi trabajo acaba a media tarde, mi profesión empieza a partir de entonces.

Libros, katas, conferencias, podcasts… El blanco y negro se torna en color y la savia en sangre de nuevo. Soy, a partir de entonces, la versión de mí que más disfruto. No necesito que me paguen por ello.

Quizás algún día, mi trabajo y mi profesión vuelvan a converger, espero que lo hagan, de verdad, pero, de momento, me he liberado de esa necesidad. He encontrado equilibrio al otro lado del máximo local que había entendido como absoluto. Equilibrio inestable, quizá, pero necesario y suficiente. Por ahora.

Unlock the Secrets of Software Testing: State-Based, Output-Based, and Communication-Based verifications

Emmanuel Valverde Ramos — Tue, 04 Feb 2025 08:00:52 +0000

Who is this article for?

This article is designed for:

Beginners exploring the world of automated testing.
Individuals starting with Test-Driven Development (TDD) want to understand what makes a good test.

What this article won't cover

While this article provides a strong foundation, it won't cover:

TDD processes.
Strategies like the Test Pyramid.
Types of tests (e.g., unit vs. integration).
Test doubles such as mocks, stubs, or spies.

Instead, we'll focus on the characteristics that define a great automated test.

Introduction to testing types of verifications

In software testing, it's crucial to understand different verification styles to ensure code quality, robustness, and maintainability. This section focuses on three distinct styles of assertions: State-Based , Output-Based , and Communication-Based. These approaches are based on concepts from Vladimir Khorikov's book Unit Testing Principles, Practices, and Patterns, and are further explored in Emily Bache's article on test design styles. Each style offers a unique way to test your system, varying based on system behavior, dependency interactions, and verification requirements.

The SUT and its behavior

The fundamental connection between these test types: State-Based , Output-Based , and Communication-Based —centers on the System Under Test (SUT) and its behavior. The appropriate testing approach depends on what's being tested (whether a class, component, or microservice) and what needs verification (state changes, outputs, or interactions).

This framework simplifies test categorization by focusing on how the SUT behaves in different scenarios. From unit tests checking object states to integration tests verifying module communication, or contract tests confirming service interactions—each test ensures the SUT behaves as intended.

In conclusion, effective testing goes beyond mere categorization or naming conventions. What matters most is the type of verification performed, the expected behavior of the SUT, and the long-term costs of test maintenance.

State-Based verification

State-based tests verify the final state of a system after an operation is completed. These tests check whether the state of the system under test (SUT) or its collaborators has changed as expected after acting. The state can refer to the SUT itself, its dependencies, or external dependencies like databases or file systems.

Usage : This testing style is ideal for validating system state changes after specific interactions.
Example : Consider a payment processing class. After calling the payment method, a state-based test would verify that the customer's balance has decreased by the correct amount.

@Test
void add_given_product_to_the_order() {
  // Arrange
  Product product = new Product("Free Guy");
  Order sut = new Order();

  // Act
  sut.add(product);

  // Assert
  assertThat(sut.products())
      .hasSize(1)
      .containsExactly(product);
}

State-based tests excel at verifying persistent changes, especially when code has side effects that need tracking—such as database writes or object state modifications.

Output-Based verification

Output-based tests focus on providing input to the system under test (SUT) and verifying its output. These tests work with pure functions—those that produce no side effects and return only a value to the caller.

Usage : These tests are ideal for functional units where the output depends solely on the input.
Example : Consider a function that adds two numbers. An output-based test would feed different number pairs into the function and verify that each sum matches the expected result.

@Test
void discount_of_two_products_should_be_two_percent() {
  // Arrange
  Product product1 = new Product("Kaamelott");
  Product product2 = new Product("Free Guy");

  // Act
  double discount = PriceEngine.calculateDiscount(product1, product2);

  // Assert
  assertThat(discount).isEqualTo(0.02);
}

Since output-based tests treat the system as a black box, they are effective at testing business rules and pure logic in a clean, straightforward manner.

Communication-Based verification

Communication-based tests verify how a system interacts with its collaborators by checking that the system under test makes the correct method calls to its dependencies. These dependencies are typically replaced with test doubles—mocks, stubs, or spies.

Usage : Communication-based tests focus on verifying interactions rather than final states or outputs. They shine when testing systems with complex dependencies or when an operation's correctness depends on specific calls to collaborators.
Example : Consider a class that sends emails for new user registrations. Rather than testing if an email was actually sent (which would require an external service), you would use a mock email sender to verify that it received the correct parameters.

@Test
void greet_a_user_should_send_an_email_to_it() {
  // Arrange
  String email = "john.doe@email.com";
  EmailGateway emailGatewaySpy = mock(EmailGateway.class);
  Controller sut = new Controller(emailGatewaySpy);

  // Act
  sut.greetUser(email);

  // Assert
  verify(emailGatewaySpy, times(1)).sendGreetingsEmail(email);
}

Communication-based tests are particularly useful for validating how the SUT works—ensuring that methods interact correctly with their dependencies. These tests can serve as a bridge between unit tests and integration tests when verifying communication flows.

Summary

These three testing approaches offer distinct perspectives for verifying software correctness.

State-based tests verify state changes after an action, making them perfect for scenarios involving persistent side effects.
Output-based tests excel at pure logic verification, ensuring functions produce consistent, predictable results from given inputs.
Communication-based tests examine how objects interact, ensuring different system components collaborate effectively.

Each approach has its strengths and limitations. Choosing the right one depends on your system's specific behavior. Used together, they create a robust strategy for maintaining software quality, reliability, and adaptability to change.

Thanks for reading Crafting software! This post is public so feel free to share it.

Fowler, Martin. Mocks Aren't Stubs. https://martinfowler.com/articles/mocksArentStubs.html
Khorikov, Vladimir. Unit Testing Principles, Practices, and Patterns.
Bache, Emily. "Styles of Unit Tests. https://sammancoaching.org/learning_hours/test_design/styles_of_unit_tests.html
Thirion, Yoan. Some of the graphic references in the article. https://yoan-thirion.gitbook.io/knowledge-base/xtrem-reading/my-book-infographics

Start Survey

How to write a test?

Emmanuel Valverde Ramos — Tue, 28 Jan 2025 08:00:48 +0000

Who is this article for?

This article is designed for:

Beginners exploring the world of automated testing.
Individuals starting with Test-Driven Development (TDD) want to understand what makes a good test.

What this article won't cover

While this article provides a strong foundation, it won't cover:

TDD processes.
Strategies like the Test Pyramid.
Types of tests (e.g., unit vs. integration).
Test doubles such as mocks, stubs, or spies.

Instead, we'll focus on the characteristics that define a great automated test.

Introdución

This article provides an introductory guide to writing tests. We'll explore the 4 phases of a test and the 3 test components, examining how they work together. To get the most from this guide, you should be familiar with the concept of Subject Under Test. Having experience with a testing framework will also help you grasp these concepts better.

Crafting software is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Las 4 fases de un test

Setup

This phase prepares all necessary conditions for the test. Here, you create objects, set initial states, configure dependencies, and get the test environment ready.

Examples :

Testing frameworks provide two key setup concepts to make your tests more readable: BeforeEach and BeforeAll. With BeforeEach, any functionality defined in that method runs before each test. With BeforeAll, the defined functionality runs once before the first test begins and doesn't run again until the next test suite execution.

Exercise

This phase executes the behavior being tested. You interact with the system under test (SUT) by calling the method or function you want to validate.

Examples :

Verify

In this phase, you check if the output or behavior of the system under test matches what you expect. This is where you use assertions to verify correctness.

Use assertions to confirm that the returned value matches the expected output.
Verify interactions with test doubles when indirect outputs are involved.

This phase relates directly to verification types, which will be covered in another post.

Teardown

This phase restores the test environment to its original state by cleaning up resources. This prevents tests from interfering with each other when they share state or resources.

Examples :

Most testing frameworks provide similar functionality for teardown as they do for setup. Methods like AfterEach and AfterAll work like their setup counterparts but execute after tests are complete.

The 3 parts of a test - Arrange, Act, Assert or Given, When, Then

Arrange-Act-Assert is a simple concept, and probably only adds marginal value. But it costs nothing to practice, and it gets us that much closer to being a community willing to agree on some standards. What I also like about memorable acronyms like AAA is that they provide a consistent way to communicate simple ideas, which often don't have concise and consistent names.

Tim Ottinger & Jeff Langr

The Arrange-Act-Assert (AAA) pattern is a widely used method for writing clear, systematic unit tests. It divides each test into three distinct phases:

Arrange: Set up the initial test conditions by creating objects, configuring dependencies, and preparing the test environment. This establishes the context for testing the desired behavior.
Act: Execute the functionality you want to test by calling methods or functions of the System Under Test (SUT) using the prepared data.
Assert: Verify the results by comparing the actual output with expected outcomes to confirm the SUT behaves correctly.

This pattern makes tests easier to understand and maintain by separating responsibilities. Each test focuses on a specific behavior, which improves precision and effectiveness.

The AAA pattern mirrors the Given-When-Then approach used in Behavior-Driven Development (BDD), where:

Given: Sets up the initial context or preconditions.
When: Describes the action or event being executed.
Then: Specifies the expected outcome or postcondition.

Both approaches create tests that are easy to read and understand for developers, which is for me one of the most important points, because like the test desiderata mentions readability is one of the important attributes that a good test should have.

These 3 parts of a test have a direct and important relationship with the first three phases of the test phases we discussed earlier. The Arrange part corresponds to the Setup phase, where we prepare our test environment. The Act part aligns with the Exercise phase, where we execute the behavior we want to test. Finally, the Assert part matches the Verify phase, where we confirm our expectations. This structured approach helps create clear, maintainable tests that are easy to understand and modify. If we examine this relationship in more detail, it would look something like this.

Let’s see a small example

public class TemperatureConverterShould {

  @Test
  void converts_the_temperature_given_in_celsius_to_fahrenheit() {
    // Arrange
    TemperatureConverter converter = new TemperatureConverter();
    double inCelsius = 25.0;

    // Act
    double inFahrenheit = converter.celsiusToFahrenheit(inCelsius);

    // Assert
    assertEquals(77.0, inFahrenheit, 0.001); // Allowing a small delta for floating-point precision
  }
}

Test focus on the Behavior

To create a good test is really important to identify the behavior you are trying to test, and identify the best way of testing it.

Conclusions

Understanding the phases of a test is crucial—it reveals how tests work behind the scenes and provides valuable insights into your current testing phase and requirements during development.

Similarly, using the Arrange-Act-Assert or Given-When-Then patterns helps separate responsibilities in tests and guides our thinking about assertions. This is why many TDD practitioners start with assertions: they shape how the test will be structured and what needs to be verified.

Focus always on the behaviour to test, and identify the best way to do it.

References

Ottinger, Tim. Langr, Jeff. Agile in a Flash - Arrange-Act-Assert. https://agileinaflash.blogspot.com/2009/03/arrange-act-assert.html
Bache, Emily. 3 Parts of a TEST | Guided Learning Hour.
Bache, Emily. 3 Parts of a TEST https://sammancoaching.org/learning_hours/test_design/three_parts_of_a_test.html
Meszaros, Gerard. Four-Phase Test. http://xunitpatterns.com/Four%20Phase%20Test.html#:~:text=How%20It%20Works,result%20verification%20and%20fixture%20teardown.

SOLID in PHP

Emmanuel Valverde Ramos — Fri, 25 Sep 2020 07:29:36 +0000

What is SOLID? 🙄

It is a set of principles to have good software design practices compiled by Uncle Bob.

Why should I use them?

Software design principles or conventions.
Widely accepted in the industry.
Help make code more maintainable and tolerant to changes.
Applicable in terms of class design (micro-design), and also at the software architecture level.

If you don't use SOLID, you probably code STUPID¹ without knowing it

¹: STUPID stands for: Singleton, Tight Coupling, Untestability, Premature Optimization, Indescriptive Naming, Duplication

What does SOLID stands for

SOLID is an acronym that stands for:

Single responsibility principle
Open/closed principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle

What do we do

S - Single Responsibility Principle(SRP)

💡 A class should only have one reason to change, which means it should only have one responsibility.

How to accomplish
- Small classes with limited objectives
Purpose or gain:
- High cohesion and robustness
- Allow class composition (inject collaborators)
- Avoid code duplication

Example

Let's imagine we have a class that represents a text document, said document has a title and content. This document must be able to be exported to HTML and PDF.

Violation of the SRP 👎

⚠️ Code coupled with more than one responsibility

class Document
{
    protected $title;
    protected $content;

    public function __construct(string $title, string $content)
    {
        $this->title = $title;
        $this->content= $content;
    }

    public function getTitle(): string
    {
        return $this->title;
    }

    public function getContent(): string
    {
        return $this->content;
    }

        public function exportHtml() {
                echo "DOCUMENT EXPORTED TO HTML".PHP_EOL;
        echo "Title: ".$this->getTitle().PHP_EOL;
        echo "Content: ".$this->getContent().PHP_EOL.PHP_EOL;
        }

        public function exportPdf() {
                echo "DOCUMENT EXPORTED TO PDF".PHP_EOL;
        echo "Title: ".$this->getTitle().PHP_EOL;
        echo "Content: ".$this->getContent().PHP_EOL.PHP_EOL;
        }
}

As you may see the methods or functions that we expose as APIs for other programmers to use, include the getTitle() and the getContent() but these methods are being used within the behavior of the same class.

This breaks the Tell-Don't-Ask principle:

💬 Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do.

Finally, we also see that the class that must represent a document not only has the responsibility of representing it, but also of exporting it in different formats.

Following the SRP Principle 👍

Once we have identified that the Document class should not have anything other than the representation of a "document", the next thing we have to establish is the API through which we want to communicate with the export.

For the export we will need to create an interface that receives a document.

interface ExportableDocumentInterface
{
    public function export(Document $document);
}

The next thing we have to do is extract the logic that does not belong to the class.

class HtmlExportableDocument implements ExportableDocumentInterface
{
    public function export(Document $document)
    {
        echo "DOCUMENT EXPORTED TO HTML".PHP_EOL;
        echo "Title: ".$document->getTitle().PHP_EOL;
        echo "Content: ".$document->getContent().PHP_EOL.PHP_EOL;
    }
}

class PdfExportableDocument implements ExportableDocumentInterface
{
    public function export(Document $document)
    {
        echo "DOCUMENT EXPORTED TO PDF".PHP_EOL;
        echo "Title: ".$document->getTitle().PHP_EOL;
        echo "Content: ".$document->getContent().PHP_EOL.PHP_EOL;
    }
}

Leaving the class implementation something like this

class Document
{
    protected $title;
    protected $content;

    public function __construct(string $title, string $content)
    {
        $this->title = $title;
        $this->content= $content;
    }

    public function getTitle(): string
    {
        return $this->title;
    }

    public function getContent(): string
    {
        return $this->content;
    }
}

This makes it easier for both the exports and the documentation class to be better tested.

O - Open-Closed Principle(OCP)

💡 Objects or entities should be open for extension, but closed for modification.

How to accomplish
- Avoiding depending on specific implementations, making use of abstract classes or interfaces.
Purpose or gain:
- Makes it easy to add new use cases to our application

Examples

Let's imagine that we need to implement a login system. Initially to authenticate our user we need a username and a password (Main use case), so far so good, but what happens if we require or from business require that the user authenticate through Twitter or Gmail?

To begin with, if a situation like this arises, it is important to understand that what is being asked of us is a new feature and not that we modify the current one. And that the case of Twitter would be one use case and that of Gmail another totally different.

Third Party API Login - OCP Violation 👎

class LoginService
{
    public function login($user)
    {
        if ($user instanceof User) {
            $this->authenticateUser($user);
        } else if ($user instanceOf ThirdPartyUser) {
            $this->authenticateThirdPartyUser($user);
        }
    }
}

Login with third party API - Following OCP 👍

The first thing we should do is create an interface that complies with what we want to do and that fits the specific use case.

interface LoginInterface
{
    public function authenticateUser(UserInterface $user);
}

Now we should decouple the logic that we had already created for our use case and implement it in a class that implements our interface.

class UserAuthentication implements LoginInterface
{
    public function authenticateUser(UserInterface $user)
    {
        // TODO: Implement authenticateUser() method.
    }
}

class ThirdPartyUserAuthentication implements LoginInterface
{
    public function authenticateUser(UserInterface $user)
    {
        // TODO: Implement authenticateUser() method.
    }
}

class LoginService
{
    public function login(LoginInterface $loginService, UserInterface $user)
    {
        $loginService->authenticateUser($user);
    }
}

As you can see, the LoginService class is agnostic of which authentication method (via web, via google or twitter, etc).

Payments API implemented with a switch - OCP Violation 👎

A very common case is when we have a switch(), where each case performs a different action and there is the possibility that in the future we will continue adding more cases to the switch. Let's look at the following example.

Here we have a controller with a pay() method, which is responsible for receiving the type of payment through the request and, depending on that type, the payment will be processed through one or another method found in the Payment class.

public function pay(Request $request)
{
    $payment = new Payment();

    switch ($request->type) {
        case 'credit':
            $payment->payWithCreditCard();
            break;
        case 'paypal':
            $payment->payWithPaypal();
            break;
        default:
            // Exception
            break;
    }
}

class PaymentRequest
{
    public function payWithCreditCard()
    {
        // Logic to pay with a credit card...
    }

    public function payWithPaypal()
    {
        // Logic to pay with paypal...
    }
}

This code has 2 big problems:

We should add one more case for each new payment that we accept or delete a case in the event that we do not accept more payments through PayPal.
All the methods that process the different types of payments are found in a single class, the Payment class. Therefore, when we add a new payment type or remove one, we should edit the Payment class, and as the Open / Closed principle says, this is not ideal. Like it is also violating the principle of Single Responsibility.

This violation it's also related to a code smell call Switch Statements Smell if you want to know more about refactors or examples go into refactoring guru

Payments API implemented with a switch - Following OCP 👍

The first thing we could do to try to comply with the OCP is to create an interface with the pay() method.

interface PayableInterface
{
    public function pay();
}

Now we will proceed to create the classes that should implement these interfaces.

class CreditCardPayment implements PayableInterface
{
    public function pay()
    {
        // Logic to pay with a credit card...
    }
}

class PaypalPayment implements PayableInterface
{
    public function pay()
    {
        // Logic to pay with paypal...
    }
}

The next step would be to refactor our pay() method.

public function pay(Request $request)
{
    $paymentFactory = new PaymentFactory();
    $payment = $paymentFactory->initialize($request->type);

    return $payment->pay();
}

👁 As you can see, we have replaced the switch with a factory.

class PaymentFactory
{
    public function initialize(string $type): PayableInterface
    {
        switch ($type) {
            case 'credit':
                return new CreditCardPayment();
            case 'paypal':
                return new PayPalPayment();
            default:
                throw new \Exception("Payment method not supported");
                break;
        }
    }
}

Benefits of the Open / Closed Principle

Extend the functionalities of the system, without touching the core of the system.
We prevent breaking parts of the system by adding new functionalities.
Ease of testing.
Separation of the different logics.

🎨 Design patterns that we can find useful for OCP

Factory - Video
Adapter - Video

L - Liskov Substitution Principle(LSP)

This principle was introduced by the guru and the first woman in America to earn a Ph.D. in Computer Science, Barbara Liskov. And it is a very interesting principle.

According to Wikipedia. Liskov's Substitution Principle says that each class that inherits from another can be used as its parent without having to know the differences between them.

Concepts:
- If S is a subtype of T, instances of T should be substitutable for instances of S without altering the program properties, That is, by having a hierarchy it means that we are establishing a contract in the father, so ensuring that this contract is maintained in the child will allow us to replace the father and the application will continue to work perfectly.
How to accomplish:
- The behavior of the sub-classes must respect the contract established in the super-class.
- Maintain functional correctness to be able to apply OCP.

There are 3 important points that we have to keep in mind in order not to violate the Liskov principle:

Not to strengthen the pre-conditions and not to weaken the post-conditions of the parent class (defensive programming).
The invariants set in the base class must be kept in the subclasses.
Cannot be a method in the subclass that goes against a behavior of the base class. This is called Historical Constraint.

Example

Shipping calculation

Let's say we have a Shipping class that is going to calculate the shipping cost of a product given its weight and destination.

class Shipping
{
    public function calculateShippingCost($weightOfPackageKg, $destiny)
    {
        // Pre-condition:
        if ($weightOfPackageKg <= 0) {
            throw new \Exception('Package weight cannot be less than or equal to zero');
        }

        // We calculate the shipping cost by
        $shippingCost = rand(5, 15);

        // Post-condition
        if ($shippingCost <= 0) {
            throw new \Exception('Shipping price cannot be less than or equal to zero');
        }

        return $shippingCost;
    }
}

Shipping calculation - LSP violation due to behavior change in daughter class 👎

class WorldWideShipping extends Shipping
{
    public function calculateShippingCost($weightOfPackageKg, $destiny)
    {
        // Pre-condition
        if ($weightOfPackageKg <= 0) {
            throw new \Exception('Package weight cannot be less than or equal to zero');
        }

        // We strengthen the pre-conditions
        if (empty($destiny)) {
            throw new \Exception('Destiny cannot be empty');
        }

        // We calculate the shipping cost by
        $shippingCost = rand(5, 15);

        // By changing the post-conditions we allow there to be cases
        // in which the shipping is 0
        if ('Spain' === $destiny) {
            $shippingCost = 0;
        }

        return $shippingCost;
    }
}

The problem is that we generate with a class like the previous one is that we are exposing a similar API for programmers, but that has a different implementation.

This class will be the parent class of our example where its method to calculate the shipping price has a pre and a post condition (this way of programming using the pre and post conditions is called Defensive Programming).

For example, a programmer on our team is sure that the calculateShippingCost() method, of the Shipping class, allows null destination and shipping costs greater than zero, so by wanting to use the WorldWideShipping class, it could cause the system to burst, for example, if you want to use the result of calculateShippingCost() in a slice or by giving it a null destiny.

Therefore, the WorldWideShipping class is violating the Liskov substitution principle.

Shipping calculation - LSP violation due to change of invariants from child class 👎

The invariants are values of the parent class that cannot be modified by the child classes.

Let's say we want to modify the Shipping class that we had before and we want to make the limit of the weight per kilos be 0 but that it is in a variable.

class Shipping
{
    protected $weightGreaterThan = 0;

    public function calculateShippingCost($weightOfPackageKg, $destiny)
    {
        // Pre-condition:
        if ($weightOfPackageKg <= $this->weightGreaterThan) {
            throw new \Exception("Package weight cannot be less than or equal to {$this->weightGreaterThan}");
        }

        // We calculate the shipping cost by
        $shippingCost = rand(5, 15);

        // Post-condition
        if ($shippingCost <= 0) {
            throw new \Exception('Shipping price cannot be less than or equal to zero');
        }

        return $shippingCost;
    }
}

class WorldWideShipping extends Shipping
{
    public function calculateShippingCost($weightOfPackageKg, $destiny)
    {
    // We modify the value of the parent class
        $this->weightGreaterThan = 10;

        // Pre-condition
        if ($weightOfPackageKg <= $this->weightGreaterThan) {
            throw new \Exception("Package weight cannot be less than or equal to {$this->weightGreaterThan}");
        }
    // Previous code...
    }
}

Shipping calculation - Following LSP by change of invariants from child class 👍

The easiest way to avoid this would be to simply create the variable $weightOfPackageKg as a private constant if our version of PHP (7.1.0) allows it but by creating that private variable.

Historical Restrictions

Historical restrictions say that there cannot be a method in the child class that goes against a behavior of its parent class.

That is, if in the parent class there is the FixedTax() method, then the ModifyTax() method cannot exist in the child class. Or didn't they teach you not to disobey your parents? 😆.

For a method of the subclass to modify the value of a property of the base class is a violation of the Liskov principle because classes must be able to change the value of their properties only (Encapsulation).

The easiest way not to break the LSP

The best way not to break LSP is by using Interfaces. Instead of extending our child classes from a parent class.

interface CalculabeShippingCost
{
    public function calculateShippingCost($weightOfPackageKg, $destiny);
}

class WorldWideShipping implements CalculabeShippingCost
{
    public function calculateShippingCost($weightOfPackageKg, $destiny)
    {
        // Implementation of logic
    }
}

By using interfaces you can implement methods that various classes have in common, but each method will have its own implementation, its own pre and post conditions, its own invariants, etc. We are not tied to a parent class.

⚠️ This does not mean that we start using interfaces everywhere, although they are very good. But sometimes it is better to use base classes and other times interfaces. It all depends on the situation.

Interfaces 🆚 Abstract Class

Interface benefits
- Does not modify the hierarchy tree
- Allows to implement N Interfaces
Benefits of Abstract Class
- It allows to develop the Template Method¹ pattern by pushing the logic to the model. Problem: Difficulty tracing who the actors are and when capturing errors
- Private getters (Tell-Don't-Ask principle)

¹. Design pattern Template Method: It states that in the abstract class we would define a method body that defines what operation we are going to perform, but we would be calling some methods defined as abstract (delegating the implementation to the children). But beware! 👀 this implies a loss of traceability of our code.

Conclusion of Interfaces 🆚 Abstract Class

When do we use Interfaces?: When we are going to decouple between layers.
When do we use Abstract?: In certain cases for Domain Models (Domain models not ORM models, to avoid anemic domain models)

🎨 Design patterns that can be useful to us in the LSP

I - Interface Segregation Principle (ISP)

💡 A client should only know the methods they are going to use and not those that they are not going to use.

Basically, what this principle refers to is that we should not create classes with thousands of methods where it ends up being a huge file. Since we are generating a monster class, where most of the time we will only use some of its methods each time. And for that it refers to the need for interfaces, it is also important to understand that this helps a lot at the Single Responsibility Principle(SRP).

How to accomplish
- Define interface contracts based on the clients that use them and not on the implementations that we could have (The interfaces belong to the clients).
- Avoid Header Interfaces by promoting Role Interfaces
Purpose or gain:
- High cohesion and low structural coupling

Header Interfaces

Martin fowler in the article HeaderInterface sustain.

💬 A header interface is an explicit interface that mimics the implicit public interface of a class. Essentially you take all the public methods of a class and declare them in an interface. You can then supply an alternative implementation for the class. This is the opposite of a RoleInterface - I discuss more details and the pros and cons there.

Role Interfaces

Martin fowler in the article RoleInterface sustain.

💬 A role interface is defined by looking at a specific interaction between suppliers and consumers. A supplier component will usually implement several role interfaces, one for each of these patterns of interaction. This contrasts to a HeaderInterface, where the supplier will only have a single interface.

Examples

Simple Example

We want to be able to send notifications via email, Slack, or txt file. What signature will the interface have? 📨

a) $notifier($content) ✔️
b) $notifier($slackChannel, $messageTitle, $messageContent, $messageStatus) ❌
c) $notifier($recieverEmail, $emailSubject, $emailContent) ❌
d) $notifier($destination, $subject, $content) ❌
e) $notifier($filename, $tag, $description) ❌

We can rule out that options B, C and E, since Header Interface would be based on the implementation (for Slack, email and file respectively).

In the case of option D, we could consider it invalid given that the type $destination It does not offer us any specificity (we do not know if it is an email, a channel ...).

Finally, in option A, we would only be sending the content, so the particularities of each of the types of notification would have to be given in the constructor (depending on the use case you could not always).

👁 The interfaces belong to the clients and not to those who implement them.

Example Developer | QA | PM - ISP violation due to excess responsibilities and poor abstraction 👎

A simple example would be the following situation. Let's imagine that we have developers, a QA team and a project manager who have to determine whether to program.

Let's say the programmer can program and test, while the QA can only test.

interface Workable
{
    public function canCode();
    public function code();
    public function test();
}

class Developer implements Workable
{
    public function canCode()
    {
        return true;
    }
    public function code()
    {
        return 'coding';
    }
    public function test()
    {
        return 'testing in localhost';
    }
}

class Tester implements Workable
{
    public function canCode()
    {
        return false;
    }
    public function code()
    {
        // El QA no puede programar
         throw new Exception('Opps! I can not code');
    }
    public function test()
    {
        return 'testing in test server';
    }
}

class ProjectManagement
{
    public function processCode(Workable $member)
    {
        if ($member->canCode()) {
            $member->code();
        }
    }
}

If we pay attention we will see that the Tester class has a method that does not correspond to it since it is not called and if it is called it would give us an Exception.

So we should make a small refactor to be able to comply with the principle of segregation of interfaces.

Example Developer | QA | PM - Following ISP 👍

The first thing is to identify what actions we have to perform, design the interfaces and assign these interfaces to the corresponding actors depending on the use case.

interface Codeable
{
    public function code();
}

interface Testable
{
    public function test();
}

class Programmer implements Codeable, Testable
{
    public function code()
    {
        return 'coding';
    }
    public function test()
    {
        return 'testing in localhost';
    }
}

class Tester implements Testable
{
    public function test()
    {
        return 'testing in test server';
    }
}

class ProjectManagement
{
    public function processCode(Codeable $member)
    {
        $member->code();
    }
}

This code does comply with the principle of segregation of interfaces. As with the previous principles.

🎨 Design patterns that can be useful to us in the ISP

D - Dependency Inversion Principle (DIP)

I must first make it clear that Dependency Injection is NOT the same as Dependency Inversion. Dependency inversion is a principle, while dependency injection is a design pattern.

💡 High-level modules should not depend on low-level ones. Both should depend on abstractions

How to accomplish
- Inject dependencies (parameters received in constructor).
- Rely on the interfaces (contracts) of these dependencies and not on specific implementations.
- LSP as a premise.
Purpose or gain:
- Facilitate the modification and replacement of implementations.
- Better class testability

The principle of dependency injection tries to maintain a low coupling.

Laravel controller example

Let's say we have a UserController. What in its index method what it does is return a JSON list of users with the users created the previous day.

Laravel controller - DIP Violation 👎

public function index()
    {
        $users = new User();
        $users = $users->where('created_at', Carbon::yesterday())->get();

        return response()->json(['users' => $users]);
    }
}

This code wouldn't be bad, because it would clearly work. But at the same time it would generate the following problems:

We cannot reuse the code as we are tied to Eloquent.
It is difficult to test the methods that instantiate one or several objects (high coupling), since it is difficult to verify that it is failing.
It breaks the principle of single responsibility, because, in addition to the method doing its job, it also has to create the objects in order to do its job.

Laravel controller - Following the DIP 👍

interface UserRepositoryInterface
{
    // 👁 I am returning an array
    // but it should return Domain Models
    public function getUserFromYesterday(DateInterface $date): array;
}

class UserEloquentRepository implements UserRepositoryInterface
{
    public function getUserFromYesterday(DateInterface $date): array
    {
        return User::where('created_at', '>', $date)
            ->get()
            ->toArray();
    }
}

class UserSqlRepository implements UserRepositoryInterface
{
    public function getUserFromYesterday(DateInterface $date): array
    {
        return \DB::table('users')
            ->where('created_at', '>', $date)
            ->get()
            ->toArray();
    }
}

class UserCsvRepository implements UserRepositoryInterface
{
    public function getUserFromYesterday(DateInterface $date): array
    {
        // 👁 I am accessing the infrastructure
        // from the same method maybe not the best
        $fileName = "users_created_{$date}.csv";
        $fileHandle = fopen($fileName, 'r');

        while (($users[] = fgetscsv($fileHandle, 0, ","))  !== false) {
        }

        fclose($fileHandle);

        return $users;
    }
}

As we can see, all classes implement the UserRespositoryInterface interface. And this gives us the freedom to get the users either from Eloquent, fromSQL or from a CSV 👏😲 file.

This is fine and would work in a normal application, but how do we make the Laravel controller receive that repository in its index method?

The answer is registering the interface with which class it has by default.

namespace App\Providers;

use Illuminate\Support\ServiceProvider;


class AppServiceProvider extends ServiceProvider
{
    public function register()
    {
        $this->app->bind(
            'App\Repositories\Contracts\UserRepositoryInterface',
            'App\Repositories\UserCsvRepository'
        );
    }
}

In other frameworks like Symfony it can be done using PHP DI.

Conclusions

In order to make a more maintainable, reusable and testable code we should try to implement these principles. Like we should know the design patterns that could be useful when we use these principles.

Webgraphy

🇪🇸

(🇬🇧/🇺🇸)

Design Patterns in Object Oriented Programming