抽象的目的绝对不是复用，而是为了清晰的设计。从某种意义上讲，抽象分为两种，一种是绝对抽象，只有神态，没有实体，另一种是轮廓抽象，或者半抽象，有了基本的架子，留下空间去具体化。前一种我们常称之为接口interface，后一种我们常称之为抽象类abstract class。对于前端代码而言，在传统前端开发模式中，不存在这两种中的任何一种，对于abstract class则可能存在一些雏形，例如：

class Some {
  stay() {
    throw new Error('stay should be overrided')
  }
}

此类处理虽然可行，但是在最终代码中会多出来许多没有用的代码，增加代码量。只有在我们引入ts之后，才有了真正的抽象代码。例如：

abstract class Some {
  abstract stay(): void
}

这段代码定义了一个抽象类，它不能被new实例化，只能被extends扩展。扩展时，带有abstract前缀的成员必须被实现，否则编译阶段会报错，而在最终生成的代码中，不存在这些abstract成员，这样就可以使代码量最小化。

在具体业务中，哪些内容可以抽象，哪些不可以呢？

其实对于前端而言，基于interface的抽象（业务层面）几乎没有，我们很少会去写一个用于描述业务的interface，而且这完全没有必要。我们大部分情况下使用abstract class进行抽象，甚至在大部分情况下，不需要abstract，直接使用class进行抽象。这里抽象脱离了技术层面的抽象，而是对业务进行抽象，同时由于大部分前端场景中，同一业务是固定不变的，因此，这类抽象可以被具体实现。例如对于同一对象实体，我们直接对其进行建模。再例如，我们直接对数据请求进行建模。对于数据的操作，我们进行建模。总之，你会发现，抛开界面和交互的一切，都是可以进行建模处理的，这个部分全部可以抽象出来，在代码中形成一块封闭的可扩展的代码块，需要时被取出来使用，不需要时不import，对当前毫无影响。

最麻烦的是界面和交互的抽象。

先看下交互的抽象，由于交互动作往往会引起界面的变化，所以我们在对交互进行建模时，就必须预留下可产生界面变化的abstract成员，从而可以使界面产生变化。例如：

abstract class SomeView extends View {
  @inject(SomeController)
  controller: SomeController

  abstract confirm(message: string, onOk: Function): void

  deleteItem(id) {
    this.confirm('确定删除吗？', () => {
      // 执行删除
    })
  }
}

上面代码中，我们预留了一个confirm方法，对于具体的某个view而言，必须扩展这个confirm方法来，为什么要留呢？因为confirm往往需要弹出一个对话框，同时，这个对话框一定是一个中间态，用户点击它的按钮之后，一定还会有后续界面变化。这种界面的流动过程，无法通过简单的处理来实现。当然，如果你想具体化，还可以借助react的state，例如：

class SomeView extends View {
  state = {
    showConfirm: false,
    deleteItemId: null,
  }

  deleteItem(id) {
    this.setState({ showConfirm: true, deleteItemId: id })
  }

  handleDeleteItem() {
    // 执行删除动作
  }
}

通过以上方式确实可以做到提供完整的动作，但是这就意味着必须按照react的状态管理模式进行编程，而且对于使用方来说，一个动作的方法太多了，在实现时，不仅要调用deleteItem还要再调用handleDeleteItem。不过，从另外一个角度看，这似乎又是正确的一种做法。

最后看下界面的抽象。这个时最难的，因为不同端端界面呈现是不一样的。比如PC和APP上。但是我们也不是不能做，其前提是开发者，或者项目的架构师，在前期规划了非常细腻的业务组件，我们所有的业务开发，基于已有的业务组件进行，我们写代码，更想写配置或DSL，比如下面：

<Page>
  <ProjectBasicInfo />
  <ProjectMembers />
  <ProjectDeals />
  <Tabs>
    <CompanyInfo />
    <FinancingInfo />
  </Tabs>
</Page>

这样一段代码，更像是一个页面的结构描述，至于每一个部分都具体展示什么内容，怎么展示，界面交互怎样，PC和APP上的差异，全靠业务组件内自己去实现，通过这种方式来进行界面的抽象，可以最大程度的抹平不同端的差异，但是对团队和架构师的要求会比较高，当然收益也是显而易见的，就是效率很高。