DEV Community: Victor Manuel Pinzon

Serverless on Kubernetes with KNative and EKS

Victor Manuel Pinzon — Fri, 26 Dec 2025 21:53:32 +0000

For a long time, Serverless has been presented as the definitive solution for all your scalability problems. You upload your code and the provider does the rest; you just pay for what you use. The most common serverless model is AWS Lambda, which is one the early drivers of this work model.

However, there are some edge cases where we are not allowed to lock in with a specific provider, and at the same time we need to benefit from the serverless model.

When we start a new project, there is always a common question: "Do we use Kubernetes or Serverless?". This post will try to give you a new question "How about serverless on Kubernetes?"

What's the deal with Serverless?

There is always a misconception that serverless means "no servers", but that cannot be further from the truth. It just means that we transfer the operational workload to the provider. The developer will focus only on business logic, while the provider will focus on scaling, routing, and availability.

When we talk about Serverless, we talk about:

Scaling under demand.
Automatic Scale-to-zero when there is no demand.
Development experience centered
Resource optimization.

There is always a catch with all these. In order to transfer the operational workload to a provider, you must lock-in with a specific technology, and there is not always a happy ending with lock-in.

Why implementing Serverless on Kubernetes?

Kubernetes has become the de facto standard to deploy data high-intensive applications. Not just for containers, but for the whole ecosystem that includes observability, security, networking, politics and governance.

K8s --for simplicity-- is an strategic investment. It means that everything is built around k8s, such as clusters, pipelines, CI/CD, security controls, operative models, and event dev/ops teams.

K8s does not offer serverless natively. It was not built to deal with this type of workload. However, it does not mean that we cannot tweak our cluster to work as a serveless provider without locking in with a specific provider, and here is where Knative enters.

Knative: Serverless on Kubernetes

Knative is an abstraction layer that turns your k8s cluster into a real serverless platform.

Knative introduces into your cluster the following features:

Real Scale-to-zero.
Smart routing (canary, blue/green).
Automatic versioning.
Event Driven architecture capabilities.
An experience based on "deploy and execute".

Knative Pillars:

There are three main pillars on Knative. They are in charge of turning your k8s cluster into a serverless platform.

Knative Serving: It is the component in charge of loading and executing your serverless applications on kubernetes. This layer abstracts all the native resources such as Deployments, Services, Ingress, and allows the developer to focus only on their application. It allows automatic scaling -- including scale to zero --, versioning, endpoint exposition.
Knative Eventing: It brings event-driven capabilities into the table, allowing services to be triggered without coupling. Main features of this layer are decoupling between producers and consumers, multiple source events (HTTP, Kafka, RabbitMQ), etc.
Knative Functions: Allows FaaS (Functions as a Services) on k8s, centered on the developers.

Proof Of Concept

I developed a Proof Of Concept (POC) in order to show the benefits of implementing serveless functions on your k8s cluster. I used an Amazon EKS cluster and I deployed the Knative layer upon it.

The POC deploys a minimalist API without defining Deployments, Services, or Ingress. All these Kubernetes native objects are managed by Knative. The POC includes:

Automatic scaling based on HTTP trafic -- including scale to zero --.
Endpoint exposition to internet using Kourier as network controller.
End-to-end flow from creating the kluster to your application deployment.

Source code: Serveless with Knative

EKS

One of the most important things about this POC is that does not use Minikube or Kind, but a real-life Amazon EKS cluseter, which means:

We built the POC under real-life circumstances on a high-availability environment with scalable nodes.
EKS takes the responsability of node orchestration, IAM integration, VPCs and load balancers.
We use eksctl to create and configure the cluster using IaC.

Conclusion

Knative brings the serverless model into Kubernetes, offering an abstraction layer and simplifying deployment, automatic scaling, and routing on cloud-native applications. Knative allows the developers to focus only on their application, while the platform is in charge of auto-scaling, scale-to-zero, and routing. These features make Knative building block for organizations that are searching for flexibility, portability and efficiency without sacrificing their infraestructure.

Scaling Kubernetes Load with KEDA

Victor Manuel Pinzon — Sun, 14 Dec 2025 06:12:16 +0000

In multiple projects, I have found myself asking the same question: Why is the HPA not scaling my pods when it is clearly needed? The answer is actually very simple—HPA only scales based on CPU or memory utilization, and that does not always reflect real-world workloads. What happens when we need to scale an application using different types of metrics, such as requests per second, queue depth, or even the result of a database query?

That's where KEDA comes into play.

On June 14, 2025, I participated in KCD Guatemala 2025, where I spoke about scaling applications on Kubernetes using KEDA. My experience working on multiple data-intensive and highly irregular workloads has shown me that this is an especially relevant topic for anyone—whether beginner or experienced—who works with any flavor of Kubernetes.

KEDA

KEDA is an excellent tool that complements the Kubernetes ecosystem. It monitors external events—such as endpoints, message queues, Prometheus or Grafana metrics, SQL queries, and HTTP traffic—and transforms these signals into metrics that Kubernetes can understand and use for scaling decisions. The Horizontal Pod Autoscaler remains responsible for scaling the application, but it now receives metrics that more accurately represent the real application load.

This enables a very powerful capability: scaling workloads down to zero when there is no traffic and automatically scaling pods back up as events arrive. It is a simple pattern, yet one that can dramatically improve operational efficiency.

KEDA Arquitecture

KEDA architecture is very interesting because it does not replace HPA, instead it allows a very ellegant scaling flow.

Keda integrates natively into a Kubernetes cluster to enable event-driven autoscaling without changing how Kubernetes fundamentally works. The process starts with a ScaledObject, a custom resource that defines which workload should scale and which external event source should drive that scaling. This definition is registered through the Kubernetes API Server, just like any other native resource. Inside the cluster, KEDA countinuously observes the external trigger process, such as message queue, HTTP Traffic or a monitoring system, usually using specialized scalers. When events are detected, KEDA´s controller evalutates the workload demand and exposes the correspoding metric throud its metrics adapter. These metris are then consumed bu the HPA, which reamins the only component responsible for scaling pods. When events are not present, KEDA allows the workload to scale down to zero, and when events are no present. KEDA allows the workload to scale down to zero, and when events reappear to scale back up. The application itself remains unchangend, making KEDA a clean and powerful extension that connects kubernetes autoscaling with real-world event sources.

Proof of Concept

In the proof of concept that was presented on KCD Guatemala 2025, I showcased how kubernetes workloads can be automatically scaled based on real HTTP traffic using KEDA. The PoC included a lightweight sample application, KEDA HTTP add-on configuration, ScaledObject definitions, and Kubernetes manifests that together demonstrate event-driven autoscaling from zero to multiple replicas and back down when traffic stops. It alos includes scripts and instructions to generate load and observe sclaing behaviour in real time, making it easy to understand how KEDA integrages with the Horizontal Pod Autoscaler under the hood. The objective is not to build a production-ready system, but to prived a clear, hands-on example of how event-based autoscaling works in procative within a Kubernetes cluster.

The complete setup, source code, and documentation is available on Gitub at keda-demo-kcd

Building Explainable Fraud Detection With Amazon Sagemaker and Bedrock

Victor Manuel Pinzon — Thu, 23 Oct 2025 23:20:52 +0000

