CN113360219A - 一种呼叫线路接入方法、装置、设备及可读存储介质 - Google Patents

Abstract

本申请公开了一种呼叫线路接入方法、装置、设备及可读存储介质，方法包括：确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑所在的目标抽象类；添加继承目标抽象类的新线路子类并在其中添加新独有逻辑，实现新呼叫线路的接入；呼叫逻辑结构的建立过程包括：建立呼叫骨架；确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中。本申请公开的上述技术方案，在进行新呼叫线路接入时只需继承预先建立的呼叫逻辑结构中的通用逻辑，并在其中添加新线路子类且在新线路子类中添加新独有逻辑即可，以降低新呼叫线路接入的复杂度和成本，且避免对其他呼叫线路造成影响。

Description

一种呼叫线路接入方法、装置、设备及可读存储介质

技术领域

本申请涉及呼叫业务处理技术领域，更具体地说，涉及一种呼叫线路接入方法、装置、设备及可读存储介质。

背景技术

随着呼叫业务的频繁迭代，需依赖硬件设备进行外呼的硬呼和不需购买任何硬件设备、只需通过上网登录的方式即可进行外呼的云呼得到了广泛应用。

目前，在呼叫业务中，云呼内部各线路的逻辑代码、硬呼内部的线路逻辑代码全部耦合在一起，线路比较复杂。当在呼叫业务中接入新线路时，不仅需要对现有耦合在一起的逻辑进行修改，并在内部添加上新的逻辑，而且需要在修改之后对每条线路进行测试，以通过测试确定逻辑修改是否对其他呼叫线路造成影响，若造成影响，则需要重新对逻辑进行修改，直至能够实现新线路的接入且新线路的接入并未对其他呼叫线路造成影响为止。由此可知，上述这种呼叫线路接入方式的复杂度比较高、工作量比较大、成本比较高，而且可能会对其他呼叫线路的运行造成影响。

综上所述，如何降低呼叫线路接入的复杂度和成本，并避免对其他呼叫线路造成影响，是目前本领域技术人员亟待解决的技术问题。

发明内容

有鉴于此，本申请的目的是提供一种呼叫线路接入方法、装置、设备及可读存储介质，用于降低呼叫线路接入的复杂度和成本，并避免对其他呼叫线路造成影响。

为了实现上述目的，本申请提供如下技术方案：

一种呼叫线路接入方法，包括：

根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定所述新独有逻辑继承的通用逻辑及所述通用逻辑所在的目标抽象类；

在所述呼叫逻辑结构中添加继承所述目标抽象类的新线路子类，在所述新线路子类中添加所述新独有逻辑，利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入；

所述呼叫逻辑结构的建立过程包括：

建立呼叫骨架；所述呼叫骨架包括呼叫抽象类、继承所述呼叫抽象类的云呼抽象类及硬呼抽象类、继承所述云呼抽象类的多个云呼线路子类、继承所述硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中；所述通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，所述独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

优选的，还包括：

当接收到呼叫线路修改请求时，从所述呼叫逻辑结构中确定与所述呼叫线路修改请求对应的修改线路子类，从所述修改线路子类和/或继承的抽象类中调用与所述呼叫线路修改请求对应的逻辑，并根据所述呼叫线路修改请求对调用的逻辑进行修改。

优选的，在将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中之后，还包括：

获取与硬呼对应的独有逻辑抽象方法、与云呼对应的独有逻辑抽象方法，并将所述与硬呼对应的独有逻辑抽象方法存放到所述硬呼抽象类中，将所述与云呼对应的独有逻辑抽象方法存放到所述云呼抽象类中；

按照模板方法对对应的通用逻辑和对应的独有逻辑抽象方法进行组装，并将组装得到的与云呼对应的通用模板存放到所述云呼抽象类中，且将组装得到的与硬呼对应的通用模板存放到所述硬呼抽象类中；

确定模板抽象方法，将所述模板抽象方法作为通用模板存放到所述呼叫抽象类中；

相应地，在利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入之后，还包括：

当接收到呼叫请求时，确定与所述呼叫请求对应的目标线路子类及目标通用模板，从所述目标线路子类中调用与所述目标通用模板对应的独有逻辑，从所述目标子线路继承的抽象类中调用与所述目标通用模板对应的通用逻辑，利用调用的通用逻辑和独有逻辑按照所述目标通用模板实现与所述呼叫请求对应的呼叫。

优选的，从当前已有呼叫线路中确定通用逻辑，包括：

获取使用当前逻辑的呼叫线路的数量，判断使用所述当前逻辑的呼叫线路的数量是否大于同类型呼叫线路总数量的一半；

若是，则将所述当前逻辑确定为通用逻辑。

优选的，还包括：

当所述当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半；

若是，则将相同的独有逻辑作为新通用逻辑，在第一触发方子类继承的抽象类中添加所述新通用逻辑，将所述第一触发方子类中所述相同的独有逻辑移除，并在第一受影响方子类中与所述新通用逻辑相同的独有逻辑上添加废弃注解，且当对所述第一受影响方子类处理时删除添加有所述废弃注解的独有逻辑；

其中，所述第一触发方子类为独有逻辑主动发生变更而得到所述新通用逻辑的线路子类，所述第一受影响方子类为逻辑未发生变更且在所述第一触发方子类中的独有逻辑发生变更时，内部独有逻辑被动变更为所述新通用逻辑的线路子类。

优选的，还包括：

当所述当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量；其中，所述变更逻辑为对所述未变更通用逻辑进行变更得到的独有逻辑；

若是，则在第二触发方子类中复写所述未变更通用逻辑，并在所述第二触发方子类继承的抽象类中的所述未变更通用逻辑上添加废弃注解，且当对最后一个第二受影响方子类进行处理时，在最后一个所述第二受影响方子类中复写所述未变更通用逻辑，并删除所述抽象类中添加有所述废弃注解的所述未变更通用逻辑；

其中，所述第二触发方子类为主动引起所继承的所述抽象类中的所述未变更通用逻辑进行变更的线路子类，所述第二受影响方子类为逻辑未主动发生变更、与所述第二触发方子类共同继承所述抽象类且共用所述未变更通用逻辑的线路子类。

一种呼叫线路接入装置，包括：

确定模块，用于根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定所述新独有逻辑继承的通用逻辑及所述通用逻辑所在的目标抽象类；

