A description of Interface that is often mistaken

Introduction

This is the first post in a few years, but since I was in Java, I feel that there are few articles that explain Interface properly in object-oriented explanations, so I will write it out once.

I think I wrote it a long time ago, but maybe it's because of it. .. ..

Conclusion

I think the explanation in the TypeScript code below is correct.

interface Task {
  name: string;
  task: () => string;
}
class Test implements Task {
  name: string;
  task() {
    return `${this.name} san`;
  }
  constructor(name: string) {
    this.name = name;
  }
}
class Hoge implements Task {
  name: string;
  id: number;
  task() {
    return `${this.name} #${this.id} chan`;
  }
  constructor(name: string, id: number) {
    this.name = name;
    this.id = id;
  }
}
function task_twise(task: Task): string {
  return task.task() + task.task();
}

Common explanation part 1

The most

code

interface Task {
  name: string;
  task: () => string;
}

class Test implements Task {
  name: string;
  task() {
    return `${this.name} san`;
  }
  constructor(name: string) {
    this.name = name;
  }
}

const test = new Test("test");
console.log(test.task())

Explanation of the contents

--The Task interface defines a variable called name and a function called task --The Test class implements the Task interface, and when you execute the task, it returns with "san" in the name. --When you create and execute Test class, task is executed.

What's wrong

――Even if a beginner sees this, he only has the question, "Why do you have to do the troublesome interface?" --It holds even if there is no Task interface. ――Some people explain the mystery like "It's important to define the interface like this."

Common explanation part 2

code

Only the second line from the end changes as follows

const test:Task = new Test("test");

What's wrong

――Since it is received by Task, it seems that Task is useful at first glance, but it seems that it is not necessary after all ――It doesn't matter if you don't

Common explanation part 3

I haven't actually seen it, but there are quite a few similar shapes like this.

code

class Test implements Task {
  name: string;
  task() {
    return `${this.name} san`;
  }
  constructor(name: string) {
    this.name = name;
  }
}

class Hoge implements Task {
  name: string;
  id: number;
  task() {
    return `${this.name} #${this.id} chan`;
  }
  constructor(name: string, id: number) {
    this.name = name;
    this.id = id;
  }
}

let test: Task = new Test("test");
console.log(test.task());
test = new Hoge("hoge", 123)
console.log(test.task());

Commentary

--Hoge class that implements Task interface like Test class is now available --You can put another object in the same Task type variable and execute it.

What's wrong

――It's not so bad ――However, I don't feel the need to reuse variables. ――It's okay to declare two separately (or rather, it's better to do so)

So in the first code

Repost

interface Task {
  name: string;
  task: () => string;
}
class Test implements Task {
  name: string;
  task() {
    return `${this.name} san`;
  }
  constructor(name: string) {
    this.name = name;
  }
}
class Hoge implements Task {
  name: string;
  id: number;
  task() {
    return `${this.name} #${this.id} chan`;
  }
  constructor(name: string, id: number) {
    this.name = name;
    this.id = id;
  }
}
function task_twise(task: Task): string {
  return task.task() + task.task();
}

Commentary

--Test, Hoge class making is the same --Apart from that, prepare a function that receives a Task and executes it twice. --This function is separate from the Test and Hoge implementations, so changing the Test and Hoge implementations will not affect it. --It is not affected even if you change the class name, and task_twise can be executed even if another class appears.

What i have to teach

――In addition to this, I think it would be good to explain that workers A and B can be divided and each can work separately on the implementation side and the user side while looking at the interface file. --Interface as a so-called stub --It is necessary to teach that the interface is the boundary surface of the function. --There is no point in making it so that implementations other than the interface do not interfere with each other beyond the boundary surface of the function. --First of all, it is necessary to assume that the source code will be rewritten. --You need a motive to minimize the impact when rewriting ――It is necessary to teach that what can be abstracted is abstracted in order to keep it to a minimum. ――It is necessary to teach how to prevent the propagation of bugs by abstracting and interface.

at the end

So, to be honest, if you just look at this source, you will not understand it, so you can relive that it will be difficult to rewrite the source if you do not define any interface. I think such an explanation would be good.