On October 18 2025, I had the pleasure of giving a presentation at AWS Community Day about Transactional Fraud Detection using AWS SageMaker and Bedrock. The purpose of this post is to expand on the technical context of that presentation.

Why Fraud Detection Needs to Evolve

Transactional fraud detection is a key security priority for every bank and financial institution, helping to protect both customers’ trust and reputation as an organization. Banks process millions of transactions every day, each of which could be either legitimate or malicious.

Traditional machine learning models can classify transactions effectively, some better than others, but they fall short in explainability:

Why was this transaction flagged?
What features contributed most to the classification?
How can we justify these decisiones to business, security or compliance teams?

That lack of interpretability creates friction among teams within the organization. This POC (Proof Of Concept) looks to bridge that gap by combining predictive Machine Learning and Generative AI.

Machine Learning meets GenAI: A Hybrid Architecture

During the AWS Community Day Guatemala 2025, I presented a live demo integrating:

Amazon Sagemaker for Machine Learning model training and inference.
Amazon Bedrock (Claude 3) for natural language and explanations.
Gradio for a quick and interactive web interface.

The goal was to build an end-to-end pipeline where AWS SageMaker detects fraud transactions and explains why.

High-Level Architecture

Dataset
I used a dataset that was originally published on Kaggle. It contains 284,807 real transactions made by European cardholders over two day period on 2023, of which 492 were fraudulent (0.17%)

Due to confidentiality restrictions, all numerical features were transformed using the PCA method (Principal Component Analysis), which ensures privacy but preserves the statistical data, which means it has the same weight and meaning for the model.

For demonstration purposes, I created a balanced subset of the dataset and stored it in Amazon S3, which was sampled and preprocessed directly in AWS SageMaker. The main objective was to maintain this POC under the free tier but also maintaining the representative patterns of both legitimate and fraudulent behavior.

Pipeline overview:

The dataset is downloaded from Kaggle and stored in Amazon S3.
I created a balanced subset of the credit card transactions from Kaggle.
A SageMaker XGBoost model is trained to classify fraud vs non-fraud trasactions.
The model is stored in Amazon S3.
For demonstration purposes, the model is loaded in a separate notebook which tests the model by ingesting it using a small sample. In a real life implementation, this would be a re-usable Lambda function.
The function invokes Amazon Bedrock with a structure prompt describing key features of the transaction.
Bedrock generates a human readable explanation.
I created a Gradio interface that dispalys the prediction and the explanation interactively.

XGBoost Model
The Extreme Gradient Boosting (XGBoost) is a classical Machine Learning Model, which is a tree-based algorithm optimized for accuracy and performance. It works sequentially building decision trees, where each new tree corrects the residual errors of the previous ones. XGBoost is mostly used in fraud detection systems, recommendation systems, and dynamic pricing.

Model Training in SageMaker
The dataset contains 285,000 real life anonymized transaction with only 0.17% are fraud cases. This is not suitable for a fraud detection system because it creates a bias in the model. We need to feed the model with approved transaction as the same than fraudulent transaction.

So I first created a balanced subset:

def make_miniset(df, pd, ratio=1, seed=42):
    fraud = df[df["Class"]==1]
    normal = df[df["Class"]==0].sample(n=len(fraud)*ratio, random_state=seed)
    mini = pd.concat([fraud, normal]).sample(frac=1, random_state=seed)
    return mini

Then I trained an XGBoost classifier in Sagemaker

 #Entrena el modelo XGBoost
 model = XGBClassifier(
     n_estimators=50, max_depth=4, learning_rate=0.1,
     subsample=0.8, colsample_bytree=0.8, random_state=seed
 )
 model.fit(Xtr, ytr)

 #Genera las prediciones acorde al modelo
 yhat = model.predict(Xte)

The model reached 98.6% accuracy on the balanced dataset.

Model Training in SageMaker
Each transaction was enriched with contextual signals before invoking the LLM:

"""
Devuelve una lista de señales legibles para un registro.
"""
def derive_signals_from_row(row: pd.Series, stats: pd.DataFrame, v_cols: List[str]) -> List[str]:

    signals: List[str] = []

    # Monto
    if "Amount" in row:
        amount = float(row["Amount"])
        signals.append(f"Monto {classify_amount(amount)} (~{amount:.2f}).")

    # Hora
    if "Time" in row:
        hour, bucket = time_bucket(float(row["Time"]))
        signals.append(f"Horario: {bucket} (~{hour:02d}:00).")

    # Z Score
    outs = []
    for c in v_cols:
        try:
            z = abs(zscore(stats, c, float(row[c])))
            if z > Z_THRESHOLD:
                outs.append((c, round(z, 2)))
        except Exception:
            continue

    outs.sort(key=lambda x: x[1], reverse=True)
    if outs:
        outs_txt = ", ".join([f"{c}(|z|~{z})" for c, z in outs[:3]])
        signals.append(f"Componentes atípicos: {outs_txt}.")

    return signals

Then, Bedrock (Claude 3) is called:

'''
Función encarga de generar el prompt a AWS Bedrock
'''
def explain_tx(br_client, model_id, tx_dict, prob, pred):

    if pred == 1:
        intent = "Explica brevemente (2-3) líneas por qué esta transacción podría ser fraudulenta."
    else:
        intent = "Explica brevemente (2-3) kíneas por qué esta transacción parece normal."

    prompt = (
      "Eres un analista de fraude bancario. "
      f"{intent} "
      f"Probabilidad de fraude: {prob:.2f}. "
      f"Predicción del modelo: {'Fraude' if pred == 1 else 'Normal'}."  
      f"Datos: {tx_dict}"
    )
    body = {
      "anthropic_version":"bedrock-2023-05-31",
      "max_tokens": 320,
      "messages":[{"role":"user","content":[{"type":"text","text":prompt}]}]
    }
    resp = br_client.invoke_model(
      modelId=model_id, contentType="application/json",
      accept="application/json", body=json.dumps(body)
    )
    out = json.loads(resp["body"].read())
    return out["content"][0]["text"]

Output example

Con una probabilidad de fraude de 0.91 y una predicción del modelo de "Fraude", esta transacción presenta los siguientes signos de posible fraude:

El monto de la transacción es alto, aproximadamente $451.27, lo cual puede ser un indicador de actividad sospechosa.

La transacción se realizó en horario de madrugada, alrededor de las 00:00, lo cual es inusual para la mayoría de las actividades bancarias legítimas.

Estos factores, junto con la alta probabilidad de fraude y la predicción del modelo, sugieren que esta transacción debe ser revisada más a fondo para descartar o confirmar la presencia de actividades fraudulentas.

Output example (translation)

With a fraud probability of 0.91 and a model prediction of "Fraud", this transaction shows the following signs of potential fraudulent activity:

The transaction amount is high — approximately $451.27, which may indicate suspicious behavior.

The transaction occurred during early morning hours, around 00:00, which is unusual for most legitimate banking activities.

These factors, combined with the high fraud probability and the model’s prediction, suggest that this transaction should be further reviewed to confirm or rule out fraudulent activity.

Demo Interface

Results

Accuracy: 98.6%
Inference time: < 100ms
Explanation time> 0.5 - 1 s via Bedrock
Cost: Under free tier

Github Repositoy

ML GenAI Github repo

Final Thoughts