添加模块，用于在所述呼叫逻辑结构中添加继承所述目标抽象类的新线路子类，在所述新线路子类中添加所述新独有逻辑，利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入；

还包括用于建立所述呼叫逻辑结构的建立模块，所述建立模块包括：

建立单元，用于建立呼叫骨架；所述呼叫骨架包括呼叫抽象类、继承所述呼叫抽象类的云呼抽象类及硬呼抽象类、继承所述云呼抽象类的多个云呼线路子类、继承所述硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中；所述通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，所述独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

优选的，还包括：

修改模块，用于当接收到呼叫线路修改请求时，从所述呼叫逻辑结构中确定与所述呼叫线路修改请求对应的修改线路子类，从所述修改线路子类和/或继承的抽象类中调用与所述呼叫线路修改请求对应的逻辑，并根据所述呼叫线路修改请求对调用的逻辑进行修改。

一种呼叫线路接入设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述任一项所述的呼叫线路接入方法的步骤。

一种可读存储介质，所述可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如上述任一项所述的呼叫线路接入方法的步骤。

本申请提供了一种呼叫线路接入方法、装置、设备及可读存储介质，其中，该方法包括：根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑及通用逻辑所在的目标抽象类；在呼叫逻辑结构中添加继承目标抽象类的新线路子类，在新线路子类中添加新独有逻辑，利用新独有逻辑及通用逻辑实现新呼叫线路的接入；呼叫逻辑结构的建立过程包括：建立呼叫骨架；呼叫骨架包括呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的多个云呼线路子类、继承硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中；通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

本申请公开的上述技术方案，通过预先建立包含有呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的云呼线路子类、继承硬呼抽象类的硬呼线路子类的呼叫骨架，并将确定出的通用逻辑存放到呼叫骨架中对应的抽象类中，将独有逻辑存放到对应的线路子类中实现逻辑的分层、通用逻辑的复用及独有逻辑的专用，从而降低云呼和硬呼的耦合度、云呼内部线路的耦合度及硬呼内部线路的耦合度，并降低整个呼叫业务内部的复杂度。在建立呼叫逻辑结构基础上，当接收到新呼叫线路接入请求时，只需在呼叫逻辑结构中添加对应的新线路子类并在新线路子类中添加新独有逻辑即可利用新线路子类中添加的新独有逻辑及其继承的通用逻辑实现新呼叫线路的接入，以实现通用逻辑的复用，且无需再如现有技术一样需要对耦合在一起的逻辑进行修改才能实现新呼叫线路的接入，因此，则并不会对其他已有的呼叫线路的逻辑造成影响，且可以降低新呼叫线路接入的复杂度和成本。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有呼叫线路的连接示意图；

图2为本申请实施例提供的一种呼叫线路接入方法的流程图；

图3为本申请实施例提供的呼叫逻辑结构的示意图；

图4为电话宝的连接示意图；

图5为对图1中已有呼叫线路进行呼叫逻辑结构建立后得到的示意图；

图6为对图1中已有呼叫线路建立呼叫逻辑结构后各呼叫线路的实现流程示意图；

图7为本申请实施例提供的一种呼叫线路接入装置的结构示意图；

图8为本申请实施例提供的一种呼叫线路接入设备的结构示意图。

具体实施方式

在现有技术中，云呼内部各线路的逻辑代码、硬呼内部的线路逻辑代码全部耦合在一起，其中，云呼即为云呼叫，不需要购买任何硬件设备、只需通过上网登录的方式即可进行外呼，硬呼即为硬件呼叫，依赖硬件设备进行外呼，比如4G话机、电话宝、固话等。当新呼叫线路接入时需要对现有耦合在一起的逻辑进行修改(例如需要对新呼叫线路和其他线路共用的逻辑进行修改，以使其能够分辨具体是哪条呼叫线路)，并添加新的逻辑，但是，由于逻辑耦合在一起，因此，逻辑的修改则可能会导致原有呼叫线路出现问题，为此，则需要对在修改后对原有的每条呼叫线路进行测试，以确定逻辑修改是否对现有呼叫线路造成影响，并确定对现有呼叫线路造成影响时重新进行逻辑的修改和测试，直至能够实现新线路的接入且新线路的接入并未对其他呼叫线路造成影响为止。例如图1所示，其示出了现有呼叫线路的连接示意图，其以三条呼叫线路为例，线路A、线路B和线路C的某些逻辑耦合在一起，图中的1代表为一条线路所用的逻辑，2代表为两条线路所用的逻辑，3代表为三条线路所用的逻辑，由图1可知，呼叫线路间千丝万缕，盘根错节，牵一发而动全身。由此可知，现有这种呼叫线路接入方法会导致新呼叫线路接入的复杂度及成本比较高，且会导致工作量比较大、效率比较低。

为此，本申请提供一种呼叫线路接入的技术方案，用于降低呼叫线路接入的复杂度和成本，并避免呼叫线路的接入对其他呼叫线路造成影响。

为了使本领域技术人员更清楚地理解本技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参见图2和图3，其中，图2示出了本申请实施例提供的一种呼叫线路接入方法的流程图，图3示出了本申请实施例提供的呼叫逻辑结构的示意图。

本申请实施例提供的一种呼叫线路接入方法，可以包括：

S11：建立呼叫骨架；呼叫骨架包括呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的多个云呼线路子类、继承硬呼抽象类的多个硬呼线路子类。

在进行呼叫线路接入之前，可以预先建立呼叫骨架，且该呼叫骨架具体包括呼叫抽象类、云呼抽象类、硬呼抽象类、多个云呼线路子类、多个硬呼线路子类。其中，呼叫抽象类用于存放云呼和硬呼的通用逻辑(即后续提及的呼叫通用逻辑)，比如号码黑名单检测、防封号检测等；云呼抽象类用于存放仅可应用于云呼的通用逻辑(即后续提及的云呼通用逻辑)，比如是否已购买坐席和外显号码，云呼抽象类继承呼叫抽象类，隐式植入呼叫抽象类中的通用逻辑；硬呼抽象类用于存放仅可应用于硬呼的通用逻辑(即后续提及的硬呼通用逻辑)，比如客户端软件连接检测，硬呼抽象类继承呼叫抽象类，隐式植入呼叫抽象类中的通用逻辑；各云呼线路子类用于继承云呼抽象类，内部存放自己线路的独有逻辑(即后续提及的云呼线路独有逻辑)；各硬呼线路子类用于继承硬呼抽象类，内部存放自己线路的独有逻辑(即后续提及的硬呼线路独有逻辑)，比如电话宝需要存放固话连接检测逻辑，其中，电话宝是将固定电话和电脑连接起来的桥梁，且具备通话信息记录和录音的功能，如图4所示，其示出了电话宝的连接示意图。

