评价规则的实现与用户数据的评价方法、装置及电子设备

摘要

本申请实施例提供了一种评价规则的实现与用户数据的评价方法、装置及电子设备。评价规则的实现方法包括：创建骨架实现类，骨架实现类中定义了第一共有属性以及第一共有方法；通过骨架实现类实现与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；基于骨架实现类创建规则子类，规则子类用于实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

说明书

技术领域

本申请涉及计算机技术领域，具体而言，本申请涉及一种评价规则的实现与用户数据的评价方法、装置及电子设备。

背景技术

在对用户数据进行评价时，一般需要基于一套行之有效的复杂规则，通常是包括一个或者多个规则组。规则组中的评价规则可能属于不同的类型，但是其具有相同的属性。

在系统开发时，每个评价规则一般会被定义为一个规则子类，并且需要定义一个父类，父类中定义了系统中所需的一些共有属性以及共有方法。

大部分规则子类都需要继承这个父类，以使得规则子类具有这些共有属性以及共有方法。但是，规则子类还需要具有规则组的共有属性以及共有方法，而规则子类需要满足只能继承自一个父类的原则。为了解决该问题，现有技术中一般通过如下两种方式：

第一种是将规则组所需具有的共有属性以及共有方法定义在父类中，规则子类继承自父类，从而具有这些共有属性以及共有方法。

第二种是在子类中直接定义规则组所需具有的共有属性以及共有方法。

上述的第一种方式中，由于在父类中定义了规则组所需的共有属性以及共有方法，会使得所有继承自父类的规则子类均具有这些共有属性以及共有方法，但是大多数的规则子类并不会调用这些共有属性以及共有方法，因此这种方式提高了规则子类之间的耦合度。

上述的第二种方式中不便于后续功能扩展和代码维护，并且造成大幅度增加重复代码，使得系统的实现类无结构层次。

综上，现有方式中均存在一定的缺陷。

发明内容

本申请的目的旨在至少能解决上述的技术缺陷之一。本申请所采用的技术方案如下：

第一方面，本申请实施例提供了一种评价规则的实现方法，该方法包括：

创建骨架实现类，骨架实现类中定义了第一共有属性以及第一共有方法；

通过骨架实现类实现与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

基于骨架实现类创建规则子类，规则子类用于实现评价规则。

可选地，上述方法还包括：

基于至少两个评价规则确定规则组，至少两个评价规则实现了与规则组对应的接口中定义的第二共有属性以及第二共有方法。

可选地，基于至少两个评价规则确定规则组，包括：

将至少两个评价规则对应的规则子类组合成聚合类；

基于聚合类实现规则组。

可选地，基于骨架实现类创建规则子类，包括：

创建继承自骨架实现类的规则子类。

可选地，基于骨架实现类创建规则子类，包括：

创建继承自骨架实现类的内部类；

创建继承自内部类的规则子类。

可选地，上述方法还包括：

对规则子类所继承的骨架实现类进行校验。

可选地，对规则子类所继承的骨架实现类进行校验，包括：

创建外部实现类，规则子类继承自外部实现类；

通过外部实现类对规则子类所继承的骨架实现类进行校验。

可选地，第一共有属性包括以下至少一项：

最后维护日期；

最后维护渠道；

第一共有方法包括以下至少一项：

获取最后维护日期的方法；

设置最后维护日期的方法；

获取最后维护渠道类别的方法；

设置最后维护渠道类别的方法；

获取最后维护员工编号的方法；

设置最后维护员工编号的方法。

可选地，第二共有属性包括以下至少一项：

规则失效日期；

规则生效日期；

第二共有方法包括以下至少一项：

规则失效日期的维护方法；

规则生效日期的维护方法；

查询规则详情的方法；

查询规则列表的方法。

第二方面，本申请实施例提供了一种用户数据的评价方法，该方法包括：

获取待评价用户数据对应的评价规则，用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

基于评价规则对待评价用户数据进行评价。

可选地，规则子类基于骨架实现类创建，是通过以下方式：

创建继承自骨架实现类的规则子类；或者，

创建继承自骨架实现类的内部类，并创建继承自内部类的规则子类。

可选地，获取待评价用户数据对应的评价规则，包括：

从预配置的规则组中获取待评价用户数据对应的评价规则，规则组包括至少两个评价规则。

第三方面，本申请实施例提供了一种评价规则的实现装置，该装置包括：

