09 装饰器性能比较
前面我们探讨了装饰器的实现方式,并实现了一个所谓的通用装饰器模式,并用它创建了一个类似 Java 的 @synchronized 装饰器作为使用示例。本节我们来看看不同的装饰器实现方式的性能问题。在这篇关于装饰器的实现性能这篇文章之后,我们将开始深入探讨如何实现代理,它是通用装饰器机制中的基础组件。
前面我们探讨了装饰器的实现方式,并实现了一个所谓的通用装饰器模式,并用它创建了一个类似 Java 的 @synchronized 装饰器作为使用示例。本节我们来看看不同的装饰器实现方式的性能问题。在这篇关于装饰器的实现性能这篇文章之后,我们将开始深入探讨如何实现代理,它是通用装饰器机制中的基础组件。
在前一篇文章中,我们描述了如何使用新的通用装饰器模式来实现Python的 @synchronized 同步原语装饰器。在Java提供的两个同步机制中,同步方法和同步原语,目前为止我们只实现了同步方法。本文将描述如何将其扩展为上下文管理器,从而等效的实现Java的同步原语。
在之前的博客中,我们讨论了装饰器的实现,并实现了一个通用装饰器模式。作为这种模式的使用示例,本节我们来实现 java 中的 @synchronized 装饰器。
java 的同步原语有两种形式,分别是同步方法和同步代码块。在Java 中创建同步方法,只需要在其定义时添加synchronized关键字即可。
上一篇文章中,我们讨论了如何实现一个带参数的装饰器,以及如何让装饰器可选的接收参数而不是必需输入参数。也讨论了如何让装饰器能在被包装函数的不同调用之间保持状态。保持状态的一种可用方法是使用类实现装饰器。然而我们实现的通用装饰器模式在使用类实现装饰器还存在一些问题,本文我们将来探讨问题出现的根源以及如何解决。
在之前的博客,通过使用代理对象,装饰器工厂函数等技术,我们已经实现了一个通用装饰器。在这篇文章中,我们将使用前面文章中描述的装饰器工厂函数,介绍如何使用它来实现接受参数的装饰器,包括强制参数和可选的接收参数。
本节我们将实现一个"通用装饰器",它能够让用户提供的包装函数通过传入的参数判断其被使用的上下文,即确定,它是被应用在函数,实例方法,类方法,类对象中的哪一个。因为装饰器不是在各个环境种被单独实现,而是以一种更加统一的方式创建,所以将这种能确定上下文的装饰器称为通用装饰器。