需要说明的是，上述提及的类即为存放一些数据和逻辑的载体，且继承即为一个类继承另一个类，前者叫子类，后者叫父类，子类将拥有父类所拥有的东西。通过上述过程可知，本申请将呼叫骨架分为三层，第一层包含呼叫抽象类，第二层包含硬呼抽象类和云呼抽象类，第三层包含各云呼线路子类和各硬呼线路子类。另外，在呼叫业务中，每个呼叫线路对应一个线路子类，如图3所示，对于云呼线路，其以包含云呼线路子类A、云呼线路子类B这两个线路子类为例进行说明，对于硬呼线路，其以包含硬呼线路子类A、硬呼线路子类B和硬呼线路子类C这三个线路子类为例进行说明。当然，图3仅以举例的方式表明云呼线路子类和硬呼线路子类与对应的抽象类之间的关系，并不限定云呼线路子类和硬呼线路子类只有这几个。

S12：从当前已有呼叫线路中确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中；通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

在执行完步骤S11之后，可以对呼叫中心当前已有呼叫线路进行分析和分解，以确定通用逻辑和独有逻辑，其中，这里提及的通用逻辑包括呼叫通用逻辑、云呼通用逻辑和硬呼通用逻辑，独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。之后，则将确定出的通用逻辑存放到呼叫骨架中对应的抽象类中，将确定出的独有逻辑存放到呼叫骨架中对应的线路子类中，具体地，也即将呼叫通用逻辑存放到呼叫抽象类中，将云呼通用逻辑存放到云呼抽象类中，将硬呼通用逻辑存放到硬呼抽象类，将各云呼线路独有逻辑存放到对应的云呼线路子类中，将各硬呼线路独有逻辑存放到对应的硬呼线路子类中。后续在进行现有已有呼叫线路实现时，可以从对应的线路子类中调用与该呼叫线路对应的独有逻辑，从对应的线路子类继承的抽象类中调用与该呼叫线路对应的通用逻辑(具体可根据呼叫线路的功能按照一定的顺序进行逻辑的调用)，以利用所调用的逻辑实现与呼叫线路对应的功能，由此可知，上述过程并不会对现有已有呼叫线路造成影响。具体可以参见图5和图6，其中，图5示出对图1中已有呼叫线路进行呼叫逻辑结构建立后得到的示意图，图6示出了对图1中已有呼叫线路建立呼叫逻辑结构后各呼叫线路的实现流程示意图，其中，实现框代表独有逻辑，虚线框代表通用逻辑，其相比图1而言，实现了垂直模块划分、线性化，且具有明确垂直模块边界。

通过上述步骤S11和步骤S12可以抽取通用逻辑，多层抽象，统一管理，共同引用，便于复用及后续扩展；每个呼叫线路各成一体，相互独立，独有逻辑各自保管维护，即实现将通用逻辑和独有逻辑进行分层，并实现通用逻辑的复用和独有逻辑的专用，降低云呼和硬呼之间的耦合度、云呼内部各线路之间的耦合度及硬呼内部各线路之间的耦合度，且降低整个呼叫业务内部的复杂度，使得整个呼叫业务内部逻辑更加清晰。

需要说明的是，步骤S11和步骤S12即为预先建立呼叫逻辑结构的具体实现过程，该过程对于各呼叫中心而言可以只进行一次，后续每当有新呼叫线路接入时可以直接在上述建立得到的呼叫逻辑结构基础上进行实现，而无需每次在新呼叫线路接入时均执行步骤S11和步骤S12。

S13：根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑及通用逻辑所在的目标抽象类。

当需要接入新呼叫线路时，可以接收相关人员等发送的新呼叫线路接入请求，在接收到新呼叫线路接入请求之后，根据该新呼叫线路接入请求确定要接入的新呼叫线路对应的新独有逻辑。之后，可以确定新独有逻辑在预先建立的呼叫逻辑结构中继承的通用逻辑，并确定新独有逻辑继承的通用逻辑所在的目标抽象类。其中，这里提及的继承的通用逻辑可以包含具体是硬呼通用逻辑还是云呼通用逻辑(硬呼通用逻辑或云呼通用逻辑与新独有逻辑为直接继承关系)，即继承的通用逻辑具体可以包括呼叫骨架中第二层中的抽象类中所存放的通用逻辑，且目标抽象类可以包含具体是硬呼抽象类还是云呼抽象类，即目标抽象类具体可以包括呼叫骨架中第二层中的抽象类，例如：以要接入硬呼线路D为例，确定其对应的新独有逻辑为d，继承硬呼通用逻辑，此时，则可以确定其对应的目标抽象类为硬呼抽象类。另外，新独有逻辑继承的通用逻辑中还可以包含呼叫通用逻辑(其与新独有逻辑之间为间接继承关系)，即继承的通用逻辑还可以包括呼叫骨架中第一层中的抽象类中所存放的通用逻辑，相应地，目标抽象类中也还可以包括呼叫抽象类，即目标抽象类还可以包括呼叫骨架中第一层中的抽象类。

S14：在呼叫逻辑结构中添加继承目标抽象类的新线路子类，在新线路子类中添加新独有逻辑，利用新独有逻辑及通用逻辑实现新呼叫线路的接入。

当确定目标抽象类中，则可以在预先建立的呼叫逻辑结构中添加继承目标抽象类的新线路子类，具体地，是根据目标抽象类中位于呼叫骨架第二层中的抽象类来添加与其对应且继承该抽象类的新线路子类，例如：结合上述的举例，对于要接入的硬呼线路D，则可以在呼叫逻辑结构中添加继承硬呼抽象类的新硬呼线路子类D。

在呼叫逻辑结构中添加完新线路子类之后，可以在新线路子类中添加新呼叫线路对应的新独有逻辑，以利用新线路子类中的新独有逻辑及新线路子类继承的抽象类中的通用逻辑实现新呼叫线路的接入。