Delivering this demo at AWS Community Day Guatemala 2025 was more than a presentation, it was a statement that explainability is the new challenge on AI.

As AI Systems become central to decision making, transparency isn't optional. It's the foundation for trust, compliance and adoption for any enterprise that wants to adopt AI.

Singleton Pattern

Victor Manuel Pinzon — Tue, 19 Oct 2021 18:34:24 +0000

I bet you heard of the Singleton Pattern before, and it doesn't surprise me, because this pattern has been built into so many frameworks nowadays, mostly because it's one the simplest to implement. But what is Singleton Pattern and what problem does it solve?

Definition

According to GoF, Singleton Pattern ensures a class has only one instance and provides a global access to it.

Perfect, why would I need a single instance of a class? Suppose that you have a Logger class that records all your application activity. You don't need to instantiate different objects of the same logger in all your classes, you just need one instance and a means to access it. Another example would be to reduce the use of global variables, so instead of using an excessive number of global variables, you could just create an object using the Singleton Pattern.

Benefits

There are many benefits of the application of this pattern:

There is controlled access to the sole instance of your class.
It reduces the excessive use of global variables, which is a bad practice.
It's easy to maintain because it provides a single point of access.
It can be lazy or eager loading.
It can be thread-safe.

Application

The Singleton Pattern can be applied in any of the following cases:

Class instantiation is resource expensive to perform.
Global variables reduction.
By design you must have a sole object of a given class.

Implementing The Singleton Pattern:

To apply the Singleton Pattern in a specific class we must do the following:

Create a private constructor.
Define a global static object where we'll store our sole instance.
Define a static method where we can retrieve the object.
The method will check if the instance is created. If it's not, it will create it.

There are four different ways of implementing the Singleton Pattern, let's take a look at each one of them:

Lazy Initialization of Singleton Pattern

On this variant of the Singleton Pattern, the instance is created until is requested by the getInstance() method. Before that, there is no instance of the class. This is helpful because we don't consume any resources if it's not necessary. Let's see the following example.

public class LoggerSingletonLazy {

    //Sole instance
    private static LoggerSingletonLazy instance;

    //Private constructor
    private LoggerSingletonLazy(){}

    /**
     * Gets the LoggerSingletonEeager instance
     *
     * @return 
     */
    public static LoggerSingletonLazy getInstance(){

        /*Checks if instance is created, if it's not if*/
        if(instance == null){
            instance = new LoggerSingletonLazy();
        }

        return instance;
    }
}

To apply the Singleton Pattern on the LoggerSingletonLazy class, we did the following:

We defined a private constructor so that it cannot be instantiated outside the class itself.
We defined a static variable where we'll store the sole instance of the LoggerSingletonLazy class.
We defined a static method where we can retrieve the sole instance of the class. If there is no instance on the first call, the method will create the object and return it.

We can test if the LoggerSingletonLazy class is returning the same object.

public class App {

    public static void main(String[] args){
        LoggerSingletonLazy firstLog = LoggerSingletonLazy.getInstance();
        System.out.println("First Log Instance: " + firstLog.hashCode());

        LoggerSingletonLazy secondLog = LoggerSingletonLazy.getInstance();
        System.out.println("Second Log Instance: " + secondLog.hashCode());

        LoggerSingletonLazy thirdLog = LoggerSingletonLazy.getInstance();
        System.out.println("Third Log Instance: " + thirdLog.hashCode());
    }
}

We retrieve an instance of the LoggerSingletonLazy class in three different times and save it in three different variables. We check the hash code to validate if the three variables point to the same object.

Let's see the output of this program:

First Log Instance: 7059277765
Second Log Instance: 7059277765
Thord Log Instance: 7059277765

The three hash codes are the same, so all the variables point to the same object. Therefore, the Singleton Pattern is correctly applied to the class.

Eager Initialization of Singleton Pattern

Now, let's suppose we want to create an instance of the object on the application startup, this is known as eager initialization. It can be helpful for the initial configuration of an object. Let's see an example of this.

public class LoggerSingletonEager {

    //Sole instance
    private static final LoggerSingletonEager INSTANCE;

    //Eager initialization
    static{
        INSTANCE = new LoggerSingletonEager();
    }

    //Private constructor
    private LoggerSingletonEager(String loggerName){}


    public static LoggerSingletonEager getInstance(){
        return INSTANCE;
    }

}

The difference between this implementation and the previous one is that the object is created in the "static" method, which is executed on the application startup. On this implementation, the "getInstance()" method only retrieves and returns the instance created in the static method.

Singleton Pattern - Thread Safe

There is a potential flaw with the previous designs. Let's suppose that two different threads enter the "getInstance()" method at the same time. Both of them will detect that the instance variable is null, so both will instantiate different objects. This means that our getInstance method is not thread-safe.

Let's change it:

public class LoggerSingletonThreadSafe {

    //Sole instance
    private static LoggerSingletonThreadSafe instance;

    //Private constructor
    private LoggerSingletonThreadSafe(){}

    //Thread safe method
    public synchronized static LoggerSingletonThreadSafe getInstance(){
        if(instance == null){
            instance = new LoggerSingletonThreadSafe();
        }

        return instance;
    }

}

We use the synchronized keyword to make our getInstance method thread-safe. This means if two or more threads try to access the method at the same time, they will have to do it one at a time.

Singleton Pattern - Double Thread Safe

Most of the time the getInstance method will just retrieve the object, so there is no point in synchronizing the whole method. We just need to synchronize the part of the method where the object is created. Let's change it.

public class LoggerSingletonThreadSafeDouble {

    //Sole instance
    private static LoggerSingletonThreadSafeDouble instance;

    //Private constructor
    private LoggerSingletonThreadSafeDouble(){}


    public static LoggerSingletonThreadSafeDouble getInstance(){
        if(instance == null){

            synchronized(LoggerSingletonThreadSafeDouble.class){
                instance = new LoggerSingletonThreadSafeDouble();
            }
        }

        return instance;
    }

}

We only synchronized the part of the code where the object is created. This is helpful on those objects where the getInstance method does different things besides just retrieving the object.

Conclusion:

The Singleton Pattern is handy when an object instantiation is resource expensive to perform or by requirement, you must have a sole instance of a class. No matter what the reason is, remember that Singleton is just a best practice and it doesn't have to be your only solution when creating objects. Just like any pattern, learn first the specific cases where you can apply the pattern and then learn the syntax.

Most Common Design Patterns

Victor Manuel Pinzon — Tue, 19 Oct 2021 16:30:00 +0000

Welcome to this new eight part series where we'll discuss about one of the most influential and controversial topics in programming, which is design patterns.

You may be familiar with the term, I can even bet that you've heard a workmate or a colleague talking about Design Patterns before. But, what are they and what benefits bring to the table? Let's take a look.

Design Patterns

A design pattern is a reusable solution to a recurring problem within a given context. It means, they are well tested solutions to general problems in software porgramming, they're usually regarded as best practices by some experts.

Design Patterns were officially presented in the book "Design Patterns - Elements of Reusable Object-Oriented Software" which was written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. The authors are also known as Gang of Four (GoF).

There were originally 23 Desing Patterns specified by GoF. However, with new programming paradigms and new programming stacks releasing more frequently, we currently don't know the official amount but we expect a much higher number.