骨架实现类创建模块，用于创建骨架实现类，骨架实现类中定义了第一共有属性以及第一共有方法；

接口实现模块，用于通过骨架实现类实现与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

规则子类创建模块，用于基于骨架实现类创建规则子类，规则子类用于实现评价规则。

可选地，上述装置还包括：

规则组确定模块，用于基于至少两个评价规则确定规则组，至少两个评价规则实现了与规则组对应的接口中定义的第二共有属性以及第二共有方法。

可选地，规则组确定模块在基于至少两个评价规则确定规则组时，具体用于：

将至少两个评价规则对应的规则子类组合成聚合类；

基于聚合类实现规则组。

可选地，规则子类创建模块在基于骨架实现类创建规则子类时，具体用于：

创建继承自骨架实现类的规则子类。

可选地，规则子类创建模块在基于骨架实现类创建规则子类时，具体用于：

创建继承自骨架实现类的内部类；

创建继承自内部类的规则子类。

可选地，上述装置还包括：

校验模块，用于对规则子类所继承的骨架实现类进行校验。

可选地，校验模块具体用于：

创建外部实现类，规则子类继承自外部实现类；

通过外部实现类对规则子类所继承的骨架实现类进行校验。

可选地，第一共有属性包括以下至少一项：

最后维护日期；

最后维护渠道；

第一共有方法包括以下至少一项：

获取最后维护日期的方法；

设置最后维护日期的方法；

获取最后维护渠道类别的方法；

设置最后维护渠道类别的方法；

获取最后维护员工编号的方法；

设置最后维护员工编号的方法。

第二共有属性包括以下至少一项：

规则失效日期；

规则生效日期；

第二共有方法包括以下至少一项：

规则失效日期的维护方法；

规则生效日期的维护方法；

查询规则详情的方法；

查询规则列表的方法。

第四方面，本申请实施例提供了一种用户数据的评价装置，该装置包括：

评价规则模块，用于获取待评价用户数据对应的评价规则，用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

评价模块，用于基于评价规则对待评价用户数据进行评价。

可选地，规则子类基于骨架实现类创建，是通过以下方式：

创建继承自骨架实现类的规则子类；或者，

创建继承自骨架实现类的内部类，并创建继承自内部类的规则子类。

可选地，评价规则模块在获取待评价用户数据对应的评价规则时，具体用于：

从预配置的规则组中获取待评价用户数据对应的评价规则，规则组包括至少两个评价规则。

第五方面，本申请实施例提供了一种电子设备，该电子设备包括：处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，执行如本申请的第一方面的任一实施方式或者第二方面的任一实施方式所示的方法。

第六方面，本申请实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现本申请的第一方面的任一实施方式或者第二方面的任一实施方式所示的方法。

本申请实施例提供的技术方案带来的有益效果是：

本申请实施例提供的方案，通过创建骨架实现类，在骨架实现类中定义第一共有属性以及第一共有方法，通过骨架实现类实现与规则组对应的接口，在接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，从而基于骨架实现类创建规则子类，并通过规则子类实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的一种评价规则的实现方法的流程示意图；

图2为本申请实施例提供的一种骨架实现框架图；

图3为本申请实施例提供一个示例中类继承关系示意图；

图4为本申请实施例提供的一种用户数据的评价方法的流程示意图；

图5为本申请实施例提供的一种评价规则的实现装置的结构示意图；

图6为本申请实施例提供的一种用户数据的评价装置的结构示意图；

图7为本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本发明的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

首先对本申请涉及的几个名词进行介绍和解释：

骨架实现类(skeletal implementation)：指结合了接口与抽象类的优点的一种抽象类型定义类。

用户评价系统：通过多种基础规则的组合配置，对用户的各种行为流水进行分析，并产生评价结果，给予同其用户评级相匹配的用户贡献值的系统；

评价规则：指对用户行为流水等用户数据进行评价分析的统一的基础定义，是最基础的一类规则；

规则组：包含了多种类型的评价规则的集合。

用户评价信息系统需要基于一套行之有效的复杂规则，通常是一个或者多个规则组，对用户数据(如行为流水、轨迹进行归类等)进行匹配和分析，从而对某一类用户评定级别或者给予用户贡献值。

