上篇文章简单介绍了python中描述器（Descriptor）的概念和使用，有心的同学估计已经Get√了该技能。本篇文章通过一个Descriptor的使用场景再次给出一个案例，让不了解情况的同学可以更容易理解。 [b]先说说decorator[/b] 这两个单词确实是有些相似，同时在使用中也是形影不离。这也给人造成了理解上的困难，说装饰器和描述器到底是怎么回事，为什么非得用一个@符号再加上描述器才行。 很多文章也都把这俩结合着讲，我自己看完之后都会觉得很绕。其实学习一个知识点，和做项目开发一个功能是一样的。在功能拆分的时候我们都会尽量的把任务拆分的足够小，然后才分配到开发者头上。这样保证各个任务的独立性，完整性，并且易于做进度管理。在任务开发的时候也不能把你的任务都放到一个函数/接口中去做，以避免各功能间产生高耦合的状况，导致后期难以维护。 再说回到学习一个技术点，如果你总是尝试一下子就要掌握两个或多个技术点，结果可能是忙活了半天，发现还是晕头转向。 擦，好像扯远了。 说Descriptor是Descriptor, Decorator是Decorator，遇到不懂的地方，各个击破，哪里不懂点哪里。所以先说Decorator， 关键点是你要意识到这就是一个语法糖 。所谓语法糖就是让你可以用简单的方式写代码。本质上装饰器（Decorator）就是这样: [b]正题：通过Descriptor来做一个类级的Property[/b] 常见的Property是这样的: 这中property的使用，是实例级的应用。因为只有在 foo = Foo() 之后，才可以 foo.name 。 但是如果我需要一个类级的属性应该怎么做呢，就像是 classmethod一样，不需要实例化类我就可以调用。对应的需求是这样的，定义了一个基类DBManage: 这其实一个对应着数据库中某张表的基础模型，我希望其他的Model都来继承它，然后可以重用这个table_name的方法（目前还是方法）。 我只需要这么定义User模型即可: 然后这么定义Post模型: 这样我如果需要查所有的User数据，只需要 User.select_all() 即可，同理Post也是如此 Post.select_all() 。但此时发现一个有点不爽的事情。那就是基类中的 cls.table_name() 这个代码，table_name看起来就是属性，却需要用调用方法的方式获取。不妥。 于是自定义了一个classproperty: 这需要这样，我在DBManage中的代码就可以改为: 这就是Descriptor另外的一个使用案例了。 可能有人或有一个小疑问：为毛你不是在sql赋值时直接 sql = "SELECT * FROM %s" % cls.__name__.lower() 。这个问题，问的非常好，原因就一个字：懒。懒得以后每次都得敲那么多代码。