JS: Object oriented design
2026-02-21 02:50 Diff
https://hexlet.io/courses/js-object-oriented-design/lessons/configuration/theory_unit

Markdown is a simplified markup language that's easier to use with text (as opposed to HTML). Browsers cannot display Markdown directly, so it's translated into HTML and then rendered. The translation of Markdown to HTML is described by a pure function. It's independent of the external environment, deterministic, and produces no side effects.

The input is text (in Markdown format), and the output is also text (in HTML format). If you want to change the behavior of the translation, you just need to pass an array of options as the second parameter.

Now let's imagine an object-oriented version of this code. Before moving on, try to take a break from the reading and think about the following questions:

  • What exactly do we want from OOP that a pure function doesn't give us?
  • What will the resulting interface look like?

As you remember, classes allow you to implement abstraction. Can we say that there's an abstraction in the Markdown to HTML conversion process? No. Abstraction implies the existence of a concept (type) whose values have a lifetime. This means that it's created and then used repeatedly and in different ways. For example, it's impossible to present the work with the user as a single function. When it comes to Markdown, we're not interested in any particular text in that format per se, we don't define a set of operations on it, and we don't intend to actively use it. All we want, right here and now (in that code) is to get HTML and forget about Markdown.

If we wanted to build an abstraction around the text, the code would look like this:

In the example above, the Markdown type represents an abstraction over text in the Markdown format. The code doesn't make much sense and causes problems as a result. These two lines will inevitably start to occur anywhere where you want to get HTML. The md object immediately becomes unnecessary as soon as the HTML is received, it doesn't have a lifetime. This antipattern is especially common among beginners. The tricky part here is figuring out exactly where we have data abstraction and where we don't.

There's a formal rule to determine this. If the object creation and method call can be replaced by a standard function, then abstraction is out of the question, and the correct approach, in this situation, is to transfer data from the constructor to the method itself.

In this code, the Markdown class is a type that refers to the translator, not the text. Such an object has a wider lifecycle than waiting for the render() function to be called once (as in the previous case). It can (and should) be reused as many times as needed. To do this, it's important to keep render() pure and not to change the state of the object between calls.

That would make it unclear as to why the object is here at all. And there are two reasons for that.

  1. Polymorphism of subtypes. We'll deal with that in the courses that follow.
  2. The second and main reason (for this case) is Configuration.

Let's look at the last point in more detail. Imagine that Markdown is used everywhere in the project (it's used on Hexlet very often) and the HTML generation code looks like this:

The more such places arise, the more times the passing of options is duplicated. Changing the behavior would require all the places where this function is called to be rewritten. The logical step would be to set the options in one place and then reuse them.

Using an object allows you to remove explicit passing (which is easy to forget about). The essence of this pattern is configuration. I.e., the object in this case acts as a container that contains options for Markdown that are applied during rendering, so you don't have to pass them every time.

Configuration always refers to passing options (various settings needed by a given library) to the constructor at the point the object is created. This configuration is especially useful when the object is created in one part of the program (during the initialization phase of the application) and used in other places. The ability to use configuration doesn't mean you have to use it. As a rule, such objects can be created without specifying anything, the default behavior remains, but the meaning doesn't change.

Axios is a popular library for HTTP requests, and is built on the same principle. It allows you to create an object that saves a basic configuration.

Try it for yourself. Is executing an HTTP request a data abstraction or not?

This technique is not the prerogative of classes and objects. In functional languages (and in JS) it's extremely easy to implement using closure.