设计模式PHP具体实现

发表于 2019 年 1 月 24 日 由 ltwen

设计模式主要有几个大类,除了经典的GOF 23个模式以外,还有其它后续出现的很多,主要分为: 结构型、创建型、行为型、其它类 四大类,在这里记录下自己的学习过程

参考文档:

https://designpatternsphp.readthedocs.io/zh_CN/latest/

https://github.com/domnikl/DesignPatternsPHP

https://laravelacademy.org/category/design-patterns

自己的实现记录在 https://github.com/hihaowen/DesignPattern

行为型:
中介者 ok
模版方法 ok
策略 ok
状态 ok
观察者 ok
责任链 ok
命令 ok
迭代器 ok
纪念品 ok
空对象 ok
访问者 ok
解释器 ok
规格模式 ok

结构型:
适配器 ok
桥接 ok
依赖注入 ok
外观 ok
装饰 ok
代理 ok
组合 ok
享元模式 ok
注册模式 ok
流式接口 ok

创建型:
生成器 (建造者) ok
抽象工厂 ok
简单工厂 ok
工厂方法 ok
静态工厂 ok
对象池 ok
原型 ok
单例 ok

其它:
服务定位器 ok

发表在 DesignPattern | 留下评论

DDD quickly 读后感

发表于 2019 年 1 月 24 日 由 ltwen

这两天把《dddquickly》这本书基本读完了,讲一下我自己的一些体会,肯定会有很多疏漏,不过没关系,反正我之前连写读后感的勇气都没有,现在能写也是勇气可嘉.
DDD主要是一种设计思想,它不是像设计模式那样怎样组织代码会更好,而是很像SOLID五大设计原则那样,会知道你这么写代码是不对的,DDD设计的软件会用到设计模式,比如工厂,资源库.当涉及到模块之间通信,防止代码腐败时候,可能还会用到门面等

它的架构分四层:
1、User Interface 用户接口层,这一层对应我们的Controller层,是供调用方调用的
2、Application 这一层是应用层,这一层其实没太懂,我想可能是由于跟我的经历有关,之前都是接触的单体应用有关把
3、Domain 这一层是我们主要关注的领域层,因为其它层建立好了基本不太会轻易变化
4、Infra 这一层是基础服务层,主要给我们提供基础服务,比如日志、Http Client、全局异常的捕获、消息队列等等

DDD是主要围绕问题域来进行产品设计、开发,讲究的是对产品的深度理解,通过对领域知识的不断扩充,再进一步对模型进行改进,这里的模型改进意味着设计、代码都会进行相应的变更,这里有两个重要的角色,一个是开发,另一个是领域专家,领域专家不见得就是产品经历,而是对这个相关业务最了解的人,双方需要通过“通用语言”来进行产品沟通,通用语言是经过双方协商之后,大家都能理解的领域知识

确定了模型、提炼出通用语言之后,就需要对模型进行设计了,这里的设计其实主要是代码层面的,代码设计是对模型的完全映射,模型中需要确定以下几个东西:

1、Entity 实体 有确定身份的唯一标识的东西就是实体,这里的唯一标识可以是一个,比如身份证号码,也可以是多个,比如姓名、门牌号、性别这三个
2、ValueObject 值对象 并不需要唯一标识的东西,比如用户的常用信息: 性别、所在城市等等这些
3、Service 服务 不能用实体或值对象来表示,并且还会有一些行为,而且这些行为都是跟领域相关的,这种情况就叫做服务
4、模块 是对于一个大的领域的细化的拆分 (画外音: 这里其实我也很模糊)
4、聚合根 对于一个领域中很可能会有多个实体、值对象,而对外暴露的只有聚合根、聚合根是对多个实体或值对象的创建过程的封装
5、工厂 是对多个聚合根的封装
6、资源库 它是对工厂生产对象的一个数据封装,而且它还可以有一些策略方面的设置,比如对哪些需求展示哪些数据等