Design Patterns can be classified in three main categories:

Creational Patterns: They deal with object creation mechanisms.
Structural Patterns: They help designing large structures.
Behavioral Patterns: They are concerned with algorithms and assigment of responsibilities.

Benefits

The main benefit of Design Patterns is that they provide well-tested solutions to known problems. However, we can also list the following benefits:

They provide a common language and jargon for programmers. For instance, when a programmer states that he/she implemented "X" pattern in a given class it's usually common knowledge for the rest of the team.
They help you write code faster by implementing well-known and testable solutions.
They help you write more legible and maintainable code.

Criticism

Some experts claim that Design Patterns introduce innecesary complexity into your code. This is partially true, Design Patterns have developed some kind of "lazyness" in programmers because they won't look for more simple solutions before going straight to desing patterns, this is specially true on junior developers. Rememeber, there must be a "common" context for using a desing patterns and even then, we must try to look for simpler solutions before implementing a new Design Pattern that you just read.

Design Patterns are good practices, well tested solutions to common problems. They are not some magic recipe to solve all our problems. It's up to you to decide where you apply a specific pattern and how to accommodate it to your chosen language, framework and solution.

Most common Design Patterns

We'll explore the most common and used patterns:

Singleton
Strategy
Observer
Factory
Adapter
Builder
State

In the next post, we will talk about the Singleton Pattern.

SOLID: Dependency Inversion Principle

Victor Manuel Pinzon — Tue, 03 Aug 2021 16:35:50 +0000

This is the last article about the SOLID principles and in my opinion the most important one. Dependency Inversion is the foundation for one of the most useful features implemented by so many frameworks nowadays, which is Dependency Injection. This SOLID principle gives your architecture the necessary flexibility to achieve separation of concerns between layers and it's a concept that every developer should know.

Definition

Robert C. Martin defines DI as follows:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend on abstractions.

High and Low-level modules:

To fully understand the dependency inversion principle, we should first understand the concept of high and low-level modules.

A software module is a coding unit that contains one or more routines. Regularly a module has just one responsibility in the whole system. You build a system using multiple modules, which can be grouped in different layers. Let's have a graphic example of this:

In this example, there are five different modules, we have the Calculator module, as well as the Add, Subtract, Multiply and Divide module.

When we talk about high-level modules, we're talking about modules that are directly used or instantiated by the presentation layer. In our example, there is just one high-level module which is the Calculator class. Low-level modules, on the other hand, help the high-level modules to accomplish their work, typically we refer to these modules as dependencies. In our example, the low-level modules are the Add, Subtract, Multiply, and Divide classes.

Dependencies and Coupling

As mentioned in the previous paragraph, dependencies are established when a module uses another module to complete its work. For instance, the Calculator module needs the Add module to achieve its goal, so a dependency is established.

Coupling is the degree of interdependence between two modules, it's a measure of how closely connected they are. When this connection is strong and we cannot change one part of the dependency without affecting the other part, we say there is a tight coupling. On the other hand, if we can change one part of the dependency without affecting the other part, we say there is a loose coupling.

We should always avoid tight coupling because it violates the Open/Closed Principle by not allowing to modify one side of the dependency without affecting the other one.

Applying The Dependency Inversion Principle

There is one fundamental flaw with the Calculator System design, there is a tight coupling between Calculator and the rest of the low-level modules. We cannot modify any of the operation modules without modifying the Calculator module. Additionally, if we want to add another operation, square root, for example, we also have to modify the Calculator class which violates the Open/Closed Principle. So, how do we fix this design issue? Easy, applying the Dependency Inversion Principle.

The first segment of our principle says "High-level modules should not depend on low-level modules. Both should depend on abstractions". In our current design, the Calculator module depends on the Add, Subtract, Divide and Multiply module. To comply with the DI, we must define an abstraction named "CalculatorOperation". Both, high and low-level modules will depend on this abstraction.

The second segment of the DIP principle says "Abstractions should not depend upon on details. Details should depend on abstractions". To accomplish this rule, we must define the abstraction as an interface (abstraction), not as a class (detail).

Now there is loose coupling between the Calculator module and the Operations modules. Now you can change one side of the dependency without affecting the other side. You can also add more operations, as long as they implement the Operation abstraction, without affecting the Calculator module.

Coding example

Bad Design

Each calculator operation is represented as a low-level module:

public class AddOperation {

    /**
     * Adds two numbers.
     * @param numA          First number.
     * @param numB          Second number.
     * @return              Result.
     */
    public double add(double numA, double numB){
        return numA + numB;
    }
}

public class SubtractOperation {

    /**
     * Subtracts two numbers.
     * @param numA          First number.
     * @param numB          Second number.
     * @return              Result.
     */
    public double subtract(double numA, double numB){
        return numA - numB;
    }
}

public class MultiplyOperation {

    /**
     * Multiplies two numbers.
     * @param numA          First number.
     * @param numB          Second number.
     * @return              Result.
     */
    public double multiply(double numA, double numB){
        return numA * numB;
    }
}

public class DivideOperation {

    /**
     * Divides two numbers.
     * @param numA          First number.
     * @param numB          Second number.
     * @return              Result.
     */
    public double divide(double numA, double numB){
        return numA / numB;
    }

}

The violation of the Dependency Inversion Principle is noticeable in the Calculator class. If we want to add a new calculator operation, we must modify the Calculator class, which violates the Open/Closed principle.

public class Calculator {

    public enum Operation{
        ADD, SUBTRACT, MULTIPLY, DIVIDE
    }


    /**
     * Performs a two numbers operation.
     * @param numA              First number.
     * @param numB              Second number.
     * @param operation         Type of operation.
     * @return                  Operation's result.
     */
    public double calculate(double numA, double numB, Operation operation){

        double result = 0;

        switch(operation){

            case ADD:
                AddOperation addOp = new AddOperation();
                result = addOp.add(numA, numB);
                break;
            case SUBTRACT:
                SubtractOperation subOp = new SubtractOperation();
                result = subOp.subtract(numA, numB);
                break;
            case MULTIPLY:
                MultiplyOperation multOp = new MultiplyOperation();
                result = multOp.multiply(numA, numB);
                break;
            case DIVIDE:
                DivideOperation divOp = new DivideOperation();
                result = divOp.divide(numA, numB);
                break;

        }

        return result;

    }
}

To solve this issue and comply with the DIP and OCP, we must add an abstraction and modify the dependencies, so both, high and low-level modules depend on the abstraction.

Good Design

public interface CalculatorOperation {

    public double calculate(double numbA, double numB);

}

public class AddOperation implements CalculatorOperation {

    @Override
    public double calculate(double numbA, double numB) {
        return numbA + numB;
    }   
}

public class SubtractOperation implements CalculatorOperation {

    @Override
    public double calculate(double numbA, double numB) {
        return numbA - numB;
    }
}

public class MultiplyOperation implements CalculatorOperation {

    @Override
    public double calculate(double numbA, double numB) {
        return numbA * numB;
    }  
}

public class DivideOperation implements CalculatorOperation {

    @Override
    public double calculate(double numbA, double numB) {
        return numbA / numB;
    }
}

Now the Calculator class complies with the Dependency Inversion Principle.

public class Calculator {

