ThinkPHP门面源码解析(2)

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
全局流量管理 GTM,标准版 1个月
云解析 DNS,旗舰版 1个月
简介: ThinkPHP门面源码解析

三、优化在框架中facade的使用

在上文中我们从实例化类到使用门面方式实现了同一个功能。


虽说想要实现的效果显示出来了,但是代码还是不够简洁优美的,结构也比较混乱。


接下来咔咔会给大家提供一个可行的方案,如果你有其它的方案可以提出来哈!评论区见。


在正常开发工作中自定义的门面类不可能只有一个或者几个,在复杂的项目中门面类会有很多。


既然多,那就需要进行管理。


image.png


首先建立一个属于门面的配置类。


并将代理类和实际类对应起来,然后设置别名。


image.png


此时需要建立一个钩子文件,将门面类注册和门面类别名注册都放在里边进行执行。


image.png


还有最后一步,那就是钩子文件虽然创建了但是没有执行。


那么钩子文件应该什么时候执行呢!那就是在应用初始化的时候进行加载。


在TP5.1中应用初始化的配置是在application/tags.php这个文件中。


在应用初始化的配置项里把钩子文件配置进去即可。


image.png


测试


最后一步就是测试了,依然是执行application/index/controller/Facade.php文件中的getUserInfo方法。


根据测试结果可以得知我们的方案代码编写没有问题。


image.png

image.png


这里有没有发现一个问题,就是既然在钩子中定义了门面类的别名了,但是在这里并没有使用。


接下来我们使用别名来测试一下。


image.png



四、门面类源码解析

在解析源码之前先认识俩个方法。


__callStatic:当访问不存在的静态方法时,会调用此方法。

call_user_func_array:可以直接用此函数来直接调用函数。

我们就从获取配置文件开始解析


image.png


执行Config::get('facade.');会执行到文件thinkphp/library/think/facade/Config.php中。


在这个文件中就是之前说的,如果存在getFacadeClass方法就会直接返回对应的别名。


如果不存在的话就需要使用bind方法来进行门面绑定。


这里如果不明白就需要去文档好好看看门面那一章节哈!


image.png


在上边类中是不存在get方法的,所以就会直接调用thinkphp/library/think/Facade.php文件中的__callStatic方法。


这个方法就是文章开头就直接说明的,访问不存在的静态的方法时则会调用此方法。


image.png


接着就会执行本类中的createFacade这个方法


在这个方法里边有一行代码是这个样子的$facadeClass = static::getFacadeClass();这段代码会在下文做详细的说明。


因为在子类中也有同样的方法,在本类中也有同样的方法但是在本类中的方法是没有任何返回值的。


这时你有没有一丝丝的困惑,这里使用的static到底会执行哪里的方法。或者这样想,为什么会执行子类的方法。


保留这些疑问将会在下文给你细细的讲来,先来把门面类的源码看完。


在这个方法中主要看我圈起来的几个地方。


第一处就是从子类的getFacadeClass方法获取类的别名。


第二处是当子类没有getFacadeClass方法时,从手动绑定的属性中获取。


第三处就是之前文章提到的容器了,这里就不对这里做详细说明了,如果不会的点开主页去看之前的文章。


image.png


五、static关键字

在这里不得不说明一下static这个关键字。


新学习的伙伴估计只能知道static是用来定义静态变量和静态方法的。


当然这里不会去给大家说怎么定义静态方法和静态变量,而是说一个非常非常小的细节点。


先看一个实例,这个实例也是在阅读门面源码时,咔咔根据门面源码改编过来的。


咔咔这里新建了俩个文件,分别为test和test1。


test继承test1文件,并且都有同样的方法getKaka。


image.png


test的源码


image.png


test1源码

image.png


控制器进行调用

image.png


打印结果

image.png

这个时候有没有一点点疑惑,这里怎么打印出来的是147,而不是456呢!


修改test1的代码,把static改为self

image.png


打印结果

image.png


使用self的代码相信大家都看的明白,那为什么使用static就出现了有可能不太明白的结果呢!


此时就是文档开始起作用了,但是当你打开PHP文档会发现,在static这一篇中并没有对这类情况作出说明。


经过咔咔多次测试和查阅资料,最终总结结果如下。


static::$test 如果有被继承的话 默认调用子类 ,否则调用的是自身


self::$test 如果有被继承的话,默认调用本类


放在本实例中来说明就是,当test继承test1时。


在test1中使用static调用方法getKaka时,默认调用的是test类中的getKaka,也就是子类的方法。


在test1中使用self调用方法getKaka时,默认调用的是test1类中的getKaka,也就是本类的方法。


这个小小的细节也是咔咔无意中发现的,如果有什么不对的地方可以提出来,咔咔作出修改。


因为在继承这方面还有另外一种情况,咔咔私下会进行测试,在这里就不说明了。


这里对这个static做出解释主要是为了解释thinkphp/library/think/Facade.php文件中这个行代码。


因为这行代码调用的方法在子类和父类都存在,所以咔咔为了不让大家出现迷惑就写出来做一个简单的介绍。





相关文章
|
11天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
11天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
11天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
1月前
|
PyTorch Shell API
Ascend Extension for PyTorch的源码解析
本文介绍了Ascend对PyTorch代码的适配过程,包括源码下载、编译步骤及常见问题,详细解析了torch-npu编译后的文件结构和三种实现昇腾NPU算子调用的方式:通过torch的register方式、定义算子方式和API重定向映射方式。这对于开发者理解和使用Ascend平台上的PyTorch具有重要指导意义。
|
12天前
|
安全 搜索推荐 数据挖掘
陪玩系统源码开发流程解析,成品陪玩系统源码的优点
我们自主开发的多客陪玩系统源码,整合了市面上主流陪玩APP功能,支持二次开发。该系统适用于线上游戏陪玩、语音视频聊天、心理咨询等场景,提供用户注册管理、陪玩者资料库、预约匹配、实时通讯、支付结算、安全隐私保护、客户服务及数据分析等功能,打造综合性社交平台。随着互联网技术发展,陪玩系统正成为游戏爱好者的新宠,改变游戏体验并带来新的商业模式。
|
2月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
87 2
|
3月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
87 0
|
3月前
|
算法 Java 容器
Map - HashSet & HashMap 源码解析
Map - HashSet & HashMap 源码解析
68 0
|
3月前
|
存储 Java C++
Collection-PriorityQueue源码解析
Collection-PriorityQueue源码解析
73 0
|
3月前
|
安全 Java 程序员
Collection-Stack&Queue源码解析
Collection-Stack&Queue源码解析
96 0

推荐镜像

更多