规则组包含了若干不同类型的评价规则，例如用户的基础贡献值规则，贡献值系数规则，不计贡献值规则，上下线规则等。这些若干类型的规则，可以由一条或者多条构成一个类别的规则集合，再共同组合成一个规则组，通过规则组作用于用户数据。虽然这些评价规则属于不同类型的规则，大部分属性值不同，但是他们共同隶属于一个规则组，对于规则组而言，具有一些共有属性以及共有方法。规则组所需的共有属性如生效日期和失效日期及规则组编号等。

在系统开发时，为了系统的类与类之间的隔离，同时符合“单一职责”的设计思想，每一种类型的评价规则被定义为一个最小的规则子类，相似类型的规则子类可以继承一个同样的父类，在父类中定义了本系类型规则所需的一些共有方法以及共有属性，如最后修改操作员工标号，最后修改时间等属性以及获取最后修改操作员工标号、最后修改时间的方法。系统中的大部分规则子类都需要继承这个父类，但是这些规则子类也必须能够具有规则组所需的共有方法以及共有属性，例如：规则组编号，规则序号等属性以及生成这些编号的方法。同时，规则子类需要满足只能继承一个父类的规则。

现有技术中，在涉及到规则组所需要一些共有属性以及共有方法时，一种处理方式为规则子类所继承的父类中定义规则组所需要一些共有属性以及共有方法，例如让多个业务类共同继承一个具有审计字段的抽象父类。这样会使得所有的规则子类都会具有这些共有属性以及共有方法，而大多数规则子类在实际使用中并不会调用这些共有属性以及共有方法。因此，这种方式提高了规则子类之间的耦合度。另外这种方式也会使这些子类无法再继承其他实现类，从而极大的限制了类的功能扩展。

现有技术中的另一种处理方式是在规则子类中直接定义规则组的共有属性和共有方法。这种方式存在不便于后续功能扩展和代码维护的缺点，并且大幅度增加重复代码可能会导致系统的实现类无结构层次。

目前，在用户评价系统中，涉及到的评价规则种类多，规则之间的关联关系复杂，随着业务的发展，用户评价的各种规则被期待有较大的灵活性，能够快速拆分和组合，能够易于维护，能够被灵活广泛的应用到各种业务环境，因此需要一种能够具有松散耦合结构的评价规则的类层次结构来适应灵活开发。本申请针对目前用户评价的复杂规则配置，提供了一种兼具松散耦合与灵活组合的类层次结构的方法，在开发中，能够提高规则子类的复用率，而不必重写规则子类，易于对多种规则进行灵活组合，适用于用户评价的多个业务场景。

本申请实施例提供的评价规则的实现与用户数据的评价方法、装置及电子设备，旨在解决现有技术的如上技术问题中的至少一个。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图1示出了本申请实施例提供的一种评价规则的实现方法的流程示意图，如图1所示，该方法主要可以包括：

步骤S110：创建骨架实现类，骨架实现类中定义了第一共有属性以及第一共有方法；

步骤S120：通过骨架实现类实现与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

步骤S130：基于骨架实现类创建规则子类，规则子类用于实现评价规则。

本申请实施例中，第一共有属性以及第一共有方法为用户评价系统中所需的属性及方法，通过骨架实现类对第一共有属性以及第一共有方法进行定义，使得基于骨架实现类创建的规则子类能够具有第一共有属性以及第一共有方法。

本申请实施例中，第二共有属性以及第二共有方法为规则组中所需的属性及方法，骨架实现类可以针对于各规则组分别实现对应的接口，即将各规则组所需的属性以及方法在对应的接口中定义。

本申请实施例中，评价规则可以通过规则子类定义，规则组中可以包括多个评价规则。

由于通过骨架实现类实现的接口中定义了第二共有属性以及第二共有方法，使得基于骨架实现类创建的规则子类能够具有第二共有属性以及第二共有方法。

通过将不同规则组所需的属性及方法定义在对应的接口中，避免直接在父类中定义所有的规则组所需属性及方法，避免导致规则子类之间耦合度身高。另外由于可以通过定义接口的方式来新增规则组，便于后续功能的拓展，避免直接在规则子类中定义规则组所需的属性及方法造成的重复代码答复增加，并且保证代码的结构层次。

本申请实施例提供的方法，通过创建骨架实现类，在骨架实现类中定义第一共有属性以及第一共有方法，通过骨架实现类实现与规则组对应的接口，在接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，从而基于骨架实现类创建规则子类，并通过规则子类实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

本申请实施例的一种可选方式中，上述方法还包括：