    /**
     * Performs a two numbers operation.
     * @param numA              First number.
     * @param numB              Second number.
     * @param operation         Type of operation.
     * @return                  Operation's result.
     */
    public double calculate(double numA, double numB, CalculatorOperation operation){
        return operation.calculate(numB, numB);
    }
}

Final thoughts

We've gone through the five SOLID principles, you've seen the benefits and disadvantages of each one. Remember that SOLID principles were thought to help you achieve flexibility, readability, and reusability. Some of these principles are the cornerstone of multiple frameworks and architectures and you will benefit from implementing them. But, also remember that excessive or incorrect use of these principles will overcomplicate your code. You must evaluate each use case and decide which is best for your solution.

If you like to read more about DIP, you can have a look at Martin Fowler’s Blog.

SOLID: Interface Segregation Principle

Victor Manuel Pinzon — Mon, 24 May 2021 21:54:43 +0000

This principle was developed by Robert C. Martin while working at Xerox as a consultant. Martin was in charge of developing a new printing management system that could carry out tasks concurrently, which was new by the time.

While developing this new printing system, Martin noticed that small changes in the design caused large-scale deployments. In some same cases caused deployments on modules out of the scope of the change. The problem was mainly caused by a large fat interface used throughout all the modules of the system.

The solution given by Robert C. Martin is what we now know as Interface Segregation Principle (ISP). Which is defined as follows:

Clients should not be forced to depend upon interfaces that they do not use.

This principle is simple and clear, classes should not be forced to implement methods that they do not use. The main goal, just like the Single Responsibility Principle, is to limit the scope of future changes.

Typical Violation of the Principle

Let's suppose that you are the person in charge of developing a new printing system for a new brand of all-in-one printers. This is a brand new system, so you have to design it in a way that you can add new printers to the brand without changing the whole system.

The new printers allow the following capabilities:

Printing
Scanning
Faxing

You define the AllInOneLXPrinter interface to model the basic tasks that a new printer can carry out.

public interface AllInOneLXPrinter {


    public boolean print();

    public boolean scan();

    public boolean fax();
}

You define your first printer class, as follows.

public class LX8578Printer implements AllInOneLXPrinter {

    @Override
    public boolean print() {
        //Logic for printing 
        return true;
    }

    @Override
    public boolean scan() {
        //Logic for scanning
        return true;
    }

    @Override
    public boolean fax() {
        //Logic for faxing
        return true;
    }

}

Please take into account that any of these classes have a real-world implementation. They are just used to simplify the example.

The new printing system is a success commercially and technically, as well as the new brand of printers. After the release of multiple all-in-one printers of the same brand, your boss asks you to work on a new economic printer under the same brand. The difference is that this new printer will have fewer functionalities. As a matter of fact, this printer will only allow printing and scanning.

Considering that this new printer will be marketed under the same brand, you decide to use the same interface.

You define the following class for the new economic printer.

public class LX8590Printer implements AllInOneLXPrinter {

    @Override
    public boolean print() {
        //Logic for printing
        return true;
    }

    @Override
    public boolean scan() {
        //Logic for scanning
        return true;
    }

    @Override
    public boolean fax() {
        throw new UnsupportedOperationException("Faxing not supported."); 
    }

}

This is where the violation of the principle happens. The LX8590Printer depends on a method that will never use. This new printer doesn't allow faxing, so it has to throw an exception instead.

Complying with the Interface Segregation Principle

The main problem with the example above is that we use a general fat interface, instead of specialized interfaces. To solve this problem, we have to segregate the fat interface into three different interfaces.

AllInOneFaxing
AllInOneScanning
AllInOnePrinting

public interface AllInOneFaxing {

    public boolean fax();
}

public interface AllInOnePrinting {

    public boolean print();
}

public interface AllInOneScanning {

    public boolean scan();
}

We modify the first printer class _LX8578Printer _, so it can use the specialized interfaces.

public class LX8578Printer implements AllInOnecanning, 
        AllInOneFaxing,
        AllInOnePrinting{

    @Override
    public boolean print() {
        //Logic for printing
        return true;
    }

    @Override
    public boolean scan() {
        //Logic for scanning
        return true;
    }

    @Override
    public boolean fax() {
        //Logic for faxing
        return true;
    }

}

Now we can define our LX8590Printer without depending upon any method that will never use.

public class LX8590Printer implements AllInOneScanning, 
        AllInOnePrinting{

    @Override
    public boolean print() {
        //Logic for printing
        return true;
    }

    @Override
    public boolean scan() {
        //Logic for scanning
        return true;
    }

}

Now our solution complies with the Interface Segregation Principle.

Difference between Interface Segregation Principle and Liskov Substitution Principle

Some developers may get confused when trying to find the differences between ISP and LSP, but they are completely different. LSP focuses on honoring the contract established by an abstract class, by using subtyping and inheritance. On the other hand, ISP focuses on segregating fat interfaces into specialized interfaces, so a class won't depend on interfaces that won't use.

When to use Interface Segregation Principle

This principle, as same as the Single Responsibility Principle, has the main goal of limiting the scope of future changes. However, it is very difficult, in the first iterations, to identify the critical parts of your solution that will violate the principle. So, my advice is to wait for your code to evolve, so you can identify where you can apply it. Don't try to guess future requirements because there is a chance that you make your code more complicated.

If you like to read more about ISP, you can have a look at Uncle Bob’s Blog.

SOLID: Liskov Substitution Principle

Victor Manuel Pinzon — Tue, 27 Apr 2021 18:44:28 +0000

This is a continuation of the SOLID principles series.

The Liskov substitution principle is the most technical principle of all. However, it is the one that most helps to develop decoupled applications, which is the foundation of designing reusable components.

Barbara Liskov defined this principle as follows:

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T”

The definition given by Liskov is based on the Design by Contract (DbC) defined by Bertrand Meyer. A contract that is identified by preconditions, invariants, and postconditions:

A routine can expect a certain condition to be guaranteed on entry by any client module that calls it: the routine’s precondition. This is an obligation for the client and benefit for the supplier, as it frees it from having to handle cases outside of the precondition.
A routine can guarantee a certain property on exit: the routine’s postcondition - an obligation for the supplier, and a benefit for the client.
Maintain a certain property, assumed on entry and guaranteed on exit: the class invariant.

The concept of contract and implementation is the foundation for inheritance and polymorphism in object-oriented programming.

In 1996, Robert C. Martin redefined the concept given by Liskov, as follows:

Function that use pointers of references to base classes must be able to use objects of derived classes without knowing it.

The redefinition given by Bob Martin helped to simplify the concept implemented by Liskov years before and its adoption by developers.

Violation of the Liskov Substitution Principle

As a developer for a banking entity, you are requested to implement a system for managing bank accounts. Your boss asks you to implement, in the first sprint of the project, a system for managing basic and premium bank accounts. The difference between them is that the latter accumulates preference points on any deposit.

You implement the following abstract class as the foundation of your system.

public abstract class BankAccount {

    /**
     * In charge of depositing a specific amount into the account.
     * @param amount            Dollar ammount.
     */
    public abstract void deposit(double amount);

    /**
     * In charge of withdrawing a specific amount from the account.
     * @param amount            Dollar amount.
     * @return                  Boolean result.
     */
    public abstract boolean withdraw(double amount);
}

