facade

使用过larave框架的朋友都知道laravel框架里面除了提供一些基本的功能（如控制器、视图、模型）之外，还有中间件、门面、契约等，这些东西是如何在laravel框架运用起来的呢？今天就和大家详聊一下。 首先应该了解laravel框架的架构模式（ 设计核心 ，laravel 框架是使用服务组件化的开发模式开发的，laravel框架就是由不同的服务组件构成的） laravel 里面多个服务提供者构成了laravel组件。分层设计：把相同功能的类库放在同一个文件夹里面。 laravel框架有多个类组成服务，由多个服务组成组件。类 -> 服务 -> 组件 laravel使用组件化的开发模式，多个类 -> 服务 -> 组件，多个类组成服务，多个服务构成组件。 多个组件提供不同的服务，然后多个服务构成我们的项目。 请求生命周期 大概的流程如图： 理论上，生命周期主要有这么些阶段，但其中，开发者大多数只需关注 路由、中间件、控制器、闭包函数、逻辑处理 等几步 当然，每一步的内部，还是会有更多细化的执行流程，在这里，一般不深入研究框架或改造框架，很少会细化研究，但研究底层，依旧是学习的好选择。 服务 说的就是提供给你所需要的东西，在laravel里面所提供的服务有 认证服务、数据库服务、缓存服务、队列服务等等。laravel框架所有服务都定义在了 app/config/app.php 里面

这是“领域驱动设计实践之路”系列的第四篇文章，从单体架构的弊端引入微服务，结合领域驱动的概念介绍了如何做微服务划分、设计领域模型并展示了整体的微服务化的系统架构设计。结合分层架构、六边形架构和整洁架构的思想，以实际使用场景为背景，展示了一个微服务的程序结构设计。 一、单体架构的弊端 单体结构示例(引用自互联网) 一般在业务发展的初期，整个应用涉及的功能需求较少，相对比较简单，单体架构的应用比较容易部署、测试，横向扩展也比较易实现。 然而，随着需求的不断增加， 越来越多的人加入开发团队，代码库也在飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。 下面分析下单体架构应用存在的一些弊端： 1、复杂性高 在项目初期应该有人可以做到对应用各个功能和实现了如指掌，随着业务需求的增多，各种业务流程错综复杂的揉在一起，整个系统变得庞大且复杂，以至于很少有开发者清楚每一个功能和业务流程细节。 这样会使得新业务的需求评估或者异常问题定位会占用较多的时间，同时也蕴含着未知风险。更糟糕的是，这种极度的复杂性会形成一种恶性循环，每一次更改都会使得系统变得更复杂，更难懂。 2.技术债务多 随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。比如，团队必须长期使用一套相同的技术栈，很难采用新的框架和编程语言。有时候想引入一些新的工具时

golang外观模式 API 为facade 模块的外观接口，大部分代码使用此接口简化对facade类的访问。 facade模块同时暴露了a和b 两个Module 的NewXXX和interface，其它代码如果需要使用细节功能时可以直接调用。 facade.go package facade import “fmt” func NewAPI() API { return &apiImpl{ a: NewAModuleAPI(), b: NewBModuleAPI(), } } //API is facade interface of facade package type API interface { Test() string } //facade implement type apiImpl struct { a AModuleAPI b BModuleAPI } func (a *apiImpl) Test() string { aRet := a.a.TestA() bRet := a.b.TestB() return fmt.Sprintf("%s\n%s", aRet, bRet) } //NewAModuleAPI return new AModuleAPI func NewAModuleAPI() AModuleAPI { return &aModuleImpl