产品上线后要不断的对代码进重构,当然是基于模型的重构,对于需要跟老代码进行通信的需求,需要引入限界上下文 (Bounded Context),这里我没看懂,所以也就不再赘述

发表在 DDD | 留下评论

深入理解OOD

发表于 2019 年 1 月 22 日 由 ltwen

http://www.cnblogs.com/niyw/archive/2011/01/25/1940603.html

发表在 ood | 留下评论

关于依赖注入

发表于 2019 年 1 月 15 日 由 ltwen

https://juejin.im/post/5ae2a019f265da0b736d5f46

发表在 扫盲 | 留下评论

S.O.L.I.D – 面向对象五大设计原则

发表于 2019 年 1 月 15 日 由 ltwen

参考资料:


http://www.cnblogs.com/wuyuegb2312/p/7011708.html#


https://zh.wikipedia.org/wiki/SOLID_(%E9%9D%A2%E5%90%91%E5%AF%B9%E8%B1%A1%E8%AE%BE%E8%AE%A1)



SRP   The Single Responsibility Principle 单一责任原则
      
      一个类只能负责一个功能



OCP   The Open Closed Principle 开放封闭原则
     
      对扩展开放、对修改关闭       



LSP   The Liskov Substitution Principle    里氏替换原则
     
      派生类(子类)应当可以替换其基类(超类 或者叫父类)中的方法,但是不应该改变程序方法的原有的定义 
      csdn
      wiki



ISP   The Interface Segregation Principle    接口分离原则

      多个接口要优于单个宽接口



DIP   The Dependency Inversion Principle    依赖倒置原则

      对象之间的引用应该引用抽象(接口),不应该依赖具体实现
发表在 扫盲 | 留下评论

.gitignore不起作用

发表于 2019 年 1 月 8 日 由 ltwen

gitignore只能忽略那些原来没有被 track 的文件，如果某些文件已经被纳入了版本管理中，则修改 .gitignore 是无效的

所以这些文件需要 git rm –cached logs/xx.log,再push就可以了

发表在 git | 留下评论

二分查找

发表于 2018 年 12 月 21 日 由 ltwen 
 $high) return false;

    $mid = floor($low + ($high - $low) / 2);

    if ($search[$mid] == $find) {
        return $mid;
    } elseif ($search[$mid] > $find) {
        return binarySearch($search, $find, $low, $mid - 1);
    } else {
        return binarySearch($search, $find, $mid + 1, $high); }

    return false;
}

function binarySearchWithWhile(array $search, int $find)
{
    $low = 0;
    $high = count($search);

    $key = false;

    while ($low <= $high) {
        $mid = floor($low + ($high - $low) / 2);

        if ($search[$mid] == $find) {
            $key = $mid;
            break;
        } elseif ($search[$md] > $find) {
            $high = $mid - 1;
        } else {
            $low = $mid + 1;
        }
    }

    return $key;
}
发表在 algorithm | 留下评论

yapi部署

发表于 2018 年 12 月 19 日 由 ltwen

npm方式安装:

https://blog.csdn.net/u012375924/article/details/84771472

docker方式安装:

https://www.jianshu.com/p/a97d2efb23c5

发表在 产品 | 留下评论

InnoDB索引组织表的原理 (参考)

发表于 2018 年 12 月 5 日 由 ltwen

http://www.cnblogs.com/leefreeman/p/8315844.html

http://hedengcheng.com/?cat=6

发表在 mysql | 留下评论

面向对象设计原则

发表于 2018 年 11 月 8 日 由 ltwen

总原则：开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。

1、单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。

2、里氏替换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科

历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。

3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。

4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。

5、迪米特法则（最少知道原则）（Demeter Principle）
就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。

6、合成复用原则（Composite Reuse Principle）
原则是尽量首先使用合成/聚合的方式，而不是使用继承。

发表在 DesignPattern | 留下评论