This abstract class defines an obligation for any derived class to override any abstract method defined in the BankAccount class. This means that the basic and premium accounts must override the deposit and withdrawal method.

public class BasicAccount extends BankAccount {

    private double balance;

    @Override
    public void deposit(double amount) {
        this.balance += amount;
    }

    @Override
    public boolean withdraw(double amount) {
        if(this.balance < amount)
            return false;
        else{
            this.balance -= amount;
            return true;
        }       
    }
}

public class PremiumAccount extends BankAccount {

    private double balance;
    private int preferencePoints;

    @Override
    public void deposit(double amount) {
        this.balance += amount;
        accumulatePreferencePoints();
    }

    @Override
    public boolean withdraw(double amount) {
         if(this.balance < amount)
            return false;
        else{
            this.balance -= amount;
            accumulatePreferencePoints();
            return true;
        }
    }

    private void accumulatePreferencePoints(){
        this.preferencePoints++;
    }

}

Please take into account that any of these classes have the minimum validations for a production environment.

All basic and premium accounts are discounted by $25.00 annually for administrative expenses. To implement this policy you defined the following class:

public class WithdrawalService {

    public static final double ADMINISTRATIVE_EXPENSES_CHARGE = 25.00;

    public void cargarDebitarCuentas(){

        BankAccount basiAcct = new BasicAccount();
        basiAcct.deposit(100.00);

        BankAccount premiumAcct = new PremiumAccount();
        premiumAcct.deposit(200.00);

        List<BankAccount> accounts = new ArrayList();

        accounts.add(basiAcct);
        accounts.add(premiumAcct);

        debitAdministrativeExpenses(accounts);

    }

    private void debitAdministrativeExpenses(List<BankAccount> accounts){
        accounts.stream()
                .forEach(account -> account.withdraw(WithdrawalService.ADMINISTRATIVE_EXPENSES_CHARGE));
    }
}

On the second sprint of your project, your boss asks you to implement long-term accounts into your bank account managing system. The differences between long-term accounts and basic/premium accounts are the following:

Long-term accounts are exempt from administrative expenses.
Long-term accounts don't allow withdrawals. If the client wants to withdraw any amount of his / her account must be done through a different process.

As a developer in charge of the accounts system, you decide to extend the BankAccount class for the Long-term accounts.

public class LongTermAccount extends BankAccount {

    private double balance;

    @Override
    public void deposit(double amount) {
        this.balance += amount;
    }

    @Override
    public boolean withdraw(double amount) {
        throw new UnsupportedOperationException("Not supported yet."); 
    }
}

This part is where the violation of the Liskov Substitution Principle is obvious. You cannot extend the BankAccount class in the LongTermAccount without overriding the withdrawal method. However, the long-term accounts don’t allow withdrawals according to your project’s requirements.

You have the following two options to solve this issue:

You can override the withdrawal method as an empty method or you can throw an UnsupportedOperationException. However, the BankAccount objects wouldn't be completely interchangeable with LongTermAccount objects because if we try to execute the withdrawal method we would get an exception. As a solution for this issue, we can condition the debitAdministrativeExpenses method, so we can skip the LongTermAccount objects but this would violate the Open/Closed Principle. For instance:

private void debitAdministrativeExpenses(List<BankAccount> accounts){

        for(BankAccount account : accounts){
            if(account instanceof LongTermAccount)
                continue;
            else
                account.withdraw(ADMINISTRATIVE_EXPENSES_CHARGE);
        }
    }

You can make your code Liskov Substitution Principle compliant.

Implementing Liskov Substitution Principle

The main issue with the bank account structure is that the long-term account is not a regular bank account, at least is not the type defined in the BankAccount abstract class. There is a simple test on the abductive reasoning area that can be used to check if a class is a subtype from “X” type. The duck test states “If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck”. The long-term account looks like a regular bank account but it does not behave like a regular one. To solve this issue we have to change the current class structure.

To make our code LSP compliant, we’ll make the following changes:

All types of bank accounts will allow the deposit action.
Only the basic and premium bank accounts will allow the withdrawal action.
We’ll define an abstract bank account for all types of accounts. This abstract class will define only one method, the deposit method.
We’ll extend the BankAccount with WithdrawableAccount abstract class, which will define the debit method.
The basic and premium accounts will extend the WithdrawableAccount abstract class, while the long-term account will extend the BankAccount abstract class.

The abstract BankAccount class will define the deposit method.

public abstract class BankAccount {

    /**
     * In charge of depositing a specific amount into the account.
     * @param amount            Dollar ammount.
     */
    public abstract void deposit(double amount);
}

The abstract WithdrawableAccount class will define the withdrawal method.

public abstract class WithdrawableAccount extends BankAccount {

    /**
     * In charge of withdrawing a specific amount from the account.
     * @param amount            Dollar amount.
     * @return                  Boolean result.
     */
    public abstract boolean withdraw(double amount);
}

The basic and premium account classes will extend the WithdrawableAccount class, which extends the BankAccount class. This nested inheritance allows the basic/premium accounts to have both methods, deposit, and withdrawal.

public class BasicAccount extends WithdrawableAccount {

    private double balance;

    @Override
    public void deposit(double amount) {
        this.balance += amount;
    }

    @Override
    public boolean withdraw(double monto) {
        if(this.balance < monto)
            return false;
        else{
            this.balance -= monto;
            return true;
        }       
    }   
}

public class PremiumAccount extends WithdrawableAccount {

    private double balance;
    private int preferencePoints;

    @Override
    public void deposit(double monto) {
        this.balance += monto;
        accumulatePreferencePoints();
    }

    @Override
    public boolean withdraw(double monto) {
         if(this.balance < monto)
            return false;
        else{
            this.balance -= monto;
            accumulatePreferencePoints();
            return true;
        }
    }

    private void accumulatePreferencePoints(){
        this.preferencePoints++;
    }
}

The WithdrawalService class is implemented using only WithdrawableAccount types or subtypes.

public class WithdrawableService {

    public static final double ADMINISTRATIVE_EXPENSES_CHARGE = 25.00;

    public void cargarDebitarCuentas(){

        WithdrawableAccount basicAcct = new BasicAccount();
        basicAcct.deposit(100.00);

        WithdrawableAccount premiumAcct = new PremiumAccount();
        premiumAcct.deposit(200.00);

        List<WithdrawableAccount> accounts = new ArrayList();

        accounts.add(basicAcct);
        accounts.add(premiumAcct);

        debitarGastosAdmon(accounts);

    }

    private void debitarGastosAdmon(List<WithdrawableAccount> accounts){
        accounts.stream()
                .forEach(account -> account.withdraw(WithdrawableService.ADMINISTRATIVE_EXPENSES_CHARGE));
    }
}

The changes done on the class structure assures that our code is LSP compliant. Now we are not required to implement the withdrawal method on the LongTermAccount class. Also, we interchange the WithdrawableAccount objects with any subtype of this abstract class. The class structure is also OCP compliant because if we added another bank account type that does not allow withdrawal, we wouldn't need to modify the current code just to extend the BankAccount type.

Importance of the Liskov Substitution Principle

The LSP allows us to identify incorrect generalization areas done during the design phase and correct them. The Liskov Substitution Principle is fundamental in the development of the dependency injection concept, which is widely used in Java Enterprise Edition and Spring Framework.

