属性和方法

在类中直接定义的参数是类属性，实例属性可以访问类和实例属性，类对象不能直接调用实例属性。
在类中定义，以self为第一个参数的都是实例对象。
当通过实例对象调用实例时，调用的参数就是self，当类调用实例对象时，不会把调用参数作为实例传递，故缺少一个参数。假设A是类，a是A的一个实例，当A中有一个name方法时，两者调用并传递a的值的格式分别为，a.name（）和A.name（a）
如果在类中想定义类属性的方法，则上面一行加@classmethod（method中文名词意思为方法，类函数）此时定义的方法通常用cls来取代self
在类中我们称@staticmethod定义的函数为静态方法，不需要任何默认参数，静态对象可以被实例和类调用，静态方法与类本身无关，是一个功能函数，但必须以方法的形式来调用。

模块

模块化，顾名思义，将一个完整的程序分成一个小小的模块。
模块化方便开发并且方便维护。
模块可以复用。
在python中其实一个.py文件就是一个模块。
模块引入的方法：

import 模块名
import 模块名 as 模块在这个程序中的名字（自己可以给模块定义一个新名字，在调用时可以更加符合自己的习惯）
from 模块名 import 变量，这种方法再调用时不需要用模块名.变量的格式，可以直接使用引入的变量。当需要引入一个模块中的多个变量时可以写成 from 模块名 import 变量1，变量2，变量3
from 模块名 import 变量 as 新的名字，这样是为了防止主模块和调用模块同名，给调用的变量设置一个新的名字。
from 模块名 import *可以直接引入模块中的所有变量，并且不需要声明模块名。


一个模块可以多次引入，但模块只会执行一次，模块执行时也会输出模块里的print，我们可以用if name==‘main’:来判断这个是不是主模块来决定是否运行他，这样他在被别的模块调用时，就不会执行被if判断后的代码。
print（模块名）会输出模块和他名字所指向的位置。
print（name）被其他模块调用时，会输出这个被调用模块的名字，如果直接运行则会输出__main__表示当前文件是主文件。
当模块被引用时，和主模块同名的变量会覆盖主模块的变量。
_变量名，这样写的变量名，是不希望被别人修改的意思。

迭代器

迭代器时访问元素的一种方式。
特点是便于记住元素位置。
迭代器通常由方法iter和next组成

···

lst = [1,2,3,4,5,6,7]

myiter = iter(lst)
print(next(myiter))

print(next(myiter))

print(next(myiter))

print(next(myiter))

print(next(myiter))

print(next(myiter))

print(next(myiter))

···

输出1，2，3，4，5，6，7

这种格式就别成为迭代数据结构。

这种访问方式和

···

for i in myiter:

print(i)

···

访问的结果是一样的，不过是另一种方式。

迭代器不可后退，当next超过元素总数时，则会报错。

生成器
在python中使用yield（中文名词意思产量）这个关键字，我们就称之为生成器函数或者生成器，他和普通函数的区别是，他会返回一个迭代器。

···

def fn():

print(‘11’)

yield 1

print(‘12’)

print(‘13’)

yield 3

print(‘14’)

yield 4

print(‘15’)

yield 5

f = fn()

print(type(f))

print(‘返回:’,next(f))  # 11 返回: 1

print(‘返回:’,next(f))  # 12 返回: 2

print(‘返回:’,next(f))  # 13 返回: 3

···

输出：

<class ‘generator’>

11

返回: 1

12

13

返回: 3

14

返回: 4

<class ‘generator’>表示这个函数的类型是迭代的，事实上只要函数中有一个yield函数就是迭代的。next函数每次会在函数中读取一个yield变量。

 模块化似乎是一个老生常谈的问题，在这里先聊聊一些背景，设计模式曾经风靡一时，但貌似模式变得很司空见惯，开发人员会经常不假思索的使用各种模式。
确实模式帮助一代开发人员接受和认识到了一种新的编程范式，我们经常谈到的面向对象设计原则也都体现在了设计模式中,这些新形成的共识指导了面向对象开发，但问题是创建大型软件系统依然是困难的，它们依然难以维护’、扩展和管理，也就是说现有的面向对象开发模式不能很好的管理系统复杂性，他们解决的是软件开发中的逻辑设计问题，但在软件的物理设计方面还有很大挑战，这里就引出了什么是物理设计、逻辑设计又是何物？
逻辑设计：逻辑设计是关于语言结构的，如类、操作符、方法和包。识别类的方法、类之间的关系以及包的结构问题是逻辑设计问题。例如，觉得一个类是否需要继承？是否单例？一个操作是否为抽象这都是逻辑设计问题，可想而知，大多数开发人员都是在操作这些对象，就会不断处理逻辑设计问题，逻辑设计只是软件设计挑战的一方面，另一方面就是物理设计。
物理设计：物理设计表现为物理实体的操作，比如如何打包部署，如何决定这个类属于哪一个部署单元，可部署单元实体之间的关系都是物理设计的问题。遗憾的是大多数团队付出很大一部分时间在逻辑设计上，但在物理设计上却很少下功夫，物理设计说白了就是如何将系统拆分为模块，以及管理模块之间关系的方法，缺乏物理设计的逻辑设计通常也不会达到预期的效果。
 那么具体在java中我们如何理解模块呢？简单说就是“一个软件块” (貌似等于没说)，但这个定义不好区分于类，包，组件和服务，关于模块它应该具备以下特征：可部署，可管理，可重用，可组合，无状态的软件单元，来个图先