基于至少两个评价规则确定规则组，至少两个评价规则实现了与规则组对应的接口中定义的第二共有属性以及第二共有方法。

本申请实施例中，由于接口中定义了第二共有属性以及第二共有方法，规则子类可以实现第二共有属性以及第二共有方法，以使得规则子类能够具有所属规则组所需属性以及方法。

本申请实施例中，规则组中可以包括多个不同类型的评价规则，用于实现规则组中评价规则的规则子类需要具有规则组所需属性以及方法。属于同一个规则组内的规则子类需要实现与规则组所对应的接口中定义的第二共有属性以及第二共有方法。

通过将多个规则子类可以组合成一个或多个规则组，从而可以根据业务场景的不同，创建不同的规则组。

本申请实施例中，基于至少两个评价规则确定规则组，包括：

将至少两个评价规则对应的规则子类组合成聚合类；

基于聚合类实现规则组。

本申请实施例中，可以将属于同一个规则组的评价规则所对应的规则子类组合为聚合类，从而基于聚合类实现规则组。

本申请实施例的一种可选方式中，基于骨架实现类创建规则子类，包括：

创建继承自骨架实现类的规则子类。

本申请实施例的一种可选方式中，基于骨架实现类创建规则子类，包括：

创建继承自骨架实现类的内部类；

创建继承自内部类的规则子类。

本申请实施例中，规则子类可以直接继承自骨架实现类。

由于规则子类需要满足不能继承一个以上的父类的规定，因此如果规则子类直接继承自父类或者骨架实现类，则无法再继承其他实现类，极大的限制了类的功能扩展。

本申请实施例中，可以定义继承自骨架实现类的内部类，并使规则子类继承自内部类，这时规则子类可以同时继承其他外部实现类，从而实现了对类功能的拓展。

本申请实施例的一种可选方式中，还包括：

对规则子类所继承的骨架实现类进行校验。

本申请实施例的一种可选方式中，述对规则子类所继承的骨架实现类进行校验，包括：

创建外部实现类，规则子类继承自外部实现类；

通过外部实现类对规则子类所继承的骨架实现类进行校验。

本申请实施例中，能会需要对规则子类所继承的骨架实现类进行校验，作为一个示例，可以创建外部实现类，并使规则子类继承自外部实现类，从而能够调用外部实现类完成对骨架实现类的校验。

本申请实施例的一种可选方式中，第一共有属性包括以下至少一项：

最后维护日期；

最后维护渠道；

第一共有方法包括以下至少一项：

获取最后维护日期的方法；

设置最后维护日期的方法；

获取最后维护渠道类别的方法；

设置最后维护渠道类别的方法；

获取最后维护员工编号的方法；

设置最后维护员工编号的方法。

本申请实施例的一种可选方式中，第二共有属性包括以下至少一项：

规则失效日期；

规则生效日期；

第二共有方法包括以下至少一项：

规则失效日期的维护方法；

规则生效日期的维护方法；

查询规则详情的方法；

查询规则列表的方法。

作为一个示例，图2中示出了本申请实施例提供的一种骨架实现框架图。

如图2中所示，IuniAttributeService接口(即接口)：其中定义了第二共有属性以及第二公有方法。

AbstractSkeletonObject类：该类是实现了接口的抽象类，即骨架实现类，在该类中除了定义了第一共有属性以及第一公有方法，还实现了接口中定义的第二共有属性以及第二公有方法。

子类，即规则子类，本例中以基础贡献值规则、贡献值系数规则、不计算贡献值规则以及特殊贡献值计算规则为例。在实际上使用中，可以根据需要定义多个规则子类。本例中基础贡献值规则子类与贡献值系数规则子类具有同样的方法与属性，即需要定义生效时间和失效时间，因此这里让他们继承了骨架实现类；

规则组：本例中的规则组作为聚合类出现，它由一个或者多个规则子类构成；

ValidateObject类，即外部实现类，可以定义部分子类继承的效验父类。

作为一个示例，图3中示出了本申请实施例提供一个示例中类继承关系示意图。其中，规则子类1、规则子类2、规则子类3、规则子类4、规则子类5……为规则组中的规则子类，其中规则子类1与规则子类2继承自骨架实现类。规则子类3继承自外部实现类1，规则子类4继承自外部实现类2。