通过上述过程可知，本申请在进行新呼叫线路接入时，只需继承预先建立的呼叫逻辑结构中的通用逻辑，并对应添加新线路子类且在对应新线路子类中添加新独有逻辑即可，而无需对已有的逻辑进行修改，因此，则可以避免对已有的呼叫线路造成影响，且无需再对每条呼叫线路进行测试，以进行后续逻辑的修改和测试等，因此，则可以降低新呼叫线路接入的复杂度和工作量，且可以降低新呼叫线路的接入成本。

本申请公开的上述技术方案，通过预先建立包含有呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的云呼线路子类、继承硬呼抽象类的硬呼线路子类的呼叫骨架，并将确定出的通用逻辑存放到呼叫骨架中对应的抽象类中，将独有逻辑存放到对应的线路子类中实现逻辑的分层、通用逻辑的复用及独有逻辑的专用，从而降低云呼和硬呼的耦合度、云呼内部线路的耦合度及硬呼内部线路的耦合度，并降低整个呼叫业务内部的复杂度。在建立呼叫逻辑结构基础上，当接收到新呼叫线路接入请求时，只需在呼叫逻辑结构中添加对应的新线路子类并在新线路子类中添加新独有逻辑即可利用新线路子类中添加的新独有逻辑及其继承的通用逻辑实现新呼叫线路的接入，以实现通用逻辑的复用，且无需再如现有技术一样需要对耦合在一起的逻辑进行修改才能实现新呼叫线路的接入，因此，则并不会对其他已有的呼叫线路的逻辑造成影响，且可以降低新呼叫线路接入的复杂度和成本。

本申请实施例提供的一种呼叫线路接入方法，还可以包括：

当接收到呼叫线路修改请求时，从呼叫逻辑结构中确定与呼叫线路修改请求对应的修改线路子类，从修改线路子类和/或继承的抽象类中调用与呼叫线路修改请求对应的逻辑，并根据呼叫线路修改请求对调用的逻辑进行修改。

在本申请中，在预先建立呼叫逻辑结构中之后，若接收到呼叫线路修改请求，则可以从呼叫逻辑结构中确定与呼叫线路修改请求对应的修改线路子类，并根据呼叫线路修改请求从修改线路子类和/或该修改线路子类继承的抽象类中调用与呼叫线路修改请求对应的逻辑，具体地，若根据呼叫线路修改请求确定需要对修改线路子类中的独有逻辑进行修改，则从修改线路子类中调用与呼叫线路修改请求对应的独有逻辑，并根据呼叫线路修改请求对调用的独有逻辑进行修改；若根据呼叫线路修改请求确定需要对修改线路子类继承的抽象类中的通用逻辑进行修改，则从修改线路子类继承的抽象类中调用与呼叫线路修改请求对应的通用逻辑，并根据呼叫线路修改请求对调用的通用逻辑进行修改；若根据呼叫线路修改请求确定需要对修改线路子类及其继承的抽象类中的逻辑都进行修改，则从修改线路子类及其继承的抽象类中调用对应的与呼叫线路修改请求对应的逻辑，并根据呼叫线路修改请求对调用的逻辑进行修改。

通过上述过程可以实现通用逻辑到相应的抽象类中进行修改，保证修改在可评估范围内或指定范围内，好评估影响点，各自独有逻辑到各自内部去修改，互不影响。且由于该过程可以实现仅对指定逻辑的修改，而并不会对其他逻辑造成影响，因此，则可以减小修改的影响范围，且后续可以仅对修改逻辑对应的呼叫线路进行测试即可，实现修改的便利性，提高修改效率。

本申请实施例提供的一种呼叫线路接入方法，在将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中之后，还可以包括：

获取与硬呼对应的独有逻辑抽象方法、与云呼对应的独有逻辑抽象方法，并将与硬呼对应的独有逻辑抽象方法存放到硬呼抽象类中，将与云呼对应的独有逻辑抽象方法存放到云呼抽象类中；

按照模板方法对对应的通用逻辑和对应的独有逻辑抽象方法进行组装，并将组装得到的与云呼对应的通用模板存放到云呼抽象类中，且将组装得到的与硬呼对应的通用模板存放到硬呼抽象类中；

确定模板抽象方法，将模板抽象方法作为通用模板存放到呼叫抽象类中；

相应地，在利用新独有逻辑及通用逻辑实现新呼叫线路的接入之后，还可以包括：

当接收到呼叫请求时，确定与呼叫请求对应的目标线路子类及目标通用模板，从目标线路子类中调用与目标通用模板对应的独有逻辑，从目标子线路继承的抽象类中调用与目标通用模板对应的通用逻辑，利用调用的通用逻辑和独有逻辑按照目标通用模板实现与呼叫请求对应的呼叫。

在本申请中，在将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中之后，可以获取与硬呼对应的独有逻辑抽象方法、与云呼对应的独有逻辑抽象方法，之后，则可以将与硬呼对应的独有逻辑抽象方法存放到硬呼抽象类中，将与云呼对应的独有逻辑抽象方法存放到云呼抽象类中，其中，这里提及的抽象方法可认为是一个算法骨架，具体的独有逻辑实现方法在对应的线路子类中，例如：对于硬呼而言，可以将“硬件连接检测”作为一个与硬呼对应的独有逻辑抽象方法而存放到硬呼抽象类中，对于电话宝具体实现硬件连接检测的独有逻辑实现方法则可以存放到电话宝对应的硬呼线路子类中。

在上述基础上，可以按照模板方法对与模板方法对应的通用逻辑(具体可以包括呼叫通用逻辑这一层、云呼通用逻辑和硬呼通用逻辑这一层)和与模板方法对应的独有逻辑抽象方法进行组装，并将利用呼叫通用逻辑、云呼通用逻辑和对应的与云呼对应的独有逻辑抽象方法组装得到的与云呼对应的通用模板存放到云呼抽象类中(即图3中对应的模板实现方法)，且将利用呼叫通用逻辑、硬呼通用逻辑和对应的与硬呼对应的独有逻辑抽象方法组装得到的与硬呼对应的通用模板存放到硬呼抽象类中。其中，模板方法定义一个操作中的算法骨架，而将算法的一些步骤延迟到具体的线路子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。例如：使用呼叫中心进行呼叫前会进行一些是否可以进行呼叫的检测(具体叫呼叫能力检测)，以硬呼为例，其呼叫能力检测包括三块，第一块为“号码黑名单检测”，第二块为“客户端软件连接检测”，第三块为“硬件连接检测”，因为每个硬呼方式都需要做呼叫能力检测，但里面的实现逻辑可能又不尽相同，因此，无法将其整个作为通用逻辑，此时，可以将呼叫能力检测作为一个通用模板放到硬呼抽象类中：对于硬呼而言，根据业务优先级，可以按照第二块、第三块、第一块的顺序将三块逻辑做成通用模板存放到硬呼抽象类中。与此同时，还可以确定模板抽象方法，并将模板抽象方法作为通用模板存放到呼叫抽象类中，例如：上述提及的“呼叫能力检测”这一模板抽象方法即可作为一个通用模板存放到呼叫抽象类中。