史上最全设计模式导学目录（完整版） 原创 2013年12月24日 23:15:16 标签： 软件工程 / 设计模式 / 博客 / 软件开发 190146 圣诞献礼！ 2012年-2013年，Sunny在CSDN技术博客中陆续发表了100多篇与设计模式学习相关的文章，涵盖了 七个面向对象设计原则和24个设计模式（23个GoF设计模式 + 简单工厂模式） ，为了方便大家学习，现将所有文章的链接进行了整理，希望能给各位带来帮助！ 祝大家 圣诞节快乐 ！ 花絮：本文的工作量大大超过之前的估计，几乎整个平安夜都花在它身上了， 基础知识 设计模式概述 从招式与内功谈起——设计模式概述（一） ：设计模式从何而来？ 从招式与内功谈起——设计模式概述（二） ：设计模式是什么？ 从招式与内功谈起——设计模式概述（三） ：设计模式有什么用？附：个人观点 面向对象设计原则 面向对象设计原则概述 面向对象设计原则之单一职责原则 面向对象设计原则之开闭原则 面向对象设计原则之里氏代换原则 面向对象设计原则之依赖倒转原则 面向对象设计原则之接口隔离原则 面向对象设计原则之合成复用原则 面向对象设计原则之迪米特法则 六个创建型模式 简单工厂模式-Simple Factory Pattern【学习难度：★★☆☆☆，使用频率：★★★☆☆】 工厂三兄弟之简单工厂模式（一） ：图表库的设计 工厂三兄弟之简单工厂模式（二）

