装饰器微妙之谈

简介: 装饰器微妙之谈


简单的装饰器


def my_decorate(fun):
    def wrapper():
        print('这是个装饰器!')
        func()
     reture wapper
def greet():
 print('hello world')
greet = my_decorator(greet)
greet()
# 输出
这是个装饰器!
hello world

这段代码中变量 greet 指向了内部函数 wrapper(),而内部函数 wrapper() 中又会调用原函数 greet(),因此,最后调用 greet() 时,就会先打印 'wrapper of decorator',然后输出'hello world'。大家应该都明白!


这里的函数 my_decorator() 就是一个装饰器,它把真正需 要执行的函数 greet() 包裹在其中,并且改变了它的行为, 但是原函数 greet() 不变。


我们换一种写法,使用Python来装饰它

def my_decorator(func):   
    def wrapper():    
       print('wrapper of decorator')   
        func()  
    return wrapper
@my_decorator
def greet(): 
   print('hello world')
greet()

这里的@,我们称之为语法糖,@my_decorator就相当于 前面的greet=my_decorator(greet)语句,只不过更加 简洁。因此,如果你的程序中有其它函数需要做类似的装饰,你只需在它们的上方加上@decorator就可以了,这样 就大大提高了函数的重复利用和程序的可读性。


带有参数的装饰器


如果原函数 greet() 中,有参数需要传递给 装饰器怎么办?一个简单的办法,是可以在对应的装饰器函数 wrapper() 上,加上相应的参数,比如:


def my_decorator(func):
    def wrapper(message):
       print('wrapper of decorator')
       func(message)
     return wrapper
@my_decorator
def greet(message):
     print(message)
greet('hello world')
# 输出
wrapper of decorator
hello world


事实上,通常情况下,我们会把*args和**kwargs,作为 装饰器内部函数 wrapper() 的参数。


def my_decorator(func):
    def wrapper(*args, **kwargs):
       print('wrapper of decorator')
       func(*args, **kwargs)
    return wrapper

类装饰器


实际上,类也可 以作为装饰器。类装饰器主要依赖于函数__call_(),每当你调用一个类的示例时,函数__call__() 就会被执行一 次

class Count:
   def __init__(self, func):
       self.func = func
       self.num_calls = 0
   def __call__(self, *args, **kwargs):
       self.num_calls += 1
       print('num of calls is: {}'.format(self.num_calls))
       return self.func(*args, **kwargs)
@Count
def example():
   print("hello world")
example()
# 输出
num of calls is: 1
hello world
example()
# 输出
num of calls is: 2
hello world

这里,定义了类 Count,初始化时传入原函数 func(), 而__call__() 函数表示让变量 num_calls 自增 1,然后打印,并且调用原函数。因此,在我们第一次调用函数 example() 时,num_calls 的值是 1,而在第二次调用时, 它的值变成了 2。

相关文章
|
5月前
|
设计模式 程序员
故意把代码写得很烂,这样的 “防御性编程“ 可取吗?
故意把代码写得很烂,这样的 “防御性编程“ 可取吗?
|
8月前
|
设计模式 IDE Java
谈谈过度设计:因噎废食的陷阱
本文探讨了设计模式在软件开发中的应用和争议,指出设计模式虽有助于应对软件复杂性,但在互联网快速迭代的背景下,可能会导致过度设计,增加理解和修改成本。文章分析了设计模式的缺陷,如开闭原则可能导致不易修改,最小知识原则可能导致理解困难。同时,文章强调了设计模式的重要性,指出它们可以提高代码的可理解性和模块的可维护性,并提出了通过函数式设计模式进行优化的示例。作者认为,设计模式需要随着业务演进而不断演进,同时提倡使用可调试的模块和模式演进来促进系统的成长性。文章最后提醒读者,要根据实际情况选择是否使用设计模式,避免因噎废食。
|
8月前
|
算法
犯错总结--工厂模式和策略模式傻傻没分清
犯错总结--工厂模式和策略模式傻傻没分清
68 0
犯错总结--工厂模式和策略模式傻傻没分清
|
编译器 C++
C++ Primer Plus 第十四章答案 C++中的代码重用
只有聪明人才能看见的摘要~( ̄▽ ̄~)~
71 0
|
消息中间件 安全 程序员
关于防御性编程,你应该知道的事
提起编程,对于程序员同学而言并不陌生,关于防御性编程相信大家也有所耳闻,但是它具体包括哪些内容呢?
关于防御性编程,你应该知道的事
|
设计模式 算法 Java
巧妙的运用装饰器,让你的代码高出一个逼格!
又到了周末了,阿粉祝各位网友中秋快乐,阖家团圆!同时,节日期间,阿粉不打烊,欢迎网友观看吐槽~
巧妙的运用装饰器,让你的代码高出一个逼格!
|
缓存 移动开发 前端开发
从 SWR 开始 — 一窥现代请求 hooks 设计模型
本文将以 swr 为例子,讲述现在最热门的 useRequest、swr 和 react-query 三个请求 hooks 的新机制,以及新机制后 class Component 和 hooks 在设计上的区别。
从 SWR 开始 — 一窥现代请求 hooks 设计模型
|
安全
细节是魔鬼——基于计数器的锁机制的实现准则
有点标题党了,本意是想把对内核锁机制的一些实现细节记录下来,但多少反映了锁机制实现时的一些准则。本文讨论的锁机制主要指基于计数器的锁机制例如 spinlock、mutex,不包括 RCU 这类锁机制。 ### parallesim 在讨论各种锁机制之前,有必要讨论系统的并行度,即有哪些潜在的竞争场景 1. 中断上下文与进程上下文对共享资源的访问,由于中断是异步进行的,因而中断与进程是并发执行
366 0
|
设计模式 Java
一起来看引用与现实的邂逅 | 带你学《Java面向对象编程》之二十二
本节通过三则分析为读者介绍了类关联结构、类自身关联等逻辑与合成设计模式的概念,带读者去理解类的灵活性。
一起来看引用与现实的邂逅    | 带你学《Java面向对象编程》之二十二
|
存储 iOS开发
探寻Objective-C引用计数本质
本文涉及到的CPU架构为arm64,其它架构大同小异。 源码来自苹果开源-runtime。 Objective-C中采用引用计数机制来管理内存,在MRC时代,需要我们手动retain和release,在苹果引入ARC后大部分时间我们不用再关心引用计数问题。
1082 0

热门文章

最新文章