之后，在利用新独有逻辑及其继承的通用逻辑实现新呼叫线路的接入之后，当接收到呼叫请求后，则可以从呼叫逻辑结构中确定与呼叫请求对应的目标线路子类及目标通用模板，并从目标线路子类中调用与目标通用模板对应的独有逻辑，从目标线路子类继承的抽象类中调用与目标通用模板对应的通用逻辑，利用调用的通用逻辑和独有逻辑按照目标通用模板实现与呼叫请求对应的呼叫，例如：用户在页面上选择使用电话宝打电话时，则可以通过页面传过来电话宝这个标识，并找到对应的电话宝子类，在对电话宝进行呼叫能力检测时，则可以在呼叫抽象类及硬呼抽象类中确定相应的目标通用模板，然后，根据硬呼抽象类中与呼叫能力检测对应的通用模板来从硬呼抽象类中拿到“客户端软件连接检测”这块通用逻辑，去电话宝子类中获取“硬件连接检测”这块独有逻辑，并从呼叫抽象类中拿到“号码黑名单检测”这块通用逻辑，以实现电话宝对应的呼叫能力检测。

上述这种通过模板方法对逻辑进行编排组装，得到通用模板的方式便于快速、准确地实现与呼叫请求对应的呼叫，且完成了接口完整的业务逻辑，实现多模式多样化的逻辑实现。

本申请实施例提供的一种呼叫线路接入方法，从当前已有呼叫线路中确定通用逻辑，可以包括：

获取使用当前逻辑的呼叫线路的数量，判断使用当前逻辑的呼叫线路的数量是否大于同类型呼叫线路总数量的一半；

若是，则将当前逻辑确定为通用逻辑。

在从当前已有呼叫线路中确定通用逻辑时，对于分解出的当前逻辑，则可以获取使用当前逻辑的呼叫线路的数量，并判断使用当前逻辑的呼叫线路的数量是否大于同类型呼叫线路总数量的一半，其中，这里提及的同类型根据使用当前逻辑的呼叫线路进行确定，若使用当前逻辑的呼叫线路既有硬呼线路又有云呼线路，则此时的同类型即为所有的呼叫线路，若使用当前逻辑的呼叫线路仅有云呼线路，则此时的同类型即为所有的云呼线路，若使用当前逻辑的呼叫线路仅有硬呼线路，则此时的同类型即为所有的硬呼线路。

若使用当前逻辑的呼叫线路的数量未大于同类型呼叫线路总数的一半，则不将该当前逻辑确定为通用逻辑，若使用当前逻辑的呼叫线路的数量大于同类型呼叫线路总数的一半，则将该当前逻辑确定为通用逻辑，即在确定通用逻辑时可以采用过半机制进行确定，以实现代码的简洁性。

具体地，例如有四个硬呼线路，其中对于一块业务处理，三个硬呼线路处理方法完全相同，只有一个硬呼线路处理方式不同，理论上这块业务处理对应的逻辑不应该算通用逻辑，若按独有逻辑处理，将会在四个硬呼线路中都去写这块逻辑，其中三个逻辑完全一样，比较冗余，代码不够简洁，后续若要改动这块逻辑时将需要同时改动三个地方；若将其作为通用逻辑存放到父类(即硬呼抽象类)中，和三个硬呼线路不同的那个硬呼线路需要在其内部重写这块逻辑，其易读性可以稍微偏差。为此，基于代码简洁性和易读性的折中考虑，则可以采用过半机制将上述逻辑确定为硬呼通用逻辑而存放到硬呼抽象类中，处理方式不同的那些呼叫线路重写这块逻辑。

本申请实施例提供的一种呼叫线路接入方法，还可以包括：

当当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半；

若是，则将相同的独有逻辑作为新通用逻辑，在第一触发方子类继承的抽象类中添加新通用逻辑，将第一触发方子类中相同的独有逻辑移除，并在第一受影响方子类中与新通用逻辑相同的独有逻辑上添加废弃注解，且当对第一受影响方子类处理时删除添加有废弃注解的独有逻辑；

其中，第一触发方子类为独有逻辑主动发生变更而得到新通用逻辑的线路子类，第一受影响方子类为逻辑未发生变更且在第一触发方子类中的独有逻辑发生变更时，内部独有逻辑被动变更为新通用逻辑的线路子类。

在本申请中，在构建呼叫逻辑结构的基础上，在确定完通用逻辑和独有逻辑之后且在加入新呼叫线路之后或之前，若当前已有呼叫线路因业务变更而导致原本不相同的独有逻辑进行了统一规划，此时，独有逻辑变为通用逻辑，则需要调整独有逻辑到上层父类抽象类中统一实现，即要根据业务变更进行通用逻辑的上浮，以便于实现呼叫逻辑结构的规范化，并便于后续进行新通用逻辑的复用。其中，需要说明的是，通用逻辑的上浮也需要遵循过半机制，以便于实现代码的简洁性。

具体地，在当前已有呼叫线路中存在线路逻辑发生变更时，则根据变更后的呼叫线路判断是否存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半。其中，这里提及的同类型与上述提及的同类型类似，在此不再赘述。若未大于同类型呼叫线路总数量的一半，则不满足过半机制，此时，不进行逻辑上浮；若大于同类型呼叫线路总数量的一半，则将上述提及的独有逻辑作为新通用逻辑，此时，则在第一触发方子类继承的抽象类中添加新通用逻辑，并为了避免逻辑重复，则将第一触发方子类中上述提及的相同的独有逻辑移除，同时，在第一受影响方子类中与新通用逻辑相同的独有逻辑上添加废弃注解(具体添加@Deprecated)，后续在进行逻辑使用时根据该废弃注解即可获知对应逻辑是废弃掉的逻辑，并当对第一受影响方子类处理(具体可为逻辑修改、测试等)时才删除添加有废弃注解的独有逻辑，这种实现方式不仅可以实现逻辑上浮，而且可以对触发方子类主动进行修改，受影响方惰性修改(即仅在对受影响方处理时才对其内部添加废弃注解的逻辑间修改)，以达到影响可控，不动不测的目的，从而避免对受影响方造成影响。