本申请实施例提供的方法，通过提供一种骨架实现类，整合从属于不同类的多个共同属性和共同方法。可以较为方便的整合系统中的若干个类，简化代码逻辑结构和代码量，拓展子类的功能。特别是在用户评价类系统中，涉及到的子类较多，相互关系复杂，采用这种方式，可以极大的提高编码效率，增加代码可读性，并能灵活的把定义好的规则子类通过骨架实现类的方式应用于不同的开发场景。

图4示出了本申请实施例提供的一种用户数据的评价方法的流程示意图，如图4所示，该方法主要可以包括：

步骤S210：获取待评价用户数据对应的评价规则，用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

步骤S220：基于评价规则对待评价用户数据进行评价。

本申请实施例中，评价规则可以通过规则子类实现。

规则子类可以基于骨架实现类创建，可以通过骨架实现类对第一共有属性以及第一共有方法进行定义，同时通过骨架实现类实现接口，并在接口中定义第二共有属性以及第二共有方法，从而使得基于骨架实现类创建的规则子类能够具有第一共有属性以及第一共有方法，并且具有规则组中所需的第二共有属性以及第二共有方法。

本申请实施例中，用户数据可以包括用户在业务流程中所产生的数据，如行为流水等。

本申请实施例中提供的方法，通过获取待评价用户数据对应的评价规则，基于评价规则对待评价用户数据进行评价。由于用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，因此，本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

本申请实施例的一种可选方式中，规则子类基于骨架实现类创建，是通过以下方式：

创建继承自骨架实现类的规则子类；或者，

创建继承自骨架实现类的内部类，并创建继承自内部类的规则子类。

本申请实施例中，规则子类可以直接继承自骨架实现类，也可以定义继承自骨架实现类的内部类，并使规则子类继承自内部类，这时规则子类可以同时继承其他外部实现类，从而实现了对类功能的拓展。

本申请实施例的一种可选方式中，获取待评价用户数据对应的评价规则，包括：

从预配置的规则组中获取待评价用户数据对应的评价规则，规则组包括至少两个评价规则。

本申请实施例中，由于可以针对不同的应用场景配置一种或者多种评价规则作为规则组，因此，在对待评价用户数据进行处理时，可以从规则组中获取对应的评价规则，并通过评价规则实现对用户数据的评价。

基于与图1中所示的方法相同的原理，图5示出了本申请实施例提供的一种评价规则的实现装置的结构示意图，如图5所示，该评价规则的实现装置30可以包括：

骨架实现类创建模块310，用于创建骨架实现类，骨架实现类中定义了第一共有属性以及第一共有方法；

接口实现模块320，用于通过骨架实现类实现与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

规则子类创建模块330，用于基于骨架实现类创建规则子类，规则子类用于实现评价规则。

本申请实施例提供的装置，通过创建骨架实现类，在骨架实现类中定义第一共有属性以及第一共有方法，通过骨架实现类实现与规则组对应的接口，在接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，从而基于骨架实现类创建规则子类，并通过规则子类实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

可选地，上述装置还包括：

规则组确定模块，用于基于至少两个评价规则确定规则组，至少两个评价规则实现了与规则组对应的接口中定义的第二共有属性以及第二共有方法。

可选地，规则组确定模块在基于至少两个评价规则确定规则组时，具体用于：

将至少两个评价规则对应的规则子类组合成聚合类；

基于聚合类实现规则组。

可选地，规则子类创建模块在基于骨架实现类创建规则子类时，具体用于：

创建继承自骨架实现类的规则子类。

可选地，规则子类创建模块在基于骨架实现类创建规则子类时，具体用于：

创建继承自骨架实现类的内部类；

创建继承自内部类的规则子类。

可选地，上述装置还包括：

校验模块，用于对规则子类所继承的骨架实现类进行校验。

可选地，校验模块具体用于：

创建外部实现类，规则子类继承自外部实现类；

通过外部实现类对规则子类所继承的骨架实现类进行校验。

可选地，第一共有属性包括以下至少一项：

最后维护日期；

最后维护渠道；

第一共有方法包括以下至少一项：

获取最后维护日期的方法；

设置最后维护日期的方法；

获取最后维护渠道类别的方法；

设置最后维护渠道类别的方法；

获取最后维护员工编号的方法；

设置最后维护员工编号的方法。

第二共有属性包括以下至少一项：

规则失效日期；

规则生效日期；

第二共有方法包括以下至少一项：

规则失效日期的维护方法；

