DEV Community: Henrique Gonçalves Galvão

What I got from Clean Architecture as a FE... (6-11)

Henrique Gonçalves Galvão — Mon, 04 Mar 2024 16:44:24 +0000

Let's continue! In this post I will keep summarizing what I'm understanding while reading the book Clean Architecture by Robert C. Martin. If you missed the first one (Chapters 1-5), click here.

Chapter 6 - Functional Programming

In this chapter Uncle Bob talks about functional programming following the topics: Structured Programming and OOP. He mentions that in functional programming, variables are immutable, meaning that to be able to make it "functional" it is necessary to have a good amount of memory and a powerful processor. Why? Because in functional programming, since it is immutable, the state doesn't change. However, the program keeps track of the modifications. Think of a bank statement, instead of changing state whenever there is a withdraw or a deposit, we keep track of the modifications and whenever an updated state is requested, we make the calculations returning a new variable with a new state of the final value. Make sense? I don't know, to be completely honest I never heard about this. Or have I?

I know this will be a big summary but it is important to mention that in Javascript, functional programming refers to the use of pure functions, immutability, and higher-order functions to create programs that are more predictable and easier to reason about.

Chapter 7 - SRP: Single Responsiblity Principle

In this chapter we start reading more about SOLID. The 5 principles of SOLID are Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segragation Principle, and Dependency Inversion Principle.

The first, is always confused with "a function should only do one thing", meaning it should only have one responsibility. I was one to think that too. However, in this chapter, the author explains that actually, a function should affect only one "actor"

Single Responsibility: A class should have one and only one reason to change. This means that the class should encapsulate one aspect of functionality that might change for only one reason.

"Actor" Focus: When considering responsibility, think about who or what might be affected by changes in the behavior of the class. Each class should serve a single actor or a cohesive group of actors.

I like the explanation the author uses of a company using the same class to calculate hourly wage, report hours and save hours. Each of these can be assigned to different "actors" for example, CFO, COO, and CTO respectively.

Chapter 8 - OCP: Open-Closed Principle

In chapter 8, the author mentions that the Open-Closed Principle refers to a class or function being open to extension but closed to modification. This is done by trying to modify the function as little as possible while separating concerns. This helps assure that a high level function is not impacted by low level functions.

In React, we can think about componentization, where apps can be build using components that are extendable. HOCs allows you to extend, add or modify without altering the original component. Even using life-cycle methods is a way of thinking about the OCP. They allow you to hook into the lifecycle of a component without modifying its implementation. You can extend the behavior of a component by subclassing it and overriding these methods.

Chapter 9 - LSP: Liskov Substitution Principle

Objects of a superclass should be replaceable with objects of its subclasses without breaking the application. That is it. In React, think about that components wrapped by HOCs should behave like the base component. So whenever a component uses another component, it shouldn’t break its functionality (or create any surprises).

This principle, for React devs (at least for me), seems like the most complicated one to make sense. However, if you think about the use of typescript, things should make a little more sense. Lets pretend you have a modal that accepts a child (which in most cases should be a JSX component). Without using TS, we can pass a object as that child and the component or the code won't break, but we will get an error in our browser... why? Because React works like that and it wants to receive (and only can) a JSX component or a string. Using TS, and typing that child to be a JSX component, no unexpected behavior will occur.

Chapter 10 - ISP: Interface Segregation Principle

From my understanding, ISP is very dependable on the language, and if it is typed. However, to summarized, thinking about React, imagine that you have a child component keeps causing the parent to rerender when it shouldn't, this is basically what ISP tries to prevent. ISP refers to not have unused or useless code causing effects on its dependents.

Keeping interfaces focused and minimal reduces the likelihood of unintended side effects, promotes better encapsulation, and makes components easier to understand and reason about.

Chapter 11 - DIP: Dependency Inversion Principle

In this chapter we get to know more about Dependency Inversion Principle (DIP). We can say that for DIP, high-level components don't directly depend on low-level components. Instead, both should rely on abstractions, like props or context, to foster flexibility and maintainability.