其中，上述提及的第一触发方子类具体为独有逻辑主动发生变更而使得与其他线路子类的独有逻辑相同，以得到新通用逻辑的线路子类，第一受影响方子类为逻辑未发生变更且在第一触发方子类中的独有逻辑发生变更时，内部独有被动变更为所述新通用逻辑的线路子类。

例如：假设硬呼包括硬呼线路1、硬呼线路2、硬呼线路3、硬呼线路4这四条线路，之前硬呼线路1、硬呼线路2内部有独有逻辑相同，硬呼线路3、硬呼线路4内部独有逻辑与硬呼线路1、硬呼线路2不同，后续因线路逻辑变更而导致硬呼线路3中有独有逻辑与硬呼线路1、硬呼线路2内部相同的独有逻辑相同，此时，该相同的独有逻辑符合过半机制，则需要将其作为通用逻辑而添加到硬呼抽象类中，且硬呼线路3对应的线路子类即为第一触发方子类，硬呼线路1对应的线路子类、硬呼线路2分别对应的线路子类则均为第一受影响方。

本申请实施例提供的一种呼叫线路接入方法，还可以包括：

当当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量；其中，变更逻辑为对未变更通用逻辑进行变更得到的独有逻辑；

若是，则在第二触发方子类中复写未变更通用逻辑，并在第二触发方子类继承的抽象类中的未变更通用逻辑上添加废弃注解，且当对最后一个第二受影响方子类进行处理时，在最后一个第二受影响方子类中复写未变更通用逻辑，并删除抽象类中添加有废弃注解的未变更通用逻辑；

其中，第二触发方子类为主动引起所继承的抽象类中的未变更通用逻辑进行变更的线路子类，第二受影响方子类为逻辑未主动发生变更、与第二触发方子类共同继承抽象类且共用未变更通用逻辑的线路子类。

在本申请中，在构建呼叫逻辑结构的基础上，在确定完通用逻辑和镀有逻辑之后且在加入新呼叫线路之后或之前，若当前已有呼叫线路因业务变更而导致原本共同复用的通用逻辑发生了变更，此时，通用逻辑变为独有逻辑，则需要调整通用逻辑到下层线路子类中实现，即要根据业务变更进行通用逻辑的下推，以便于实现呼叫逻辑结构的规范化，并便于后续进行独有逻辑的专用。其中，需要说明的是，通用逻辑的下推也需要遵循过半机制。

具体地，在当前已有呼叫线路中存在线路逻辑发生变更时，则根据变更后的呼叫线路判断是否存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量，其中，这里提及的变更逻辑即为对未变更通用逻辑进行变更得到的独有逻辑。若未大于，则不符合过半机制，此时，不进行逻辑下推，但需要在第二触发方子类中复写未变更通用逻辑，以便于对复写的未变更通用逻辑进行修改并实现新独有逻辑；若大于，则符合过半机制，此时，则需要进行逻辑下推。需要说明的是，这里提及的变更后的呼叫线路是从第一个发生变更的呼叫线路开始进行计数计算的。

对于下推，具体过程为在第二触发方子类中复写未变更通用逻辑，并在第二触发方子类继承的抽象类中的未变更通用逻辑上添加废弃注解(具体添加@Deprecated)，且当对最后一个第二受影响方子类进行处理时，在最后一个第二受影响方子类中复写未变更通用逻辑，并删除抽象类中添加有废弃注解的未变更通用逻辑，这种实现方式不仅可以实现逻辑下推，而且可以对触发方子类主动进行修改，受影响方惰性修改(即仅在对受影响方处理时才对其内部添加废弃注解的逻辑间修改)，以达到影响可控，不动不测的目的，从而避免对受影响方造成影响。

其中，上述提及的第二触发方子类为主动引起所继承的抽象类(具体指的是后续提到的线路子类继承的抽象类)中的未变更通用逻辑发生变更，以作为其独有逻辑的线路子类，第二受影响方子类为逻辑未主动发生变更、与第二触发方子类共同继承抽象类且共用未变更通用逻辑的线路子类。

例如：假设硬呼包括硬呼线路a、硬呼线路b、硬呼线路c、硬呼线路d、硬呼线路e这五条线路，且这五条线路共用硬呼抽象类中的通用逻辑E，当硬呼线路a发生变更而导致其对应的线路子类需对继承的通用逻辑E进行变更并作为独有逻辑实现时，则硬呼线路a对应的线路子类作为第二触发方子类复写该通用逻辑，但由于1不大于4，不满足使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量，则不进行通用逻辑E的下推；接着，若硬呼线路b发生变更而导致其对应的线路子类需对继承的通用逻辑E进行变更并作为独有逻辑实现时，则硬呼线路b对应的线路子类作为第二触发方子类复写该通用逻辑，但由于2(即变更的总线路子类)不大于3(即此时对应的使用未变更通用逻辑的呼叫线路的数量)，不满足使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量，则不进行通用逻辑E的下推；接着，若硬呼线路c发生变更而导致其对应的线路子类需对继承的通用逻辑E进行变更并作为独有逻辑实现时，则硬呼线路c对应的线路子类作为第二触发方子类复写该通用逻辑，且由于3(即变更的总线路子类)大于2(即此时对应的使用未变更通用逻辑的呼叫线路的数量)，满足使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量，则需要进行通用逻辑E的下推，实际上，此时，仅在通用逻辑E上添加废弃注解，以表明该通用逻辑E不再作为通用逻辑使用，而并不删除抽象类中的通用逻辑E，以免对硬呼线路d和硬呼线路e造成影响，同时，硬呼线路d对应的线路子类和硬呼线路e对应的线路子类均作为第二受影响方子类，当先对硬呼线路d对应的线路子类这一第二受影响方子类进行处理时，仅在该线路子类中复写通用逻辑E，当最后对硬呼线路e对应的线路子类这一第二受影响方子类进行处理时，不仅在该线路子类中复写通用逻辑E，还删除抽象类中添加有废弃注解的未变更通用逻辑E。

