基于面向切面编程的类实现方法、装置、设备及介质与流程

1.本发明涉及spring框架技术领域，特别涉及一种基于面向切面编程的类实现方法、装置、设备及介质。


背景技术：

2.在实际的项目开发过程中存在不同的业务场景。以下发通知的业务场景为例，如果用户a提交了工单，需要通知到用户b，通知方式有多种：短信、钉钉、邮箱等。根据需求可以自定义选择不同的通知方式，可能是用一种方式进行通知，也可能是两种方式，甚至是所有的通知方式。与上述场景类似的还有一些导出业务功能，例如有些导出功能需要支持导出word、excel、pdf、html中的几种。
3.把下发通知的业务场景作为例子进行处理，如图1所示，前提条件为定义一个下发通知的接口(noticeservice)，所有的通知方式都实现了这个接口。进一步的，现有技术的处理方式中，为了可以根据需求选择通知方式，需要定义实现类的别名，进而可以由已知的自定义配置得出对应的通知方式，再依次调用不同通知实现类的方法去下发通知，如图2所示。虽然现有技术中通过多次注入接口的多个实现类，再分别依次调用实现类的下发通知方法固然可以完成需求，但是这种方式有以下几个缺陷：首先，要保证可以同时注入一个接口的多个实现类的前提是为不同的实现类定义各自的别名，否则项目启动会提示编译异常；其次，为不同实现类定义别名后再引入多个实现类，最后调用不同实现类的下发通知方法，造成代码编写比较繁琐。另外，程序执行时，按照顺序依次下发通知，如果前面的下发通知方法报错，后面的方法就无法执行，代码耦合度比较高。
4.综上，如何在实现类的过程中简单编写业务代码，降低代码及业务的耦合是目前有待解决的问题。


技术实现要素：

