Hello everyone, I am han Cao 😈, a grass code ape 🐒 who has been working for more than a year. If you like my article, you can follow ➕ to like it and grow up with me. Add my wechat: Hancao97, invite you to join the group, learn and communicate together, and become a better engineer

This is the sixth day of my participation in the First Challenge 2022. For details: First Challenge 2022.

background

In this article, we will learn about functional programming

Clean Architecture Series:

  • Programming paradigm (II) : Object-oriented programming
  • Programming paradigm (I) : Structured programming
  • Cold grass and “architecture clean way” | leaves flying, the story begins 🌟

Functional programming

Functional programming relies on principles that in many ways predate programming itself. Because the paradigm of functional programming relies heavily on the lambda calculus, invented by Alonzo Church in the 1930s.

Variables in functional programming languages Vary.

The Clojure language is mentioned several times in the book as an example of functional programming for those who are interested.

Immutability and software architecture

Why is immutability a key consideration in software architecture design? Why should a software architect worry about variable variability?

All race problems, deadlock problems, and concurrent update problems are caused by mutable variables. If variables are never changed, it is impossible to have race or concurrent update problems. If the lock state is immutable, deadlock problems will never occur.

In other words, all the problems encountered by concurrent applications, all the problems caused by using multiple threads, multiple processors, would not be possible without mutable variables.

We need to make sure that we design systems that work reliably in a multithreaded, multiprocessor environment. So the real question we should be asking here is: is immutability practical?

If we can ignore the speed limitations of memory and processor, the answer is yes. Otherwise, immutability is only possible under certain circumstances.

Let’s take a look at how it works.

Variability isolation

A common approach is to slice an application, or its internal services, into mutable and immutable components. Immutable components perform tasks as pure functions without changing any state in the process. These immutable components modify variable state by communicating with one or more non-functional components.

Since state changes can lead to a host of concurrency problems, some sort of transactional memory is often used to protect mutable variables from synchronous updates and contending states.

A well-architased application should isolate the parts of the application where state changes and those that do not need state changes into separate components, and then protect the variables with appropriate mechanisms. The software architect should focus on putting most of the processing logic into immutable components, with as little logic for mutable state components as possible.

Event source

Here’s an example:

Suppose a banking application needs to maintain balance information on a customer’s account. As it performs a deposit or withdrawal transaction, it is also responsible for modifying the balance record. But if we don’t keep the specific account balance, just keep the transaction log, then when someone wants to check the account balance, we pull out the entire transaction record, and we have to accumulate it from the beginning to the present every time. Of course, such a design does not need to maintain any mutable variables.

This is called event traceability, in which we store only transaction records, not specific states. When specific states are needed, we simply calculate all transactions from scratch.

There are no deletions and updates in this data storage mode, and our application is not CRUD, but CR. Since neither update nor delete exists, there is no concurrency problem.

If we have enough memory and processing power, applications can be programmed in a completely immutable, purely functional way. “What is big enough? We have enough storage and processing power to satisfy it over the life of the program.”

conclusion

All three paradigms have been learned together, and here’s a summary:

  • Structured programming limits the direct transfer of program control.
  • Object – oriented programming limits the indirect transfer of program control.
  • Functional programming is a restriction on assignment operations in a program.

All three programming paradigms impose new constraints on programmers. Each paradigm constrains a certain way of writing code, and none of the programming paradigms is adding new capabilities.

That said, what we’ve learned over the past few decades is mostly what not to do.

In short, software, or computer programs, are invariably composed of sequential structure, branch structure, loop structure, and indirect transfer.

The last

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Youth never knows heaven and earth

Conceit and talent are everywhere you look

Pretentious as it is

I was honest

I love such a boy

Humble and arrogant

Proud and calm ☀️

✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨ ✨

Your likes and attention are my constant motivation, you can add my wechat: HancAO97, invite you to join the group, learn and communicate together, become a better front-end engineer ~