Small knowledge, big challenge! This article is participating in the creation activity of “Essential Tips for Programmers”.

takeaway

This is a short article that needs to be explained, but the front end here refers to the narrow work that is closely related to the development page. As for the independent development of NPM, the server and other scenarios are a different matter, which will be discussed later.

background

Class is almost synonymous with OOP. OOP features: encapsulation, inheritance, polymorphism, representing languages Java, C++. Joe Armstrong, author of the Erlang language, says:

The problem with object-oriented languages is that they always carry around those implicit environments. All you need is a banana and you get a gorilla with a banana… And the whole jungle.

In JS, functions are first-class citizens and can be declared and used directly. But in Java, functions must be attached to a Class, so if you want to simply declare and use a function, you have to declare a Class first. For programmers accustomed to OOP languages, this can even become a knee-jerk reaction. Perhaps because Java and C++ are the mainstream teaching in colleges and universities, the author often sees this kind of “conditioned reflex” left over in front-end code, which is unnecessary in most cases.

This article looks at three aspects of OOP to see why classes are not necessary on the front end, or even should be avoided. The appropriate scenarios for using Class will then be added dialectically.

The body of the

Why not Class

encapsulation

Page is a concrete thing that everyone can see, it can be abstracted as a combination of components, so the front end is naturally suitable for the model of component development, component is the most basic front-end packaging unit, people are very easy to understand the concept of component.

On the back end, however, it is difficult to have a concrete and accurate object to carry people’s cognition (because you can’t see it). It is difficult to unify the scope and granularity of cohesion, so it is necessary to create an abstract concept, which is the function of “object” or Class.

If correct, then the Class abstraction, from a encapsulation perspective, is not necessary for the front end, or even should be prohibited. Because it co-exists with componentization, the granularity of encapsulation diverges, which is not a good thing for project maintenance.

inheritance

Front-end has Object data type, usually called “Object”, do not need to declare Class, do not need new can be directly defined, this is common sense front-end, is also one of the characteristics of JS. How do you implement inheritance without Class? Let’s look at a piece of code:

const basePeople: People = {
  name: ' '.age: 0.shout() { alert('hahaha')}};constzhangsan: People = { ... basePeople,name: 'zhangsan'.age: 18};Copy the code

Destruct the assignment and Class is not necessary for inheritance. Multiple inheritance can be implemented the same way.

polymorphism

In my very superficial (and possibly erroneous) understanding, the nature of polymorphism is to solve the problem of method (function) reuse and code readability. The reason for this is that declaring new functions is too expensive in OOP languages to be a last resort. In JS where functions are first-class citizens, the cost of declaring and using new functions is very low, which means more flexibility. So you can say that polymorphism itself is not needed in the front end.

When is Class appropriate

As mentioned in the “wrapping” section above, if the nature of the project is not to work with pages, there is no natural “component” concept and Class abstraction is needed to assist. So the conclusion is obvious:

It is still necessary to use the idea of Class and OOP for high abstraction projects that do not deal with pages, such as encapsulating NPM packages and writing server-side code. It is not necessary. React-hooks, for example, which provide Hooks of alternative thinking but have their own limitations.

conclusion

Conclusion 1:

  • Class should be avoided in page-focused projects
  • For non-page projects, you can use OOP Class, but there are other options, such as Hooks

Whether it’s OOP, AOP, FP, or any other programming paradigm, it’s rogue to talk about it outside of a specific usage scenario. Although they do have a high degree of abstraction and universality, but put into practice, there are still great differences in use and effect.

Therefore, as an engineer in charge of implementation, the author advocates that everything should start from practice and how to effectively improve production efficiency. Practice comes first, then theory, thinking from the bottom up. Rather than the other way around, otherwise it would be the mistake of “bookism”.

Given my limited capabilities, this article may be fallacious, but I am confident that the problems reflected in this article are real, that is, “unclear package granularity can cause project maintenance problems, and Class can cause such problems”. Even if the document is slightly biased, if it causes more people to think about it, it is barely enough.

Paper come zhongjue shallow, realize this to practice. – lu you