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.
Top comments (0)