JS: Functions
2026-02-21 02:53 Diff
https://hexlet.io/courses/js-functions/lessons/abstraction/theory_unit

The main reason for creating functions is to increase the abstraction level, not to reduce code duplication. The second is a consequence of the first. And indeed, instead of implementing sorting by yourself in every place where you need it, you can use the sort() function, which hides the implementation within and leaves the developer undistracted by unnecessary details (type of sorting, code to perform it).

This is the essence of abstraction; we ignore the non-essential aspects, properties, and relationships of the object or process in question, which allows us to simplify a presentation of a complex concept. The ability to abstract is one of the most important properties of our brain. Young children learn very quickly how to classify objects in our world. Without much difficulty they understand that a tree is a tree, even if it is the first time they have seen a particular species of tree. And the two spread fingers indicate a bunny (because ears).

Despite this, an understanding of how to build abstractions wisely (in our case, distinguish functions) does not appear by itself. It comes with experience, provided there is another person stronger than you who can point out to you the mistakes you have made, and you keep track of the problems of your abstraction in the process of operation (reflection). On the other hand, excessive abstraction is more harmful than helpful. You can lose the essence and spend more time understanding what's going on behind the clutter of new entities. The construction of abstraction is always a compromise. The lack of abstraction leads to duplicate code, and the abundance can be very difficult to understand (try to grasp Category Theory) and make simple problems harder to solve.

Higher-order functions take function abstraction to a new level. By delegating behavior to external code (using anonymous functions), the ability to reuse the code (algorithm) in different situations is dramatically enhanced. And instead of ten functions for ten different pieces of code, you get one function that is specified ten times with ten alternate behaviors.

But don't forget that abstractions almost always leak.

An example of a leaky abstraction

In Hexlet's first project, our students make one (they make many, but for now we are interested in one) mistake, related to the incorrect allocation of abstractions. Putting aside (abstracting!) the details, the problem boils down to writing a function that takes a number as input and has to print yes on the screen if it is even, and no otherwise.

The first solution looks something like this:

It works, but the concept of parity itself is not isolated in its abstraction, which, for example, makes it difficult to test and understand the code. Here it is simple, but in more complex cases it is problematic to guess what kind of operation is being performed. The right thing to do would be to make parity a separate function (abstraction).

Look at the code above carefully. Is it okay?

This code is even worse than the first version, because the wrong abstraction is created. The number parity concept has nothing to do with the printing the "yes" or "no" strings. It exists in a vacuum as a mathematical concept and cannot know how it is going to be used. Not to mention that the name isEven() starts with is, which means that the function is a predicate. Such functions can only return a boolean value and nothing else (no exceptions!). The right version looks like this:

And this is the most primitive way to create abstractions. In real code, things are usually much more complicated. The construction of correct abstractions is practiced in the Hexlet projects.