php 设计模式--准备篇

要了解设计模式 首先我们要先了解 php的命名空间和类的自动载入的功能

下面我们来说一下

命名空间

概念缘由:比如一个a.php的文章 但是我们需要两个 此时同一个目录下不可能存在两个a.php 那么我们可以放到my/home 和 my/home1的目录下 此时命名空间就有了它的意义

那么空间即为my/home/a.php

namespace my\name;

demo

<?php
//file a.php
namespace my/home;
const test = ’Atest’;
function test() {
  return __FUNCTION__;
}
class Test{
  public function __construct(){
    return __METHOD__;
  }
}
?>

  那么下面就是自动加载的问题了

原本最为简单的自动加载是

function __autoload($class) {
  $dir = ’./’;
  set_include_path(get_include_path().PATH_SEPARATOR.$ids_dir);
  $class = str_replace(’\’, ’/’, $class) . ’.php’;
  require_once($class); }

  但是用__autoload()这种方法已经out了

现在我们用的更多的是spl_autoload_register(优势)

面试可能设计到

对比:

1。spl_autoload_register可以进行多次的写注册加载函数,谁先注册谁就先调用,但是_autoload()只能调用一次

2.spl_autoload_register可以catch错误

3.既然可以注册那么我们也可以用spl_autoload_unregister()解除注册。

通过上面的学习我们可以进行一个psr的架构处理了

psr概念:

1、PSR-0规范

[1]命名空间必须与绝对路径一致

[2]类名首字母必须大写

[3]除去入口文件外,其他“.php”必须只有一个类

[4]php类文件必须自动载入,不采用include等

[5]单一入口

2、案例

[1]目录结构

[2]源码

index.php

<?php
define(‘BASEDIE‘,__DIR___);
require_once(‘/Config/Loader.php‘);
spl_autoload(‘\\Config\\Loader.php::autoload‘);
Config\Object::test();
App\Home\Index::test();

Config/Object.php

<?php
namespace Config;

class Object{
    static function test(){
        echo "nihao";
    }
}

Config/Loader.php

<?php
namespace Config;

class Loader{
    static function   autoload($class)
    {
        require_once(BASEDIE.‘/Config/‘.str_replace(‘\\‘,‘/‘,$class).‘.php‘);
    }
}

App/Home/Index.php

<?php
namespace App\Home;

class Index{
    static  function test(){
        echo "ceshixinxi";
    }
}
时间: 2024-11-05 00:59:09

php 设计模式--准备篇的相关文章

设计模式总结篇系列:策略模式(Strategy)

前面的博文中分别介绍了Java设计模式中的创建型模式和结构型模式.从本文开始,将分别介绍设计模式中的第三大类,行为型模式.首先我们了解下分为此三大类的依据. 创建型模式:主要侧重于对象的创建过程: 结构型模式:主要侧重于处理类或对象的组合: 行为型模式:主要侧重于类或对象之间的交互以及职责分配. 首先了解下策略模式的概念:定义了多个算法,并将它们封装起来(一般的是每个算法封装成一个单独的类),让算法独立于客户端而可以单独变化. 具体可以看一下下面的例子(以计算加.减.乘为例): 1. 对加.减.

设计模式总结篇系列:外观模式(Facade)

张三自从毕业后开始做软件开发,做着做着发现不爽了,钱赚不了太多,头发也白了.于是拿着一点小资本,想着做点小生意.瞅着眼前的餐饮行业还不错,于是打算开一家餐馆.开参观可不是一件容易的事,仅仅行政类的审批流程就不少.至少包括办理卫生许可证,办理税务登记,办理工商登记等. 我们先来看一下行政审批接口: 1 interface Executive{ 2 3 public void approve(); 4 5 } 卫生局类的定义: 1 class HealthOffice implements Exec

设计模式总结篇系列:代理模式(Proxy)