You can use the following tips if you want to easily detect violations of the Liskov Substitution Principle:

There is an LSP violation if you introduce a condition using the type of your object, as shown above in the instanceof example.
There is an LSP violation if you extend an abstract class and you set one of the abstract methods as an empty method or you throw a not defined exception.

Why not using interfaces instead of abstract classes

Interfaces and abstract classes are very similar, but they are not the same. Abstract classes define functionality that subclasses must implement. On the other hand, interfaces define functionality that must be implemented by any class that implements the given interface.

For instance, abstract classes define that a pony gallops because it is a type of horse. In contrast, an interface defines that a "thing" can "move" because there is an agreement, by implementing the interface, that the thing must move.

So this raises two questions:

Could we implement the bank account example using interfaces? Yes, Sure. There is no wrong answer here. You could implement the example by using either abstract classes or interfaces.
Would I still violate LSP by using interfaces?
Well, there is no correct answer here. LSP was defined in the context of subtyping. However, I think, this is not valid anymore. LSP is not about abstract classes or interfaces, is all about honoring the contract.

If you like to read more about LSP, you can have a look at Uncle Bob’s Blog.

In the next post, we will talk about the Interface Segregation Principle.

You can follow me on Twitter or Linkedin.

SOLID: Open Closed Principle

Victor Manuel Pinzon — Thu, 08 Apr 2021 21:18:03 +0000

This is a continuation of the SOLID principles series.

The Open/Closed Principle (OCP) is one of the most important SOLID principles but the least used. One of the reasons is its ambiguous and confusing definition. The OCP was first defined by Bertrand Meyer in his “Object-Oriented Software Construction” book. The OCP, according to Meyer, states the following:

Software entities should be open for extension but closed for modification.

The original definition given by Meyer led to some confusion within the developer community because it was poorly phrased. Years later, Bob Martin expanded the definition as follows:

You should be able to extend the behavior of a system without having to modify that system.

This definition was in tune with the plug-in architecture, which was at its peak at that time. The plug-in architecture states that you should build software that is able to extend its core functionality by providing plugins, which you could add, remove or change with little or no effect on the rest of the core system.

For instance, an integrated development environment (IDE) allows you to extend its core functionality by using plugins, such as Lite Server, Remote SSH, etc... These plugins do not affect the IDE’s core system. This means that an IDE is in tune with the plug-in architecture and the Open/Closed Principle.

Another example of OCP can be found in software libraries. These are usually developed to be used in different contexts and projects. Some standard libraries even allow you to extend their core functionality by using inheritance and polymorphism. These libraries are also in tune with the Open/Closed Principle because you could extend the functionality of these libraries without affecting their core functionality.

Now let's see a code example. Suppose you work for a gaming development company. Your boss, as part of a project, asks you to implement a library for calculating any rectangle´s area. This will be used for drawing the game’s characters.

You develop the following classes:

public class Rectangle{

    private final double width;
    private final double height;

    public Rectangle(double width, double height){
        this.width = width; 
        this.height = height;
    }

    /*Getters / Setters*/
}

The Rectangle class stores the width and height of any rectangle.

public class AreaCalculator{

    public double calculateArea(Rectangle rectangle){
        return rectangle.getWidth * rectangle.getHeight;
    }   
}

The AreaCalculator class defines just one method in charge of the area calculation, which is done by multiplying the rectangle’s width by the rectangle’s height.

The library is used as follows:

public class App{

    public static void main(String[] args){

        AreaCalculator areaCalc = new AreaCalculator();
        Rectangle rec1 = new Rectangle(13.5, 14);
        Rectangle rec2 = new Rectangle(7.89, 9.85);

        System.out.println("Rectangle's area #1: " + areaCalc.calculateArea(rec1));
        System.out.println("Rectangle's area #2: " + areaCalc.calculateArea(rec2));
    }
}

Your library is a success and is used in multiple projects. Months later, your boss asks you to implement the area calculation for squares.

When you start the analysis of the new requirement you realize the following:

A square is a special case of the rectangle. The difference is that the sides of the square are the same length.
The area of a square is calculated by multiplying the length of the sides by itself.

You immediately realize that your library does not comply with Open/Closed Principle, because you cannot extend the library functionality by adding new geometric figures without modifying the existing code. Of course, we could discuss that in order to add the square functionality you could set the same length for all the sides of the rectangle, but what if you want to add the circle functionality?

The answer is the Open/Closed Principle.

Applying the Open/Closed Principle

The Area Calculator library shows us the problems that can arise when we do not take into account the future changes that a specific module can have. The main objective of the OCP is to develop software solutions where you can easily extend functionalities without affecting the core system. To achieve this, you must identify the modules in your code that are most likely to change in the future and decouple them, so you can easily extend their behavior.

Decoupling means taking the key parts of your classes’ functionality and replace them with interfaces. This allows you to replace these key parts with any class that extends the interface.

To apply OCP in the Area Calculator library, we’ll define a geometric figure interface that will have just one method for area calculation.

public interface GeometricFigure{
      public double calculateArea();
}

Then we’ll define the specific geometric figure classes. Each figure will define its own implementation of the area calculation.

public class Rectangle implements GeometricFigure{

    private final double width;
    private final double height;

    public Rectangle(double width, double height){
        this.width = width;
        this.height = height;
    }

    @Override
    public double calculateArea(){
        return this.width * this.height;
    }
}

public class Square implements GeometricFigure{

    private final double side;

    public Square(double side){
        this.side = side;
    }

    @Override
    public double calculateArea(){
        return this.side * this.side;
    }
}

public class Circle implements GeometricFigure{

    public static final double PI = 3.1416;
    private final double radius;

    public Circle(double radius){
        this.radius = radius;
    }

    @Override
    public double calculateArea(){
        return (Circle.PI * (this.radius * this.radius));
    }
}

We will modify the AreaCalculator class so that the calculateArea method receives a GeometricFigure object. So it can calculate its own area by using the object's method.

public class AreaCalculator {

    public double calculateArea(GeometricFigure figure){
        return figure.calculateArea();
    }    
}

The library is used as follows:

public class App {

    public static void main(String[] args) {

        AreaCalculator areaCalc = new AreaCalculator();
        Square square = new Square(3.15);
        Rectangle rectangle = new Rectangle(7.85, 10.85);
        Circle circle = new Circle(7.98);

        System.out.println("Square's area: " + areaCalc.calculateArea(square));
        System.out.println("Rectangle's area: " + areaCalc.calculateArea(rectangle));
        System.out.println("Circle's area #1:" + areaCalc.calculateArea(circle));
    }
}

The new design for the Area Calculator library allows us to extend the functionality of any geometric figure as long as we implement the GeometricFigure interface. Now the library complies with the Open/Closed Principle.

Should we always apply the Open/Closed Principle?

The OCP should not be an unbreakable rule when designing software solutions, it should be more like a best practice. The problem with OCP, as the same as the Single Responsibility Principle, is that you must guess the possible future changes your code will suffer. This can be easy for a senior or semi-senior developer, but for a junior developer could be a disaster. The poor implementation of the OCP could complicate the structure needlessly.

My recommendation is to always design your solutions in a way that your code is easily understood by other developers and easily scalable for changes in the future. About OCP, it is always better to wait for the first iteration of changes (because it always changes) so that you can identify the modules where you can apply the Open/Closed Principle.