本申请实施例还提供了一种呼叫线路接入装置，参见图7，其示出了本申请实施例提供的一种呼叫线路接入装置的结构示意图，可以包括：

确定模块72，用于根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑及通用逻辑所在的目标抽象类；

添加模块73，用于在呼叫逻辑结构中添加继承目标抽象类的新线路子类，在新线路子类中添加新独有逻辑，利用新独有逻辑及通用逻辑实现新呼叫线路的接入；

还可以包括用于建立呼叫逻辑结构的建立模块71，建立模块71可以包括：

建立单元，用于建立呼叫骨架；呼叫骨架可以包括呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的多个云呼线路子类、继承硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中；通用逻辑可以包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，独有逻辑可以包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

本申请实施例提供的一种呼叫线路接入装置，还可以包括：

修改模块，用于当接收到呼叫线路修改请求时，从呼叫逻辑结构中确定与呼叫线路修改请求对应的修改线路子类，从修改线路子类和/或继承的抽象类中调用与呼叫线路修改请求对应的逻辑，并根据呼叫线路修改请求对调用的逻辑进行修改。

本申请实施例提供的一种呼叫线路接入装置，还可以包括：

获取模块，用于在将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中之后，获取与硬呼对应的独有逻辑抽象方法、与云呼对应的独有逻辑抽象方法，并将与硬呼对应的独有逻辑抽象方法存放到硬呼抽象类中，将与云呼对应的独有逻辑抽象方法存放到云呼抽象类中；

组装模块，用于按照模板方法对对应的通用逻辑和对应的独有逻辑抽象方法进行组装，并将组装得到的与云呼对应的通用模板存放到云呼抽象类中，且将组装得到的与硬呼对应的通用模板存放到硬呼抽象类中；

存放模块，用于确定模板抽象方法，将模板抽象方法作为通用模板存放到呼叫抽象类中；

相应地，还可以包括：

调用模块，用于在利用新独有逻辑及通用逻辑实现新呼叫线路的接入之后，当接收到呼叫请求时，确定与呼叫请求对应的目标线路子类及目标通用模板，从目标线路子类中调用与目标通用模板对应的独有逻辑，从目标子线路继承的抽象类中调用与目标通用模板对应的通用逻辑，利用调用的通用逻辑和独有逻辑按照目标通用模板实现与呼叫请求对应的呼叫。

本申请实施例提供的一种呼叫线路接入装置，建立单元可以包括：

判断单元，用于获取使用当前逻辑的呼叫线路的数量，判断使用当前逻辑的呼叫线路的数量是否大于同类型呼叫线路总数量的一半；

确定单元，用于若使用当前逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半，则将当前逻辑确定为通用逻辑。

本申请实施例提供的一种呼叫线路接入装置，还可以包括：

第一判断模块，用于当当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半；

添加模块，用于若存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半，则将相同的独有逻辑作为新通用逻辑，在第一触发方子类继承的抽象类中添加新通用逻辑，将第一触发方子类中相同的独有逻辑移除，并在第一受影响方子类中与新通用逻辑相同的独有逻辑上添加废弃注解，且当对第一受影响方子类处理时删除添加有废弃注解的独有逻辑；

其中，第一触发方子类为独有逻辑主动发生变更而得到新通用逻辑的线路子类，第一受影响方子类为逻辑未发生变更且在第一触发方子类中的独有逻辑发生变更时，内部独有逻辑被动变更为新通用逻辑的线路子类。

本申请实施例提供的一种呼叫线路接入装置，还可以包括：

第二判断模块，用于当当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量；其中，变更逻辑为对未变更通用逻辑进行变更得到的独有逻辑；

复写模块，用于若存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量，则在第二触发方子类中复写未变更通用逻辑，并在第二触发方子类继承的抽象类中的未变更通用逻辑上添加废弃注解，且当对最后一个第二受影响方子类进行处理时，在最后一个第二受影响方子类中复写未变更通用逻辑，并删除抽象类中添加有废弃注解的未变更通用逻辑；

其中，第二触发方子类为主动引起所继承的抽象类中的未变更通用逻辑进行变更的线路子类，第二受影响方子类为逻辑未主动发生变更、与第二触发方子类共同继承抽象类且共用未变更通用逻辑的线路子类。

本申请实施例还提供了一种呼叫线路接入设备，参见图8，其示出了本申请实施例提供的一种呼叫线路接入设备的结构示意图，可以包括：

存储器81，用于存储计算机程序；

处理器82，用于执行存储器81存储的计算机程序时可实现如下步骤：

根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑及通用逻辑所在的目标抽象类；在呼叫逻辑结构中添加继承目标抽象类的新线路子类，在新线路子类中添加新独有逻辑，利用新独有逻辑及通用逻辑实现新呼叫线路的接入；呼叫逻辑结构的建立过程包括：建立呼叫骨架；呼叫骨架包括呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的多个云呼线路子类、继承硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中；通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

本申请实施例还提供了一种可读存储介质，可读存储介质中存储有计算机程序，计算机程序被处理器执行时可实现如下步骤：

根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定新独有逻辑继承的通用逻辑及通用逻辑所在的目标抽象类；在呼叫逻辑结构中添加继承目标抽象类的新线路子类，在新线路子类中添加新独有逻辑，利用新独有逻辑及通用逻辑实现新呼叫线路的接入；呼叫逻辑结构的建立过程包括：建立呼叫骨架；呼叫骨架包括呼叫抽象类、继承呼叫抽象类的云呼抽象类及硬呼抽象类、继承云呼抽象类的多个云呼线路子类、继承硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将通用逻辑存放到对应的抽象类中，将独有逻辑存放到对应的线路子类中；通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

该可读存储介质可以包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

本申请实施例提供的一种呼叫线路接入装置、设备及计算机可读存储介质中相关部分的说明可以参见本申请实施例提供的一种呼叫线路接入方法中对应部分的详细说明，在此不再赘述。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。另外，本申请实施例提供的上述技术方案中与现有技术中对应技术方案实现原理一致的部分并未详细说明，以免过多赘述。

对所公开的实施例的上述说明，使本领域技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种呼叫线路接入方法，其特征在于，包括：