控制器获取请求参数 一、新建 Demo 控制器 二、获取参数的方法 一、新建 Demo 控制器 <?php namespace app \ controller ; use app \ BaseController ; class Demo extends BaseController { public function request ( ) { dump ( $this - > request - > param ( ) ) ; } } 浏览器访问： 获取单个参数： $this->request->param('a') ； 默认值： $this->request->param('a',1) ； 转换为整数： $this->request->param('a',1,'intval') ； 二、获取参数的方法 如上提到的 $this->request->param() ;(需继承 BaseController ) 根据请求类型获取，如果是get请求，可以使用： $this->request->get() ，结果同上(需继承 BaseController )； 如果没有继承 BaseController ，可以使用方法依赖注 app\Request 对象 public function request ( Request $request ) { dump ( $request -

△Hollis, 一个对Coding有着独特追求的人△ 这是Hollis的第 315 篇原创分享 作者 l Hollis 来源 l Hollis（ID：hollischuang） 相信很多人对Java中的注解都很熟悉，比如我们经常会用到的一些如@Override、@Autowired、@Service等，这些都是JDK或者诸如Spring这类框架给我们提供的。 在以往的面试过程中，我发现，关于注解的知识很多程序员都仅仅停留在使用的层面上，很少有人知道注解是如何实现的，更别提使用自定义注解来解决实际问题了。 但是其实，我觉得一个好的程序员的标准就是懂得如何优化自己的代码，那在代码优化上面，如何精简代码，去掉重复代码就是一个至关重要的话题，在这个话题领域，自定义注解绝对可以算得上是一个大大的功臣。 所以， 在我看来，会使用自定义注解 ≈ 好的程序员。 那么，本文，就来介绍几个，作者在开发中实际用到的几个例子，向你介绍下如何使用注解来提升你代码的逼格。 基本知识 在Java中，注解分为两种，元注解和自定义注解。 很多人误以为自定义注解就是开发者自己定义的，而其它框架提供的不算，但是其实上面我们提到的那几个注解其实都是自定义注解。 关于"元"这个描述，在编程世界里面有都很多，比如"元注解"、"元数据"、"元类"、"元表"等等，这里的"元"其实都是从meta翻译过来的。 一般我们把

作者 l Hollis 来源 l Hollis（ID：hollischuang） 相信很多人对Java中的注解都很熟悉，比如我们经常会用到的一些如@Override、@Autowired、@Service等，这些都是JDK或者诸如Spring这类框架给我们提供的。 在以往的面试过程中，我发现，关于注解的知识很多程序员都仅仅停留在使用的层面上，很少有人知道注解是如何实现的，更别提使用自定义注解来解决实际问题了。 但是其实，我觉得一个好的程序员的标准就是懂得如何优化自己的代码，那在代码优化上面，如何精简代码，去掉重复代码就是一个至关重要的话题，在这个话题领域，自定义注解绝对可以算得上是一个大大的功臣。 所以， 在我看来，会使用自定义注解 ≈ 好的程序员。 那么，本文，就来介绍几个，作者在开发中实际用到的几个例子，向你介绍下如何使用注解来提升你代码的逼格。 基本知识 在Java中，注解分为两种，元注解和自定义注解。 很多人误以为自定义注解就是开发者自己定义的，而其它框架提供的不算，但是其实上面我们提到的那几个注解其实都是自定义注解。 关于"元"这个描述，在编程世界里面有都很多，比如"元注解"、"元数据"、"元类"、"元表"等等，这里的"元"其实都是从meta翻译过来的。 一般我们把 元注解理解为描述注解的注解，元数据理解为描述数据的数据，元类理解为描述类的类 … 所以，在Java中

前言 Github 是目前全球最大的男性同性交友平台~最近在GitHub上爆火的一份Java核心知识笔记让大家趋之若鹜，我费尽心思拿到整理后只感觉：Java技术可谓博大精深，知识体系非常丰富并且也极其复杂，因此想要学习好Java其实并不是一件非常轻松的事。当然，刚跨入编程行业的小白也无需担心，这份 Java核心知识笔记 你学完一半基本就可以找个非常不错的开发工作了，如果想要高薪，那就默默地全部学完吧！ 目录 内容 本书中的章节大部分是相互独立的。你可以研究自己最感兴趣的主题，并可以按照任意顺序阅读这些章节。 JVM JVM是可运行Java代码的假想计算机 ，包括一套字节码指令集、一组寄存器、一个栈、一个垃圾回收，堆 和 一个存储方法域。JVM 是运行在操作系统之上的，它与硬件没有直接的交互。 Java集合 集合类存放于 Java.util 包中，主要有 3 种：set(集）、list(列表包含 Queue）和 map(映射)。 Java多线程并发 Thread 类本质上是实现了 Runnable 接口的一个实例，代表一个线程的实例。启动线程的唯一方法就是通过 Thread 类的 start()实例方法。 Java基础 如果某个方法不能按照正常的途径完成任务，就可以通过另一种路径退出方法。在这种情况下会抛出一个封装了错误信息的对象。 Spring 原理 它是一个全面的

本文主要描述了门面的使用和实现过程以及源码的深度解析。 @ TOC 前言 使用框架的伙伴应该都知道在5.1时框架新增了一个特性那就是本文将编写的门面，也就是facade这个特性。 使用过这个特性的都明白其中的好处，那就是方法调用可以直接静态进行调用，不用再使用关键字static来定义。 接下来咔咔将会从以下几个方面带着大家探索属于门面的故事。 一、简单认识一下在框架中的门面的好处 在之前有写过配置文件加载一文，在那一文中的最后提到过配置信息获取的几种方式。 其中有一种方式就是Config::get(),到这篇文章应该都知道使用Config获取配置信息时，必须先得引入 use think\facade\Config ，又因为在系统中注册了别名，所以直接使用 use Config 即可。 虽说我们使用的是 use think\facade\Config ，但是实际调用的方法却是 thinkphp/library/think/Facade.php 中的 __callStatic 方法。 然后会执行同文件的 createFacade 方法。 虽说现在还没有看源码，看着知道就好了，在调用 createFacade 方法时是直接从容器类里边获取的。 在学习容器时我们都知道容器是使用了注册树模式，需要使用对应对象实例的时候就可以直接获取，这样就避免了一个类反复的创建。这就是其中的一个优点

设计模式简介 设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。 设计模式的类型 总共有 23 种设计模式。这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns） 创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。 - 工厂模式（Factory Pattern） - 抽象工厂模式（Abstract Factory Pattern） - 单例模式（Singleton Pattern） - 建造者模式（Builder Pattern） - 原型模式（Prototype Pattern） 结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。 - 适配器模式（Adapter Pattern） - 桥接模式（Bridge Pattern） - 过滤器模式（Filter、Criteria Pattern） -