What I got from Clean Architecture as a FE... (1-5)

Henrique Gonçalves Galvão — Fri, 23 Feb 2024 12:51:38 +0000

I decided to start writing about my reading experiences. I have tried to pick up the habit of reading for a while and I decided that since my goal is to become a better dev, I will read and document software development books.

To give context, I am a Frontend Developer with more than 3 years of experience. I am one of those bootcamp developers. However, since the beginning, I tried to keep up with the content that is clearly missing from those bootcamps.

How is this going to work... I will try to write here what I am understanding from each chapter of this book by Robert C. Martin. Keep in mind, this is something I am doing for myself. However, if you want to comment on this with your thoughts, questions or tips on better understanding this book, feel free!

Chapter 1 - What is design and architecture?

The first chapter, he compares design and architecture to conclude that they are the same. He makes sure to emphasize the importance of a good design and architecture of a software. Furthermore, he continues to say that without quality, performance will dramatically decrease. He uses the story from the rabbit and the turtle to explain why over confidence and coding in a rush is always a bad choice.

Chapter 2 - A tale of two values

In the second chapter, Uncle Bob talks about two main values of a software, the functionality/how it works, and the architecture. He proceeds saying that most developers and tech workers tend to forget about the most important one, which is architecture, to focus on the other. We all know how it is "if it works, don't touch it". However, developing a software like this will have many implications. A good architecture permits that changes and improvements can be made to the software without impactful additional costs. He adds that the Eisenhower's matrix can be used.

While architecture is both urgent and important, functionality tends to be "just" urgent...

Chapter 3 - Paradigm Overview

In chapter three, the differences between the three paradigms (Structured Programming, Object-Oriented Programming, and Functional Programming) get overly summarized, but with the purpose to conclude that they are all important for software architecture.

Chapter 4 - Structured Programming

In this chapter, Uncle Bob talks about how the structured programming was proved useful. In general, he mentions that structured programming is basically separating concerns or practicing functional decomposing, which is separating big things into small modules so they are "testable". (Will have to read more about this)

Chapter 5 - Object-Oriented Programming

Reading chapter 5 from the perspective of a Javascript/Typescript developer, can be challenging if you have no previous experience working with classes (Why learn them if we can just "rfce" on VSCode and create our functional components, right?). However, the author gives a brief explanation of the three principles related to OOP. One is encapsulation. Encapsulation is the method of bundling data and functions inside an object. Encapsulation helps hiding internal state of such object.

class Car {
  constructor(make, model) {
    this.make = make;
    this.model = model;
    this.speed = 0;
  }

  accelerate(speedIncrement) {
    this.speed += speedIncrement;
  }

  brake(speedDecrement) {
    if (this.speed - speedDecrement >= 0) {
      this.speed -= speedDecrement;
    } else {
      this.speed = 0;
    }
  }

  getSpeed() {
    return this.speed;
  }
}

In this example, while you can view the properties, they can only be controlled through 'accelarate', 'break', and 'getSpeed'.

The second principle is inheritance, which by the name should be simple to figure out. This is a mechanism that a class inherits properties and methods from other classes.

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    console.log(`${this.name} makes a noise.`);
  }
}

class Dog extends Animal {
  speak() {
    console.log(`${this.name} barks.`);
  }
}

Last principle is Polymorphism, considered to be the most important one. Polymorphism allows objects of different classes to be treated as objects of a common superclass. This relates to inheritance, however in the example below we can see polymorphism with the method makeSound() as it behaves differently based on the type of animal object it is called upon.

class Animal {
  makeSound() {
    console.log('Some generic sound');
  }
}

class Dog extends Animal {
  makeSound() {
    console.log('Woof');
  }
}

class Cat extends Animal {
  makeSound() {
    console.log('Meow');
  }
}

I will end this first portion here. Next time I will go from Chapter 6 until Chapter 10. This book has 34 chapters, let's see if I will be a better architect by then...