定义模块
可部署：没错，不同其他软件单元，它是一个部署单元，模块所表达的意义更多是粗粒度物理层面的实体，可能你想到了很多例子如EAR，WAR，JAR。
可管理：可管理的意思就是说在运行时可进行安装、卸载和更新，包括版本的管理。将系统拆分为模块有助于开发人员隔离开发自主模块并按照模块边界规划开发工作(如EAR，WAR，JAR)。
可重用：这里说的模块其实是进程内重用单元，尽管SOA(面向服务的架构 Service-Oriented-Architecture)也是来设计软件模块的，但这里所述的模块与应用或服务不同，它不属于分布式技术，也就是说模块暴露的操作是通过直接调用方法触发的。
可组合：模块是可以组合的，大模块可以由小模块组成，粗粒度模块是由细粒度的模块组合的。
无状态：模块本身是无状态的，尽管我们在使用模块时需要实例化其中的类，这些类会保持某种状态，就模块本身而言是无状态的(如EAR，WAR，JAR)。
综上述：java中最适合做模块的单元是？没错就是jar。
下一篇我将讲解下【模块化实践包含哪些方面】，敬请期待！个人理解有所纰漏，还请老铁们多多指教！

一、单一职责原则

定义：一个对象应该只包含单一的职责，并且该职责被完整的封装在一个类中。
说明：一个类或模块，所承担的职责越多它被复用的可能性就越小，耦合性就越大，当其中一个职责变化的时候可能会影响其他职责的运作。

二、开闭原则

定义：软件实体应该对扩展开放，对修改关闭。
说明：通俗的说就是软件实体应该尽量在不修改源代码的情况下进行扩展。

三、里氏代换原则

定义：所有引用到基类的地方必须能透明的使用其子类的对象
说明：在使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用使用基类类型来定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

四、依赖倒转原则

定义：高层模块不应该依赖低层模块，他们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象
说明：依赖倒转原则要求针对接口编程，不要针对实现编程。使用接口或抽象类进行变量类型声明，参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。

五、接口隔离原则

定义：客户端不应该依赖那些它不需要的接口。
说明：当我们的接口太大的时候，需要将它分割成一些更小的细节接口，每一个接口应该承担一种相对独立的角色，不干不相关的事，该干的事都要干，也就是前面单一职责原则。

六、合成复用原则

定义：优先使用对象组合，而不是通过继承来达到复用的目的。
说明：在一个新的对象里通过关联关系（包括组合，聚合）来使用一些已有的对象，使之成为新对象的一部分，新对象通过委派调用已有对象的方法达到复用功能的目的。尽量使用关联关系，少用继承，降低耦合度

七、迪米特法则

定义：每一个软件单位对其他单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
说明：一个软件实体应当尽可能少的与其他实体发生相互作用，这样当某个模块需要或者类发生修改的时候会尽量少的影响其他模块，扩展会相对容易。

在使用tp5的路由是，写了一个路由规则（route.php）



本来只是想在index模块使用，突然发现影响到了admin模块，admin模块下的admin/news/xxx 不能正常访问了，原因就是路由规则影响到了。

后来查了下文档，说是route.php是针对的应用，单独在模块里定义route.php是无效的，当然，也可以在配置文件中的route_config_file中通过   模块名/route.php 的方式添加使模块里定义的route.php生效，但是仍然是影响到admin模块，

然后，我就又走了老套路。。改代码

具体怎么找的我就不说了，直接上结果

最终在\thinkphp\library\think\App.php里找到了routeCheck方法



把方法里的路径加上BIND_MODULE."/",BIND_MODULE需要你在模块的入口文件定义，也就是你的模块名，这样，访问的时候，只会使用对应模块下的路由规则(route.php），不会相互影响，当然，不要再runtime文件夹下加route.php，不然就不灵了，动态添加的话，我没有试，因为比较懒。。。。你可以自己试试成不成，不成的话，你试试把\thinkphp\library\think\console\command\optimize\Route.php下面的buildRouteCache方法照着上面的做法修改下，有用的话记得告诉我