cbv继承view是哪个包_Python-继承的优缺点S(1)--> django通用视图分析

Django通用视图中的混入

"""
在Django中，
视图(view)是可调用的对象，
        传入参数：是表示HTTP请求的对象
        返回值：表示HTTP响应的对象
关注返回值（即响应的对象）

起初，Django 提供的是一系列函数，这叫通用视图，实现常见的用例
eg:
taobao网都需要展示搜索结果，里面包含很多项目，分成多页，而且各个项目会链接到详细信息页面。
django的实现：这种需求使用 列表视图（渲染搜索结果）和详情视图（生成各个项目的详情页面）实现。

然而，最初的通用视图是函数，不能扩展。如果需求与列表视图相似但不完全以信仰，那么不得不自己从头实现。

django 1.3 引入了基于类的视图，而且还通过基类、混入和拿来即用的具体类提供了一些通用视图类,这些基类和混入在django.views.generic包的base模块里，
位于顶部的两个类，View和TemplateResponseMixin，负责完全不同的工作 -->等有时间，打一下注释理解

参考链接：
http://ccbv.co.uk
https://github.com/django/django/blob/master/django/views/generic/base.py

"""

"""
View是所有视图（可能是个抽象基类）的基类，提供核心功能（如dispatch方法），这个方法委托具体子类实现的处理方法（handler），如get、head、post等，处理不同的HTTP动词。

RedirectView类只继承View，可以看到，它实现了get、head、post等方法

View的具体子类应该实现处理方法，但他们为什么不在view接口中呢？
原因是：子类只需实现它们想支持的处理方法。
TemplateView只用于显示内容，因此它只实现了get方法。
如果把HTTP POST请求发给TemplateView，经继承的View.dispatch方法检查，
没有实现post处理方法，因此会返回HTTP 405 Method Not Allowed(不允许使用的方法)响应。


TemplateResponseMixin 提供的功能只针对需要使用模板的视图，例如
RedirectView没有主体内容，因此它不需要模板，也就没有继承这个混入。

TemplateResponseMixin为TemplateView和django.views.generic包中定义的使用模板渲染的其它视图（ListView、DetailView，等等）提供的行为。

Django程序员知道，as_view类方法是View接口最为重要的部分。

如果深入了解设计模式，你会发现django的分派机制是动态版模板方法模式（https://en.wikipedia.
org/wiki/Template_method_pattern）
为啥是动态的？
因为view类不强制子类实现所有处理方法，而是让dispatch方法在运行时检查有没有针对特定请求的具体处理方法。

"""

"""
对于django用户来说，在图12-5中，最重要的类时ListView，这是一个聚合类，不含任何代码（定义体中只有文档字符串）。ListView实例有个object_list属性，模板会迭代它显示页面的内容，通常是数据库查询返回的多个对象。生成这个可迭代对象列表的相关功能都由MultipleObjectMixin 提供。

这个混入还提供了复杂的分页逻辑，即在一夜中显示部分结果，并提供只想其他页面的链接。

假设你想创建一个使用模板渲染的视图，但是会生成一组 JSON 格式的对象，此时用得到BaseListView类。这个类提供了易于使用的扩展点，把View和MultipleObjectMixin的功能整合在一起，避免了模板机制的开销。

！！！
Django基于类的视图API是多重继承更好的示例。尤其是，
djano的混入类易于理解：各个混入的目的明确，而且名称的后缀都是...Mixin 

Django 用户还没有完全拥抱基于类的视图，很多人确实在使用，但是用法有限，把他们当成黑盒；   
需要新功能时，很多Django程序员依然选择编写单块视图函数，负责处理所有的事务，而不尝试重用基视图和混入！ 
-->我好好反思一下
"""
"""
学习基于类的视图和根据应用需求扩展它们确实需要一些时间，不过我觉得这是值得的：
基于类的视图能避免大量的样板代码，便于重用，还能增进团队交流-->eg:为模板和传给模板上下文的变量定义标准的名称。基于类的视图把Django视图带到了正轨上。

--> 把这部分再撸两遍，我就看看django的源码，生活越来约有意思了！
"""
"""
大佬曾经说过：“django通过混入设计的视图层次结构有点混乱。”
but(not bug) but -->大佬又说了： “多重继承的危害和缺点被放大了。我从来不觉得它是什么大问题。”

又一大佬总结了：
“总之，每个人对如何使用以及要不要在自己的项目中使用多重继承都有自己的观点。”
but but but "我们往往没得选择，因为我们必须使用的框架由它们自己的选择。"

"""

延伸（感觉含金量最高的地方，淘淘淘）