5.有鉴于此，本发明的目的在于提供一种基于面向切面编程的类实现方法、装置、设备及介质，能够在实现类的过程中简单编写业务代码，降低代码及业务的耦合。其具体方案如下：
6.第一方面，本技术公开了一种基于面向切面编程的类实现方法，包括：
7.接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；
8.基于所述目标接口收集预先构建的用于确定所述类的自定义注解，并对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；
9.当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
10.可选的，所述基于所述目标接口收集预先构建的用于确定所述类的自定义注解之前，还包括：
11.定义自定义注解类，并基于所述自定义注解类实现mergedbeandefinitionpostprocessor接口；
12.基于所述mergedbeandefinitionpostprocessor接口，对postprocessmergedbeandefinition方法进行重写，以得到所述自定义注解。
13.可选的，所述对所述代理对象进行依赖注入以得到所述自定义注解的配置信息，包括：
14.基于所述自定义注解类继承instantiationawarebeanpostprocessoradapter类，并根据继承后的自定义注解类对postprocessproperties方法进行重写，以实现对所述代理对象的依赖注入。
15.可选的，所述当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类，包括：
16.当调用所述代理对象时，对所述配置信息进行解析并获取解析后的配置信息中用于确定所述类的选择方式的value值和解析后的配置信息中用于通过数组指定所述类的serviceids值；
17.根据所述value值和所述serviceids值进行反射调用，以确定出需要调用的目标类。
18.可选的，所述根据所述属性类型的值进行反射调用，以确定出需要调用的目标类，包括：
19.如果所述value值为all，则直接将所述自定义注解中的所有类确定为所述目标类；
20.如果所述value值为assign，则根据所述serviceids中数组的值确定出需要调用的所述目标类。
21.可选的，所述的基于面向切面编程的类实现方法，还包括：
22.当所述类中存在新增类时，更新所述自定义注解并对所述代理对象进行依赖注入以得到更新后自定义注解的更新配置信息；
23.相应的，所述当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类，包括：
24.当调用所述代理对象时，对所述更新配置信息进行解析并根据解析后的更新配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
25.可选的，所述当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类之后，包括：
26.当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值利用handler处理器进行反射调用，以确定出需要调用的目标类。
27.第二方面，本技术公开了一种基于面向切面编程的类实现装置，包括：
28.目标接口确定模块，用于接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；
29.注解收集模块，用于基于所述目标接口收集预先构建的用于确定所述类的自定义注解；
30.依赖注入模块，用于对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；
31.目标类确定模块，用于当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
32.第三方面，本技术公开了一种电子设备，所述电子设备包括处理器和存储器；其中，所述存储器用于存储计算机程序，所述计算机程序由所述处理器加载并执行以实现如前所述的基于面向切面编程的类实现方法。
33.第四方面，本技术公开了一种计算机可读存储介质，用于存储计算机程序；其中所述计算机程序被处理器执行时实现如前所述的基于面向切面编程的类实现方法。
34.本技术中，接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；基于所述目标接口收集预先构建的用于确定所述类的自定义注解，并对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。可见，在业务场景中确定了需要调用的目标接口后，为了增强接口的注入，自定义一个注解，把多个实现类注入进去。在执行代码时收集自定义注解，收集注解完成之后，需要根据收集的注解完成依赖注入，因为可能有多个实现类，只能使用代理对象进行依赖注入。如此一来，当调用代理对象时，根据依赖注入得到的自定义注解的配置信息进行反射调用，实现一次性注入同一接口的多个实现类，编写业务代码非常简单、清晰。如此就可以把原本复杂冗余的代码替换掉，而且不用担心多个业务之间一个业务失败其他业务无法正常执行的情况，降低了代码及业务的耦合。
附图说明
35.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
36.图1为本技术公开的一种接口及实现类架构图；
37.图2为本技术公开的一种现有技术处理方式流程图；
38.图3为本技术公开的一种基于面向切面编程的类实现方法流程图；
39.图4为本技术公开的一种理想的操作流程图；
40.图5为本技术公开的一种具体的基于面向切面编程的类实现方法流程图；
41.图6为本技术公开的一种收集注解的流程图；
42.图7为本技术公开的一种依赖注入的执行流程图；
43.图8为本技术公开的一种反射调用流程图；
44.图9为本技术公开的一种基于面向切面编程的类实现装置结构示意图；
45.图10为本技术公开的一种电子设备结构图。
具体实施方式
46.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
47.当前，在不同的场景下通过接口实现不同类的过程中，通过多次注入接口的多个实现类，再分别依次调用实现类满足当前场景下的选择操作。然而，这种方式不仅需要定义实现类的别名，还要在定义别名后引入多个实现类，最后调用不同实现类，造成代码编写比较繁琐。另外，程序执行时，按照顺序依次下发通知，如果前面的下发通知方法报错，后面的方法就无法执行，代码耦合度比较高。
48.为此，本技术提供了一种基于面向切面编程的类实现方案，能够在实现类的过程中简单编写业务代码，降低代码及业务的耦合。
49.本发明实施例公开了一种基于面向切面编程的类实现方法，参见图3所示，该方法包括：
50.步骤s11：接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口。
51.本技术实施例中，以下发通知业务为例对本技术实施例进行说明，后续实施例均参照该场景不再赘述。
52.由于现有技术中，为实现不同的类，分别为不同的实现类定义别名，然后再多次注入接口依次调用，实现根据需求实现不同类进行下发通知，不仅代码编写繁琐，耦合度还高。因此，通过分析现有技术的处理方式的缺陷，可以得出最理想的操作流程是直接调用下发通知的方法，如图4所示。
53.图4中的操作流程是最简单、最直接、最清晰的流程，代码编写的时候不需要关注配置了几种通知方式，只需要直接调用下发通知接口即可。因此，本技术实施例中，在当前场景下，当接收到用户终端发送的操作请求后，如用户需要下发通知，确定下发通知的目标接口，通过调用该接口再调用下发通知的方法，编写业务代码非常简单、清晰,替换掉原本复杂冗余的代码.
54.本技术实施例中，下发通知的目标接口基于面向切面编程(aspect oriented programming，aop)进行编写，通过预编译方式和运行期间动态代理实现程序功能的统一维护的一种技术。aop是oop的延续，是软件开发中的一个热点，也是spring框架中的一个重要内容，是函数式编程的一种衍生范型。利用aop可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。由于目标接口基于aop进行编写，因此在通过目标接口调用下发通知方法时，利用代理对象进行增强实现不同类型的类的调用。
55.步骤s12：基于所述目标接口收集预先构建的用于确定所述类的自定义注解，并对所述代理对象进行依赖注入以得到所述自定义注解的配置信息。
56.本技术实施例中，为了简单清晰的编写业务代码，直接调用目标接口，但是注入实现类的时候，不能用@autowired或者@resource注解，因为目前无论是@autowired还是@
resource注解只支持一次注入一个接口的一种实现，无法实现通过一个接口注入多个实现类，也即，如果有选择多个通知方式的需求时，利用@autowired或者@resource注解无法实现。
57.因此，本技术实施例中使用自定义注解，在一种实施方式中使用自定义注解@di。可以理解的是，注解(annotation)是以@注解名在代码中存在的，是jdk1.5及以后版本引入的，它可以用于创建文档、跟踪代码中的依赖性、甚至执行基本编译时检查。根据注解参数的个数，可以将注解分为：标记注解、单值注解、完整注解三类，它们都不会直接影响到程序的语义，只是作为标识存在，通过反射机制编程实现对元数据的访问。
58.本技术实施例中，自定义注解@di的核心内容是两个属性：value和serviceids。value属性可以确定类的选择方式是全部选择还是指定选择，通常value属性的默认值为all，表示注入的所有实现类；也可以是assign，搭配serviceids可以指定注入哪种实现类。serviceids是一个数组，可以把需要注入的实现类的beanname写入数组。如此一来，注解通过value字段的取值不同，支持找所有的实现类，也支持找单个实现类，也支持优先匹配某个实现类。
59.本技术实施例中，确定了程序代码中使用了自定义注解并对自定义注解进行收集后，根据收集的注解完成代理对象的依赖注入。也即，对代理对象进行依赖注入后可以得到自定义注解的配置信息，相当于把有依赖关系的类放到容器中解析出这些类的实例，实现类的解耦。需要指出的是，依赖注入的是代理对象，因为可能有多个实现类，因此只能使用代理对象进行依赖注入，如此一来，才会在代理对象调用的时候会根据@di的配置信息进行反射调用。
60.步骤s13：当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
61.本技术实施例中，调用下发通知方法的时候，因为可能会调用多个可以实现下发通知的类的下发通知方法，所以需要使用代理对象。然后需要知道要调用哪些类，解析@di自定义注解的配置信息，获取value和serviceids属性的值。如果value为all时，表示调用所有的类，也即，直接在反射调用过程中将所有类确定为目标类；如果value为assign时，表示指定实现类，此时serviceids数组内配置的实现类就是需要调用的实现类，也即，根据serviceids中数组的值确定出需要调用的目标类。进一步的，确定了需要调用的目标类后，执行对应的处理程序去调用配置的目标类的下发通知方法。
62.本技术实施例中，当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值利用handler处理器进行反射调用，以确定出需要调用的目标类。也即，在判断出value值后，确定了需要调用的目标类，利用handler处理器进行反射调用，执行通知方法，实现目标类的下发通知方法。
63.本技术中，接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；基于所述目标接口收集预先构建的用于确定所述类的自定义注解，并对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。可见，在业务场景中确定了需要调用的目标接口后，为了增强接口的注入，自定义
一个注解，把多个实现类注入进去。在执行代码时收集自定义注解，收集注解完成之后，需要根据收集的注解完成依赖注入，因为可能有多个实现类，只能使用代理对象进行依赖注入。如此一来，当调用代理对象时，根据依赖注入得到的自定义注解的配置信息进行反射调用，实现一次性注入同一接口的多个实现类，编写业务代码非常简单、清晰。如此就可以把原本复杂冗余的代码替换掉，而且不用担心多个业务之间一个业务失败其他业务无法正常执行的情况，降低了代码及业务的耦合。
64.本技术实施例公开了一种具体的基于面向切面编程的类实现方法，参见图5所示，该方法包括：
65.步骤s21：接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口。
66.其中，关于上述步骤s21更加具体的处理过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
67.步骤s22：定义自定义注解类，并基于所述自定义注解类实现mergedbeandefinitionpostprocessor接口。
68.本技术实施例中，为了实现一次性注入同一接口的多个实现类，首先需要预先构建自定义注解，具体的，定义自定义注解类，如将自定义注解定义为@di，则定义diannotationbeanpostprocessor类，然后基于diannotationbeanpostprocessor类去实现mergedbeandefinitionpostprocessor接口。
69.步骤s23：基于所述mergedbeandefinitionpostprocessor接口，对postprocessmergedbeandefinition方法进行重写，以得到所述自定义注解。
70.本技术实施例中，参考spring框架的实现，spring是一个开放源代码的j2ee应用程序框架，由rod johnson发起，是针对bean的生命周期进行管理的轻量级容器(lightweight container)。解决了开发者在j2ee开发中遇到的许多常见的问题，提供了功能强大ioc、aop及web mvc等功能。
71.需要指出的是，在mergedbeandefinitionpostprocessor接口中有postprocessmergedbeandefinition方法，因此，基于mergedbeandefinitionpostprocessor接口，对postprocessmergedbeandefinition方法进行重写。
72.在一种具体的实施方式中，参考spring的实现，具体可以参考findautowiringmetadata方法编写finddimetadata方法，该方法属于中间方法，用于处理注解缓存数据；参考buildautowiringmetadata方法编写builddimetadata方法，该方法用于收集注解；参考autowiredfieldelement内部类编写difieldelement内部类，用于属性注入；参考autowiredmethodelement内部类编写dimethodelement内部类，用于方法注入等。
73.如图6所示为收集注解的流程图，其中，参考spring框架完成收集注解的流程，autowiredannotationbeanpostprocessor类完成了收集注解的工作。
74.步骤s24：基于所述自定义注解类继承instantiationawarebeanpostprocessoradapter类，并根据继承后的自定义注解类对postprocessproperties方法进行重写，以实现对所述代理对象的依赖注入。
75.spring中，构成应用程序主干并由spring ioc容器管理的对象称为bean。bean是
一个由spring ioc容器实例化、组装和管理的对象。本技术实施例中，借助spring的beanpostprocessor对加了@di注解的bean作属性增强，把多个类注入进去。
76.本技术实施例中，依赖注入也是参考spring的实现，当然依赖注入的是代理对象，先关注依赖注入的实现，再去关注代理对象的实现。依赖注入的执行流程如图7所示，继承instantiationawarebeanpostprocessoradapter类，重写postprocessproperties方法。然后根据自定义注解时编写的finddimetadata方法，和/或builddimetadata方法，和/或difieldelement内部类，和/或dimethodelement内部类进行依赖注入。
77.本技术实施例中，因为依赖注入的是代理对象，所以要实现依赖注入之前要生成代理对象。要注入代理对象，首先需要生成代理对象，具体的，定义invokeproxy类，编写newproxy()用来新建一个代理对象。由图7中可以看到，依赖注入的时候，调用的是metadata.inject()方法，需要指出的是，注入时可以分为field(字段)注入和method(方法)注入，对应difieldelement和dimethodelement内部类，实际上依赖注入会调用difieldelement.inject()和dimethodelement.inject()方法。也即，在自定义注解时由于定义了不同而内部类进行编写，包括difieldelement内部类和dimethodelement内部类，因此在依赖注入时也会相应的调用difieldelement.inject()和dimethodelement.inject()方法。
78.步骤s25：当所述类中存在新增类时，更新所述自定义注解并对所述代理对象进行依赖注入以得到更新后自定义注解的更新配置信息。
79.本技术实施例中，如果有新的业务功能加进来，业务拓展的时候也比较方便，不需要更新业务代码，只更新@di注解的配置即可。也即，存在新增类可以实现下发通知时，依赖注入时就可以得到更新后自定义注解的更新配置信息。
80.步骤s26：当调用所述代理对象时，对所述更新配置信息进行解析并根据解析后的更新配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
81.本技术实施例中，在进行反射调用时，如果更新了自定义注解的配置信息，则对更新配置信息进行解析，进一步的，确定了需要调用的目标类后，执行对应的处理程序去调用配置的目标类的下发通知方法。
82.如图8所示为反射调用的流程图，调用下发通知方法的时候，因为可能会调用多个实现类的下发通知方法，所以需要使用代理对象。然后执行代理对象，解析@di注解的配置信息获取注解属性，如果value为all时，调用所有的实现类；如果value为assign时，根据serviceids数组内的配置确定需要调用的实现类。确定了value的值之后，执行对应的处理程序去调用配置的实现类的下发通知方法。综合以上步骤，实现一次性调用下发通知接口的多个实现类的下发通知的方法，逻辑清晰，操作简单，可拓展性高。
83.本技术中，接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；定义自定义注解类，并基于所述自定义注解类实现mergedbeandefinitionpostprocessor接口；基于所述mergedbeandefinitionpostprocessor接口，对postprocessmergedbeandefinition方法进行重写，以得到所述自定义注解；基于所述自定义注解类继承instantiationawarebeanpostprocessoradapter类，并根据继承后的自定义注解类对postprocessproperties方法进行重写，以实现对所述代理对象的依赖注入；当所
述类中存在新增类时，更新所述自定义注解并对所述代理对象进行依赖注入以得到更新后自定义注解的更新配置信息；当调用所述代理对象时，对所述更新配置信息进行解析并根据解析后的更新配置信息中的属性值进行反射调用，以确定出需要调用的目标类。可见，在业务场景中确定了需要调用的目标接口后，为了增强接口的注入，自定义一个注解，把多个实现类注入进去。在执行代码时收集自定义注解，收集注解完成之后，需要根据收集的注解完成依赖注入，因为可能有多个实现类，只能使用代理对象进行依赖注入。如此一来，当调用代理对象时，根据依赖注入得到的自定义注解的配置信息进行反射调用，实现一次性注入同一接口的多个实现类，编写业务代码非常简单、清晰。如此就可以把原本复杂冗余的代码替换掉，而且不用担心多个业务之间一个业务失败其他业务无法正常执行的情况，降低了代码及业务的耦合。
84.相应的，本技术实施例还公开了一种基于面向切面编程的类实现装置，参见图9所示，该装置包括：
85.目标接口确定模块11，用于接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；
86.注解收集模块12，用于基于所述目标接口收集预先构建的用于确定所述类的自定义注解；
87.依赖注入模块13，用于对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；
88.目标类确定模块14，用于当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。
89.其中，关于上述各个模块更加具体的工作过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
90.由此可见，通过本实施例的上述方案，接收用户终端发送的操作请求，并确定所述操作请求中需要调用的目标接口；其中，所述目标接口为基于面向切面编程利用代理对象实现不同类型的类的调用的接口；基于所述目标接口收集预先构建的用于确定所述类的自定义注解，并对所述代理对象进行依赖注入以得到所述自定义注解的配置信息；当调用所述代理对象时，对所述配置信息进行解析并根据解析后的配置信息中的属性值进行反射调用，以确定出需要调用的目标类。可见，在业务场景中确定了需要调用的目标接口后，为了增强接口的注入，自定义一个注解，把多个实现类注入进去。在执行代码时收集自定义注解，收集注解完成之后，需要根据收集的注解完成依赖注入，因为可能有多个实现类，只能使用代理对象进行依赖注入。如此一来，当调用代理对象时，根据依赖注入得到的自定义注解的配置信息进行反射调用，实现一次性注入同一接口的多个实现类，编写业务代码非常简单、清晰。如此就可以把原本复杂冗余的代码替换掉，而且不用担心多个业务之间一个业务失败其他业务无法正常执行的情况，降低了代码及业务的耦合。
91.进一步的，本技术实施例还公开了一种电子设备，图10是根据一示例性实施例示出的电子设备20结构图，图中内容不能认为是对本技术的使用范围的任何限制。
92.图10为本技术实施例提供的一种电子设备20的结构示意图。该电子设备20，具体可以包括：至少一个处理器21、至少一个存储器22、电源23、通信接口24、输入输出接口25和
通信总线26。其中，所述存储器22用于存储计算机程序，所述计算机程序由所述处理器21加载并执行，以实现前述任一实施例公开的基于面向切面编程的类实现方法中的相关步骤。另外，本实施例中的电子设备20具体可以为计算机。
93.本实施例中，电源23用于为电子设备20上的各硬件设备提供工作电压；通信接口24能够为电子设备20创建与外界设备之间的数据传输通道，其所遵循的通信协议是能够适用于本技术技术方案的任意通信协议，在此不对其进行具体限定；输入输出接口25，用于获取外界输入数据或向外界输出数据，其具体的接口类型可以根据具体应用需要进行选取，在此不进行具体限定。
94.另外，存储器22作为资源存储的载体，可以是只读存储器、随机存储器、磁盘或者光盘等，其上所存储的资源可以包括操作系统221、计算机程序222及数据223等，数据223可以包括各种各样的数据。存储方式可以是短暂存储或者永久存储。
95.其中，操作系统221用于管理与控制电子设备20上的各硬件设备以及计算机程序222，其可以是windows server、netware、unix、linux等。计算机程序222除了包括能够用于完成前述任一实施例公开的由电子设备20执行的基于面向切面编程的类实现方法的计算机程序之外，还可以进一步包括能够用于完成其他特定工作的计算机程序。
96.进一步的，本技术实施例还公开了一种计算机可读存储介质，这里所说的计算机可读存储介质包括随机存取存储器(random access memory，ram)、内存、只读存储器(read-only memory，rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、磁碟或者光盘或技术领域内所公知的任意其他形式的存储介质。其中，所述计算机程序被处理器执行时实现前述基于面向切面编程的类实现方法。关于该方法的具体步骤可以参考前述实施例中公开的相应内容，在此不再进行赘述。
97.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
98.结合本文中所公开的实施例描述的基于面向切面编程的类实现或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
99.最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
100.以上对本发明所提供的一种基于面向切面编程的类实现方法、装置、设备及介质进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术
人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。