If you like to read more about OCP, you can have a look at Uncle Bob's Blog.

In the next post, we will talk about the Liskov Substitution Principle.

You can follow me on Twitter or Linkedin.

SOLID: Single Responsibility Principle

Victor Manuel Pinzon — Tue, 30 Mar 2021 17:58:57 +0000

Code quality is one of the angular pieces of software development, nonetheless, is also one of the most neglected ones. The current trend on software development is to focus on learning new languages, new paradigms and the new trendy technologies that everybody tweets on Twitter. Leaving aside the importance of good practices and learning on how to develop scalable and robust solutions with high code quality.

SOLID principles are vitally important in object-oriented programing (OOP) because it allows you to write programs which are maintainable, extendable and testable. However, it is very common to find experienced and non-experienced developers that haven’t heard of them. Of course, I wasn’t the exception to the rule. My passion for software development started in 2004, developing simple adding and subtracting programs in Pascal. Throughout the years I learned multiple languages, such as C, C++, Visual Basic, Visual Fox Pro, etc. In 2008 I learned Java and the OOP paradigm, but it wasn’t until 2014, that a workmate lent me the book “Clean Code” by Robert C. Martin. From this book, I learned about coding standards and best practices, but most importantly I learned about the SOLID principles.

Before reading “Clean Code”, 6 years went by where I developed professionally without knowing about SOLID principles. To be honest with you, there is a huge difference between the quality of my programs before and after having learned them. The most notorious improvement is that, now, I’m able to write applications that are easily maintainable and testable.

Believing that never is too late to learn, we will review each one of the principles.

SOLID Principles

S.O.L.I.D principles are 5 five foundational principles in object-oriented programming. These were developed by Robert C. Martin (Uncle Bob) in 2000. The main objective of SOLID principles is to eliminate bad practices in software design, as well as helping the developer to write maintainable, scalable, and testable code.

The SOLID principles are conformed by:

Single Responsibility Principle.
Open/Closed Principle.
Liskov Substitution Principle
Interface Segregation Principle.
Dependency Inversion Principle.

The term SOLID is an acronym for those five principles.

Single Responsibility Principle

Single Responsibility Principle (SRP) refers that a class, method or module must have just one responsibility. In other words, it must have just one reason to change. Sometimes we create classes, methods or modules that have too many responsibilities at once. For instance, sometimes you can have a class that has business logic, persistence logic, log register, all in the same class. This is a violation of SRP because the class is trying to do many things at once and a change in one of those responsibilities means all other responsibilities will be affected as well.

The main objective of SRP is the separation of responsibilities and scope reduction when you introduce a change.

Let’s see the following example:

package com.yourregulardeveloper.entities;

import java.math.BigDecimal;
import java.util.List;

public class Client {
    private String clientId;
    private String name;
    private String lastName;

    public Client(String clientId, String name, String lastName) {
        this.clientId = clientId;
        this.name = name;
        this.lastName = lastName;
    }

    /**
     * Calculates the subtotal invoice.
     * @param articles         List of articles bought by the client.
     * @return                 Invoice subtotal.
     */
    public BigDecimal calculateSubTotalInvoice(List<Article> articles){
        return articles
                .stream()
                .map(article -> article.getUnitPrice()
                        .multiply(new BigDecimal(article.getAmount)))
                .reduce(BigDecimal.ZERO, BigDecimal::add);

    }

    /**
     * Calculates the total invoice.
     * @param subtotal                  Invoice subtotal.
     * @param taxPercentage             Tax percentage.
     * @return                          Total invoice.
     */
    public BigDecimal calculateTotalInvoice(BigDecimal subtotal, BigDecimal taxPercentage){
        return subtotal.add(subtotal.multiply(taxPercentage));
    }

    public String getClientId() {
        return this.clientId;
    }

    public void setClientId(String clientId) {
        this.clientId = clientId;
    }

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

The class “Client” violates the SRP because it has more than one responsibility, which are:

The handling of the client entity throughout the application lifecycle. This responsibility is given by the attributes and methods related to the client’s info.
Invoice totals calculator. This responsibility is given by the methods calculateSubTotalInvoice() and calculateTotalInvoice().

The main, and only, responsibility of the class “Client” should be the handling of the client entity. A bad design introduced a second responsibility to the class. To solve this bad design we could implement SRP and separate the responsibilities into two different classes.

package com.yourregulardeveloper.entities;

public class Client {
    private String clientId;
    private String name;
    private String lastName;

    public Client(String clientId, String name, String lastName) {
        this.clientId = clientId;
        this.name = name;
        this.lastName = lastName;
    }

    public String getClientId() {
        return this.clientId;
    }

    public void setClientId(String clientId) {
        this.clientId = clientId;
    }

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }
}

package com.yourregulardeveloper.invoice;

import java.math.BigDecimal;
import java.util.List;

public class InvoiceCalculator {

    /**
     * Calculates the subtotal invoice.
     * @param articles         List of articles bought by the client.
     * @return                 Invoice subtotal.
     */
    public BigDecimal calculateSubTotalInvoice(List<Article> articles){
        return articles
                .stream()
                .map(article -> article.getUnitPrice()
                        .multiply(new BigDecimal(article.getAmount)))
                .reduce(BigDecimal.ZERO, BigDecimal::add);

    }

    /**
     * Calculates the total invoice.
     * @param subtotal                  Invoice subtotal.
     * @param taxPercentage             Tax percentage.
     * @return                          Total invoice.
     */
    public BigDecimal calculateTotalInvoice(BigDecimal subtotal, BigDecimal taxPercentage){
        return subtotal.add(subtotal.multiply(taxPercentage));
    }

}

Now we have the class “Client” and the class “InvoiceCalculator”. Each one of those classes have just one responsibility or just one reason to change. SPR allowed the class “Client” to have just the responsibility of handling the client entity and the class “InvoiceCalculator” to just have the responsibility of calculating the invoice totals. Both classes are easier to read, to maintain and to test.

Single Responsibility Principle on methods

SRP can be applied on methods, classes or modules. I make emphasis on methods because is very common to develop methods that do too many things at once. I’ve seen some huge 500 lines methods that have too many responsibilities at once. For instance, is common to find methods that record on logs, do some calculations and finally they persist the result of those calculations in the database. The problem with these types of methods is that besides they are difficult to maintain and difficult to introduce changes, they also are difficult to test.

SRP allows to write methods that have just one responsibility without caring about the size of it, just caring about the method having one reason to change.

Single Responsibility Principle bad practices

Sometimes the poor implementation of SRP can be counterproductive. For instance, if the SRP implementation is exaggerated you could end up writing classes with just one method, which could be wrong. We must remember that SRP dictates that a coding unit (method/class/module) must have just one reason to change. We must also remember that the correct implementation of SPR allows us to group different code units with one responsibility. It doesn’t dictate the number of methods in a class or the number of lines in a method.

SRP helps us to separate concerns and responsibilities and is key to write scalable, maintainable, and testable code. It allows us to eliminate bad practices, such as: implementing classes and methods that do many things at once.

If you like to read more about SRP, you can have a look at Uncle Bob's Blog.

In the next post, we will talk about the Open/Closed Principle.

You can follow me on Twitter Twitter.