"""
使用抽象基类，多重继承很常见，而且实际上也是不可避免的，因为最基本的集合抽象
(Sequence、Mapping 和 Set)都扩展多个抽象基类。collections.abc的源码
Lib/_ collections_abc.py，
https://hg.python.org/cpython/file/3.4/Lib/_collections_abc.py)
是抽象基类 使用多重继承的范例——其中很多还是混入类。
"""
"""
Raymond Hettinger 写的文章，从积极的角度解说了 Python 的 super 和多重继承的运作原理。
“Python’s super() considered super!”(https://rhettinger.wordpress. com/2011/05/26/super-considered-super/)

这篇文章是对 James Knight 的“Python’s Super is nifty, but you can’t use it”
(以前题为“Python’s Super Considered Harmful”，https://fuhm.net/super-harmful/)一文作出的回应。
"""
'''
尽管这两篇文章的题目中提到了内置的 super 函数，但它不是真正的问题——Python 3 中 的 super 函数没有 Python 2 中那么令人讨厌了。

真正的问题是多重继承，它天生复杂，难以处理。

(大佬)Michele Simionato不再批评这一点，他在
“Setting Multiple Inheritance Straight”一文
(http://www.artima.com/weblogs/viewpost.jsp?thread=246488)中给出了解决方案:
他实现了性状(trait)，这是一种受限的混入，源自 Self 语言。

Simionato 写了一系列具有启发性的博客文章，对 Python 的多重继承进行了探讨，
包括

“The wonders of cooperative inheritance, or using super in Python 3”(http://www.artima.com/weblogs/viewpost.jsp?thread=281127)，

“Mixins considered harmful”
第一部分(http://www.artima.com/weblogs/viewpost.jsp?thread=246341)
第二部分(http://www.artima.com/weblogs/viewpost.jsp?thread=246483)

“Things to Know About Python Super” 
第 一 部分(http://www.artima.com/weblogs/viewpost.jsp?thread=236275) 
第 二 部分(http://www.artima.com/weblogs/viewpost.jsp?thread=236278)
第 三 部分(http:// www.artima.com/weblogs/viewpost.jsp?thread=237121)
最早的文章使用Python2的super句法，不过依然值得一读。
'''

杂谈（这是杂谈吗？OMG, 这是根本就是在正儿八经的说正事呢！！）

"""
想想哪些类是真正需要的
大多数程序员编写应用程序而不开发框架。即便是开发框架的那些人，多数时候(或 大多数时候)也是在编写应用程序。

编写应用程序时，我们通常不用设计类的层次结构。
我们至多会编写子类、继承抽象基类或框架提供的其他类。作为应用程序开发者，我们极少需要编写作为其他类的超类的类。
我们编写的类就都是末端类（即继承树的叶子）

如果作为应用程序的开发者，你发现自己在构建多层类层次结构，可能是发生下述事件中的一个或多个。
a、你在重新发明轮子。-->去找框架或库，它们提供的组建可以在应用程序中重用。
b、你使用的框架设计不良。-->去寻找替代品
c、你在过度设计。-->记住要遵守KISS原则（什么鬼、什么嘛、 原则吗？我太肤浅了）。
        """
            KISS原则（此KISS不是我想的kiss）：
            https://blog.codingnow.com/2009/03/aiaeeoooo.html  --> 我天 09年的时候，我还在读初中
            http://people.apache.org/~fhanik/kiss.html
            https://www.cnblogs.com/yutiansanshou/archive/2012/12/05/2802653.html
        """
d、你厌烦了编写应用程序，决定新造一个框架，恭喜，猪你好运。

这些事情你可能会都会遇到：你厌倦了，决定重新发明轮子，自己构建设计过度和不良的框架，因此不得不编写一个又一个类去解决鸡毛蒜皮的小事（我天，我忘记了，我有没有这么做过，OMG!!!,我错了）。希望你乐在其中，至少得到应有的回报。（OMG，我要去厕所边呼吸点新鲜空气，反思一下）
"""
"""
内置类型的不当行为是缺陷还是特性
内置的dict、list和str类型是python的底层基础，因此速度必须快，与这些内置类型有关的任何性能问题几乎都会对其他所有代码产生重大影响。
于是，CPython 走了捷径，
故意让内置类型的方法行为不当，即不调用被子类覆盖的方法。

解决这一困境的可能方式之一是，为这些类型分别提供两种实现:
一种供内部使用，为解释器做了优化;
另一种供外部使用，便于扩展。

但是等等，我们已经拥有这些了:UserDict、UserList 和 UserString 虽然没有内置类型的速度快，但是易于扩展。
CPython 采用的这种务实方式意味着，我们也要在自己的应用程序中使用做了优化但是难以子类化的实现。
这是合理的，因为我们每天都使用dict、list 和 str，但是很少需要定制映射、列表或字符串。我们只需知道其中涉及的取舍。
"""
"""
其他语言对继承的支持

面向对象”这个术语是 Alan Kay 发明的，而 Smalltalk 只支持单继承，不过有些派生 版以不同的方式支持多重继承，例如现代的 Squeak 和 Smalltalk 方言 Pharo 支持性状
(trait)——这是实现混入类的语言结构，而且能避免多重继承的一些问题。

C++ 是第一门实现多重继承的流行语言，但是这一功能被滥用了，因此意欲取代 C++ 的 Java 不支持多重继承(即没有混入类)。不过，Java 8 引入了默认方法，这使得接 口与 C++ 和 Python 用于定义接口的抽象类十分相似。但是它们之间有个关键的区别: Java 的接口没有状态。Java 之后，使用最广泛的 JVM 语言要数 Scala 了，而它实现了 性状。支持性状的其他语言还有最新稳定版 PHP 和 Groovy，以及正在开发的 Rust 和 Perl 6。因此可以说，性状是目前的趋势。

Ruby 对多重继承的态度很明确:对其不支持，但是引入了混入。Ruby 类的定义体中 可以包含模块，这样模块中定义的方法就变成了类实现的一部分。这是“纯粹”的混 入，不涉及继承，因此 Ruby 混入显然不会影响所在类的类型。这种方式凸显了混入 的优点，避免了很多常见问题。

最近广受瞩目的两门语言——Go 和 Julia——对继承的支持极其有限。Go 完全不支持 继承，但是它实现的接口与静态鸭子类型相似(详情参见第 11 章的“杂谈”)。Julia 回避“类”(class)这个术语，只接受“类型”(type)。Julia 有类型层次结构，但是子 类型不能继承结构，只能继承行为，而且只能为抽象类型创建子类型。此外，Julia 的 方法使用多重分派，这是 7.8.2 节所述机制的高级形式。
"""

看书也是有乐趣的！！！ 哈哈哈！！！

我是lin，加油加油加油！！！