根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定所述新独有逻辑继承的通用逻辑及所述通用逻辑所在的目标抽象类；

在所述呼叫逻辑结构中添加继承所述目标抽象类的新线路子类，在所述新线路子类中添加所述新独有逻辑，利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入；

所述呼叫逻辑结构的建立过程包括：

建立呼叫骨架；所述呼叫骨架包括呼叫抽象类、继承所述呼叫抽象类的云呼抽象类及硬呼抽象类、继承所述云呼抽象类的多个云呼线路子类、继承所述硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中；所述通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，所述独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

2.根据权利要求1所述的呼叫线路接入方法，其特征在于，还包括：

当接收到呼叫线路修改请求时，从所述呼叫逻辑结构中确定与所述呼叫线路修改请求对应的修改线路子类，从所述修改线路子类和/或继承的抽象类中调用与所述呼叫线路修改请求对应的逻辑，并根据所述呼叫线路修改请求对调用的逻辑进行修改。

3.根据权利要求1所述的呼叫线路接入方法，其特征在于，在将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中之后，还包括：

获取与硬呼对应的独有逻辑抽象方法、与云呼对应的独有逻辑抽象方法，并将所述与硬呼对应的独有逻辑抽象方法存放到所述硬呼抽象类中，将所述与云呼对应的独有逻辑抽象方法存放到所述云呼抽象类中；

按照模板方法对对应的通用逻辑和对应的独有逻辑抽象方法进行组装，并将组装得到的与云呼对应的通用模板存放到所述云呼抽象类中，且将组装得到的与硬呼对应的通用模板存放到所述硬呼抽象类中；

确定模板抽象方法，将所述模板抽象方法作为通用模板存放到所述呼叫抽象类中；

相应地，在利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入之后，还包括：

当接收到呼叫请求时，确定与所述呼叫请求对应的目标线路子类及目标通用模板，从所述目标线路子类中调用与所述目标通用模板对应的独有逻辑，从所述目标子线路继承的抽象类中调用与所述目标通用模板对应的通用逻辑，利用调用的通用逻辑和独有逻辑按照所述目标通用模板实现与所述呼叫请求对应的呼叫。

4.根据权利要求1至3任一项所述的呼叫线路接入方法，其特征在于，从当前已有呼叫线路中确定通用逻辑，包括：

获取使用当前逻辑的呼叫线路的数量，判断使用所述当前逻辑的呼叫线路的数量是否大于同类型呼叫线路总数量的一半；

若是，则将所述当前逻辑确定为通用逻辑。

5.根据权利要求4所述的呼叫线路接入方法，其特征在于，还包括：

当所述当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用相同独有逻辑的呼叫线路的数量大于同类型呼叫线路总数量的一半；

若是，则将相同的独有逻辑作为新通用逻辑，在第一触发方子类继承的抽象类中添加所述新通用逻辑，将所述第一触发方子类中所述相同的独有逻辑移除，并在第一受影响方子类中与所述新通用逻辑相同的独有逻辑上添加废弃注解，且当对所述第一受影响方子类处理时删除添加有所述废弃注解的独有逻辑；

其中，所述第一触发方子类为独有逻辑主动发生变更而得到所述新通用逻辑的线路子类，所述第一受影响方子类为逻辑未发生变更且在所述第一触发方子类中的独有逻辑发生变更时，内部独有逻辑被动变更为所述新通用逻辑的线路子类。

6.根据权利要求4所述的呼叫线路接入方法，其特征在于，还包括：

当所述当前已有呼叫线路中存在线路逻辑发生变更时，根据变更后的呼叫线路判断是否存在使用变更逻辑的呼叫线路的数量大于使用未变更通用逻辑的呼叫线路的数量；其中，所述变更逻辑为对所述未变更通用逻辑进行变更得到的独有逻辑；

若是，则在第二触发方子类中复写所述未变更通用逻辑，并在所述第二触发方子类继承的抽象类中的所述未变更通用逻辑上添加废弃注解，且当对最后一个第二受影响方子类进行处理时，在最后一个所述第二受影响方子类中复写所述未变更通用逻辑，并删除所述抽象类中添加有所述废弃注解的所述未变更通用逻辑；

其中，所述第二触发方子类为主动引起所继承的所述抽象类中的所述未变更通用逻辑进行变更的线路子类，所述第二受影响方子类为逻辑未主动发生变更、与所述第二触发方子类共同继承所述抽象类且共用所述未变更通用逻辑的线路子类。

7.一种呼叫线路接入装置，其特征在于，包括：

确定模块，用于根据接收到的新呼叫线路接入请求确定新呼叫线路对应的新独有逻辑，从预先建立的呼叫逻辑结构中确定所述新独有逻辑继承的通用逻辑及所述通用逻辑所在的目标抽象类；

添加模块，用于在所述呼叫逻辑结构中添加继承所述目标抽象类的新线路子类，在所述新线路子类中添加所述新独有逻辑，利用所述新独有逻辑及所述通用逻辑实现所述新呼叫线路的接入；

还包括用于建立所述呼叫逻辑结构的建立模块，所述建立模块包括：

建立单元，用于建立呼叫骨架；所述呼叫骨架包括呼叫抽象类、继承所述呼叫抽象类的云呼抽象类及硬呼抽象类、继承所述云呼抽象类的多个云呼线路子类、继承所述硬呼抽象类的多个硬呼线路子类；从当前已有呼叫线路中确定通用逻辑和独有逻辑，将所述通用逻辑存放到对应的抽象类中，将所述独有逻辑存放到对应的线路子类中；所述通用逻辑包括呼叫通用逻辑、云呼通用逻辑、硬呼通用逻辑，所述独有逻辑包括各云呼线路独有逻辑、各硬呼线路独有逻辑。

8.根据权利要求7所述的呼叫线路接入装置，其特征在于，还包括：

修改模块，用于当接收到呼叫线路修改请求时，从所述呼叫逻辑结构中确定与所述呼叫线路修改请求对应的修改线路子类，从所述修改线路子类和/或继承的抽象类中调用与所述呼叫线路修改请求对应的逻辑，并根据所述呼叫线路修改请求对调用的逻辑进行修改。

9.一种呼叫线路接入设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至6任一项所述的呼叫线路接入方法的步骤。

10.一种可读存储介质，其特征在于，所述可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至6任一项所述的呼叫线路接入方法的步骤。

Images