规则生效日期的维护方法；

查询规则详情的方法；

查询规则列表的方法。

可以理解的是，本实施例中的评价规则的实现装置的上述各模块具有实现图1中所示的实施例中的评价规则的实现方法相应步骤的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。上述模块可以是软件和/或硬件，上述各模块可以单独实现，也可以多个模块集成实现。对于上述评价规则的实现装置的各模块的功能描述具体可以参见图1中所示实施例中的评价规则的实现方法的对应描述，在此不再赘述。

基于与图4中所示的方法相同的原理，图6示出了本申请实施例提供的一种用户数据的评价装置的结构示意图，如图6所示，该用户数据的评价装置40可以包括：

评价规则模块410，用于获取待评价用户数据对应的评价规则，用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法；

评价模块420，用于基于评价规则对待评价用户数据进行评价。

本申请实施例中提供的装置，通过获取待评价用户数据对应的评价规则，基于评价规则对待评价用户数据进行评价。由于用于实现评价规则的规则子类是基于骨架实现类创建的，骨架实现类中定义了第一共有属性以及第一共有方法，骨架实现类中实现了与规则组对应的接口，接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，因此，本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

可选地，规则子类基于骨架实现类创建，是通过以下方式：

创建继承自骨架实现类的规则子类；或者，

创建继承自骨架实现类的内部类，并创建继承自内部类的规则子类。

可选地，评价规则模块在获取待评价用户数据对应的评价规则时，具体用于：

从预配置的规则组中获取待评价用户数据对应的评价规则，规则组包括至少两个评价规则。

可以理解的是，本实施例中的用户数据的评价装置的上述各模块具有实现图4中所示的实施例中的用户数据的评价方法相应步骤的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。上述模块可以是软件和/或硬件，上述各模块可以单独实现，也可以多个模块集成实现。对于上述用户数据的评价装置的各模块的功能描述具体可以参见图4中所示实施例中的用户数据的评价方法的对应描述，在此不再赘述。

本申请实施例提供了一种电子设备，包括处理器和存储器；

存储器，用于存储操作指令；

处理器，用于通过调用操作指令，执行本申请任一实施方式中所提供的方法。

作为一个示例，图7示出了本申请实施例所适用的一种电子设备的结构示意图，如图7所示，该电子设备2000包括：处理器2001和存储器2003。其中，处理器2001和存储器2003相连，如通过总线2002相连。可选的，电子设备2000还可以包括收发器2004。需要说明的是，实际应用中收发器2004不限于一个，该电子设备2000的结构并不构成对本申请实施例的限定。

其中，处理器2001应用于本申请实施例中，用于实现上述方法实施例所示的方法。收发器2004可以包括接收机和发射机，收发器2004应用于本申请实施例中，用于执行时实现本申请实施例的电子设备与其他设备通信的功能。

处理器2001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器2001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线2002可包括一通路，在上述组件之间传送信息。总线2002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线2002可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器2003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

可选的，存储器2003用于存储执行本申请方案的应用程序代码，并由处理器2001来控制执行。处理器2001用于执行存储器2003中存储的应用程序代码，以实现本申请任一实施方式中所提供的方法。

本申请实施例提供的电子设备，适用于上述方法任一实施例，在此不再赘述。

本申请实施例提供了一种电子设备，与现有技术相比，通过创建骨架实现类，在骨架实现类中定义第一共有属性以及第一共有方法，通过骨架实现类实现与规则组对应的接口，在接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，从而基于骨架实现类创建规则子类，并通过规则子类实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述方法实施例所示的方法。

本申请实施例提供的计算机可读存储介质，适用于上述方法任一实施例，在此不再赘述。

本申请实施例提供了一种计算机可读存储介质，与现有技术相比，通过创建骨架实现类，在骨架实现类中定义第一共有属性以及第一共有方法，通过骨架实现类实现与规则组对应的接口，在接口中定义了对应的规则组所需的第二共有属性以及规则组所需的第二共有方法，从而基于骨架实现类创建规则子类，并通过规则子类实现评价规则。本方案中，通过骨架实现类实现接口的方式，使得规则子类能够具有用户评价系统中所需的属性及方法，并且具有的规则组所需属性及方法，能够避免现有方式可能导致的代码耦合度增加、代码重复量大等缺陷，提升了编码效率，保证系统代码的结构层次，并且保证代码的扩展性。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。