建模与抽象是两个概念

    

     我们在前面的第三章第一节中介绍了需求的拆分和业务建模的过程，但是并没有谈到如何做模型抽象。

     建模是为了满足基本的业务场景，抽象是为了实现更灵活的拓展能力。

     抽象是为了更灵活的应对业务，单纯从业务建模来说即便是不抽象也不影响业务建模。因此业务建模不是说必须得抽象。

什么是抽象

我们先来理解一下什么叫做抽象，举例来说：

         公司里有两个部门，分别是研发部门和财务部门，研发部门经常需要出差，然后需要找财务部门报销费用，财务部门就安排了小红会计来负责对接研发部门的报销事项。但是财务部门的小红工作比较忙经常顾不上来，这样研发部门还得每次对接报销费用的时候还需要等待小红的时间，为了让研发部门报销流程更加流畅，财务部门安排了小丽经理负责，小丽经理下有5个会计人员，这样每次研发部门需要报销的时候直接找小丽经理，小丽经理会根据会计人员的情况，每次安排一人与研发部门对接，这样以后研发部门的报销流程就不再出现问题了。

   在这个例子中，小丽经理就是一个“抽象”的存在，研发部门不需要知道具体的会计是谁，也不需要了解会计的工作细节，他们只需要和小丽经理交互，提交报销请求。小丽经理会根据自己的内部流程（这些是研发部门不需要关心的），安排具体的会计人员来处理这个请求。通过这种方式，报销流程得以简化，研发部门的工作效率也得到提升。 这就是抽象的核心概念：将复杂的细节隐藏起来，只提供简单的接口，让使用者不需要了解内部的复杂性就能完成工作。在面向对象编程中，抽象通常是通过创建抽象类或接口来实现的。这些抽象类或接口定义了一组方法（就像小丽经理提供的报销服务），但并没有提供具体的实现（就像小丽经理并没有自己去处理每一个报销请求）。具体的实现是由继承抽象类或实现接口的具体类来完成的（就像小丽经理的会计人员）。这样，代码的使用者只需要依赖抽象的接口，就可以让具体的实现来处理复杂的工作。这使得代码更易于理解和维护，也更具有灵活性。

抽象的两个关键点：

   抽象必会采用多态 

   使用方依赖其抽象

为什么要抽象？

简化复杂性

    结合上面的例子，研发部门不需要知道财务部门内部如何处理报销的所有细节，他们只需要知道报销请求应该提交给小丽经理。这个抽象（小丽经理）隐藏了财务部门的内部复杂性，使研发部门可以专注于他们自己的工作。

增强可重用性

    结合上面的例子，小丽经理为所有需要报销的部门提供了一个统一的接口。这意味着不只是研发部门，其他需要报销的部门也可以复用这个接口。通过这种方式，小丽经理的角色（即这个抽象）增强了系统的可重用性。

提供扩展性

   结合上面的例子，如果公司需要改变报销的处理方式，或者添加新的处理步骤，他们只需要更改小丽经理的操作流程，而不需要通知和修改其他部门的操作方式。因此，这个抽象提供了系统的扩展性。

促进了封装

     结合上面的例子，小丽经理封装了财务部门处理报销的具体细节。其他部门不需要了解这些细节，也不能直接干预这些细节。这提高了系统的稳定性和安全性，因为每个部门都只能通过小丽经理来进行报销，不能直接操作财务部门的内部流程。

该如何抽象？

先说四个观点：

   抽象是为了更灵活的应对业务，单纯从业务建模来说即便是不抽象也不影响业务建模。因此业务建模不是说必须得抽象。  

   抽象也不是越多越好，凡事都有一个度，过度的抽象会让系统变得更复杂，因此应该做到只满足当前的场景即可，不要过度抽象。 

   抽象与设计模式无关，在做抽象设计的时候不要刻意的与设计模式向靠拢，并不是采用了设计模式才是抽象 

   抽象是一种设计能力，是需要根据自己的设计经验不断的锻炼出来的能力，抽象也是一个仁者见仁智者见智的事情，同样的场景不同的人设计出来的模型会存在差异，但是抽象建模是有评价依据的，评价依据就是SOLID原则，我们需要反思思考理解这些原则，然后再调整自己的模型，但是不要求一蹴而就，尽量要根据自己的经验来不断提升。

抽象的运用方式：

   简单来说，只要你在模型中提炼出来了接口、抽象类，然后通过继承、实现的方式在对象中使用了他们，就可以说你已经运营上了抽象了。 

   由于抽象的能力不同，所提来出来的抽象概念可能不是特别合适，但是随着你对SOLID原则的理解，然后不断的锻炼自己的抽象建模能力，慢慢你会具备良好的抽象能力的，所以我们可以先做将其运用上，然后再考虑不断的优化。另在再强调一点，建模本身是可以不需要抽象的，因此在做抽象之前，先要确保业务建模是可以满足需求的，不要在建模的过程中刻意的追求锻炼抽象能力。