时代在发展,我们发现,现在不少明星都开始进行微访谈之类的,有越来越多的参与捐赠等.新的一天开始了,首先看下新的一天的日程安排: 1 interface Schedule{ 2 3 public void weiTalk(); 4 5 public void donation(); 6 7 } Schedule接口定义了今天的形成安排,主要包括微访谈和捐款.那么看一下实现此接口的明星类定义: 1 class Star implements Schedule { 2 3 @Override 4 pu

设计模式总结篇系列:组合模式(Composite)

在探讨Java组合模式之前,先要明白几个概念的区别:继承.组合和聚合. 继承是is-a的关系.组合和聚合有点像,有些书上没有作区分,都称之为has-a,有些书上对其进行了较为严格区分,组合是contains-a关系,聚合是has-a关系. 组合方式中被组合的对象生命周期不能超过整体,一般写代码时是直接在整体类的构造方法中创建被组合类的对象.如人和手之间的关系,人都没了,还何来手? 聚合方式中对于对象的生命周期则没有此类限制,一般可以在聚合类的构造函数中通过外部传参以赋值给整体(或通过其他set等

设计模式总结篇系列:桥接模式(Bridge)

在实际类设计过程中,有时会遇到此类情况:由于实际的需要,某个类具有两个或两个以上的维度变化,如果利用继承将每种可能的变化情况都定义成一个类,一是会导致类膨胀的问题,二是以后不太好维护和并且违背类的设计原则.那么面对这种情况,类改如何设计呢?这就是本文所要讲到的桥接模式. 简单的讲,桥接模式是指:将抽象和行为划分开来,从而将各个可能变化的维度分离开来,各自独立成一个类,但是能够动态的组合. 貌似有点抽象,下面通过一个简单的例子来理解桥接模式. 我们可以通过Email发送信息,也可以手段短信发送信息

设计模式总结篇系列:建造者模式(Builder)

关于建造者模式网上有很多文章,也有些不同的理解.在此结合网上其他文章对建造者模式进行总结. 总体说来,建造者模式适合于一个具有较多的零件(属性)的产品(对象)的创建过程.根据产品创建过程中零件的构造是否具有一致的先后顺序,可以将其分为如下两种形式. 一.通过Client.Director.Builder和Product形成的建造者模式 Builder负责Product类对象的具体过程构建,Director负责指导Build,要求Builder按照其指定的顺序去完成Produt的构造.最后通过Bu

设计模式总结篇系列:工厂方法模式(Factory Method)

工厂方法模式适合于对实现了同一接口或继承了同一父类的一些类进行实例的创建.一般是通过定义一个工厂类,并在其方法中实现对具有上述特点的类对象的创建. 根据具体产生类对象的方法定义形式,又可以将其分为普通工厂方法模式.多个工厂方法模式和静态工厂方法模式. 一.普通工厂方法模式: 常见的经典写法如下(以发送邮件和短信为例): 1.定义邮件类和短信类具有的共同接口: 1 interface Sender{ 2 3 public void sender(); 4 5 } 2.定义邮件类和短信类: 1 cl

设计模式总结篇系列:单例模式(SingleTon)

在Java设计模式中,单例模式相对来说算是比较简单的一种构建模式.适用的场景在于:对于定义的一个类,在整个应用程序执行期间只有唯一的一个实例对象.如Android中常见的Application对象. 通过单例模式,自行实例化并向这个系统提供这个单一实例的访问方法. 根据此单一实例产生的时机不同(当然,都是指第一次,也是唯一一次产生此单一实例时),可以将其分为懒汉式.饿汉式和登记式. 一.懒汉式: 其特点是延迟加载,即当需要用到此单一实例的时候,才去初始化此单一实例.常见经典的写法如下: 1 pa

设计模式总结篇系列:适配器模式(Adapter)

网上看到不少关于适配器模式的讲解,其中对于适配器模式解释的过于专业,一时不是特别理解适配器模式到底是用来干嘛的,具体的适用场景在哪,其最精髓的地方到底在哪. 本文结合自己的理解,阐述下对适配器模式的看法. 假设系统存在一个现有的类UserInfo: 1 class UserInfo { 2 3 private Map<String, String> userBaseInfo; 4 5 public Map getUserBaseInfo() { 6 return userBaseInfo; 7

从真实项目中抠出来的设计模式——第二篇:过滤器模式

一:实际场景介绍 我们在给用户做订单催付通知的时候,会有这样的一种场景,用户在系统后台设置一组可以催付的规则,比如说订单金额大于xx元,非黑名单用户,来自 哪个地区,已购买过某个商品,指定某个营销活动的人等等这样的条件,如果这时用户在淘宝上下了一个订单,那程序要判断的就是看一下此订单是否满足这 些规则中的某一个,如果满足,我们给他发送催付通知,这种场景是很多做CRM的同学都会遇到的问题,那针对这种场景,如何更好的规划业务逻辑呢? 二:普通的编程代码 在这里我们就不考虑多筛选条件下的性能,而只从代