Programming paradigm roughly speaking

Programming paradigm refers to the basic style or typical pattern of computer Programming.

Programming paradises provide (and determine) the programmer’s view of program execution. For example, in object-oriented programming, programmers think of a program as a series of interacting objects, whereas in functional programming a program is thought of as a sequence of stateless functions evaluated.

There are many kinds of programming paradigms that focus on different ways to solve problems, such as procedural, object-oriented, functional programming paradigms. We are familiar with them, and they often appear in our eyes. To further your understanding of programming paradigms, here are several commonly used paradigms.

Process oriented

Procedural programming, also known as imperative programming, is one of the most primitive and familiar programming paradigms used in everyday work. In essence, it is an abstraction of the operation mechanism of the von Neumann machine, and its way of thinking derives from the sequence of computer instructions.

The core of process orientation is to analyze the steps to solve the problem, implement these steps with functions, and then call them in turn.

Here’s a classic example:

Put the elephant in the refrigerator divided into several steps?

Step 1: Open the fridge

Step 2: Pack the elephant

Step 3: Close the refrigerator door

It is still widely used today, thanks to its process-oriented intuitiveness and its closest approximation to the actual operation of the program.

However, it is not suitable for solving some kinds of problems, such as those unstructured problems with complex algorithms. It must describe an algorithm in detail and include the order in which these instructions or statements are executed. In fact, it is extremely difficult to give detailed algorithms for unstructured problems with complex algorithms; And it stresses that order matters, which is not appropriate for every problem.

object-oriented

OOP (Object Oriented Programming) regards objects as the basic unit of programs. An Object contains data and functions that manipulate data. It was first proposed by Alan Kay in 1966 or 1967 during his graduate study.

Unlike procedural programming, where the data and the functions that process it are independent of each other, we need to first process the data into a format that the function can accept and then call the relevant functions. In object-oriented, the data and the functions that process it are all in one class, passing the data by initializing instances.

Nowadays, when it comes to object orientation, three characteristics come to mind subconsciously: encapsulation, inheritance and polymorphism.

class Animal {
  constructor(
    public name: string
  ) {}

  eat() {
    console.log('eat food')}}class Cat extends Animal {
  constructor() {
    super('Cat')}}class Bird extends Animal {
  constructor() {
    super('Dog')}}Copy the code

There is also a graphic on the web that visually illustrates some common concepts in object orientation:

An object-oriented way to explain “Put the elephant in the fridge” :

Refrigerator. Open the door ()

To put (an elephant) in a refrigerator.

Refrigerator. Close the door ()

Aspect oriented

AOP: Aspect Oriented Program is a complement to object-oriented programming. We know that in object-oriented programming, you can’t reuse methods that aren’t relevant to the main business. For example, if you want to use logging for both classes A and B, object-oriented design dictates that you should include such A method in each class, even though they are almost identical. Of course, you could put such A piece of code in A separate class and call it in class A and class B, but this would create A strongly coupled relationship, and its changes would affect both classes. Faceted programming solves the problem of taking things outside the code that are irrelevant to the main business.

For example, on the front end, when implementing a code bill:

Without AOP your code might look like this:

class Test {
  add(paras: Params) {
    // Embedded code
    // Other code}}Copy the code

But this creates coupling and cannot be reused.

When using AOP:

function log() :MethodDecorator {
  return (target, key, descriptor) = > {
    // Here you can add your buried point interface
    // Or do something else
    return descriptor;
  };
}


class Test {
  @log()
  add(paras: Params) {
    //}}Copy the code

Another example is back-end interface authentication, which you might handle in middleware:

function guardsMiddle(req, res, next) {
  // There may be various judgments here
  // Check whether the URL is the specified URL, and then check whether it has permissions
  next()
}
Copy the code

Or you’ll handle it in a specific Controller /service:

class SomeController {

  getUserInfo() {
    // Check whether you have the corresponding permission
    // Do the specific processing}}Copy the code

In AOP, it might look like this:

@Controller(a)class SomeController {

  @Get('userInfo')
  @Roles('admin')
  getUserInfo() {
    //}}Copy the code

An interface

Like aspect – oriented programming, interface – oriented is a complement to object – oriented. It specifies a set of rules that a class that implements this interface must have. Such as:

interface Animal {
  eat(): void;
}

class Cat implements Animal {

  eat() {}
}

class Dog implements Animal {
  eat() {}
}

Copy the code

When developing vscode plug-ins, we use a number of interfaces exposed from vscode:

class StatusBar implements vscode.Disposable {
  dispose() {
    // xxx}}class TargetTreeProvider implements vscode.TreeDataProvider<{}> {
  getChildren() {
    // xxx}}Copy the code

You might be wondering, I could also use abstract classes, so what’s the difference?

abstract class Animal {
  abstract eat(): void;
}

class Cat extends Animal {
  eat() {}
}

Copy the code

There is little difference between using an interface or abstract class in these two examples, the only difference is that TypeScript is compiled into JavaScript and the interface is no longer there (no extra space is used). In addition, abstract classes can contain the implementation details of a program, that is, the reuse of code.

abstract class Animal {
  constructor(private name: string) {}

  abstract eat(): void;

  printName() {
    console.log(this.name); }}class Cat extends Animal {
  constructor() {
    super('cat');
  }

  eat() {}
}

class Dog extends Animal {
  constructor() {
    super('dog');
  }

  eat() {}
}

Copy the code

Another difference between an interface and an abstract class is that there should be a general and special relationship between an abstract class and its subclasses, whereas an interface is simply a set of rules that a class should implement.

conclusion

Today, there are many programming paradigms:

Each programming paradigm plays an important role in the context in which it focuses. OOP, for example, focuses on the packaging of data and behavior and the decoupling of the program’s interface and implementation. The biggest characteristic of FP is the stateless property of pure function. The process-oriented approach is closer to the operation mode of hardware in actual engineering.

Each paradigm has a “soul” that can only be understood when it is actually used.

In real projects, more often than not, we use multi-paradigm programming, as Van Roy believed: to solve a programming problem, you need to choose the right concept; To solve multiple problems, you need to combine multiple concepts that are in different parts.

reference

• Programming paradigm
• Major Programming Paradigms
• Interface oriented programming
• The forgotten history of object-oriented programming
• The dumb programming paradigm

---

For more articles, please pay attention to the official number: