记录－交流－Web开发知识分享
如果你在header或cookie函数前发送大量字符到浏览器，就会报headers already sent 错误，以下为说明：
此函数告诉我们发送header的状态。如果将输出发送到浏览器，则不应使用重定向等header函数。为避免此类错误，我们可以使用headers_sent()函数检查header发送状态。它根据标头的状态返回TRUE或FALSE。当我们执行一个php脚本时，将输出存储到缓冲区中，然后再将其发送到浏览器。但是，这还取决于您的服务器php.ini设置，其中必须打开或关闭输出缓冲区。…
现代PHP很快！它具有多项性能功能，例如OPCache，JIT和其他编译阶段的改进，可针对许多PHP应用程序进行智能优化。
检查OPCode是确保PHP可以进行最佳优化的简便方法。使用列出的OPCode，可以更清楚地了解给定的PHP代码段是否采用了执行预期任务所需的最短数量的OPCode。
目前，PHP有30多个这样的函数，它们使用特殊的OPCode或内联以提高性能。
展示这种效果的一个例子是 strlen函数。它返回给定字符串的长度，PHP尝试抢先优化。
if (strlen('Test') < 2) {
echo "Test";
}在此代码段中，该strlen函数在静态字符串文字上调用，并且PHP可以完全消除此块，因为Test字符串的长度是固定的，并且比较值也是静态值。
使用OPCode dump可以更好地揭示这一点。
优化之前
php 基本信息
4.2 面向对象设计7大原则
设计实现一个系统时，我们一般先按功能划分好模块，以模块中核心类为起点，根据功能逐步向周边延展设计其它类。
设计模式在这个过程中可以帮助我们进行高质量的代码设计。但是模式是有限的，这些优秀的设计模式背后有没有什么通用的指导原则呢？
依赖倒置原则：面向接口编程，不要针对实现编程。实现意味着应对变化的能力下降，尽量延迟到调用时再具体化。
开闭原则：对扩展开放，对修改关闭。比较好理解，扩展新增引入的风险相对修改更可控一些。修改往往意味着，系统扩展性不够。
里氏替换原则：继承父类的目的是为了复用。高质量的继承关系，是衍生类可以完全替换掉基类，并且系统的行为不受到影响。如果子类不能完全替换父类，说明继承是不彻底的，复用的目的就没有达到。
单一职责原则：一个类应该只承担一个职责。承担的职责过多，职责之间可能会相互耦合。这里最难的就是划分职责，职责必须恰如其分地表现实体的行为。比如用户账号可以修改基础信息，会员可以持有会员卡。如果不加以区分，只抽象一个用户实体包括所有的行为，显然是不合适的。
接口隔离原则：适度细化接口，接口的行为尽量少。分治的思想，降低复杂性，系统更可控。
迪米特法则：一个类对依赖的类知道的越少越好。本质目的是将复杂度控制在一定范围内。
组合/聚合复用原则：复用即可以通过继承实现，也可以通过组合 / 聚合实现。区别在于，继承表达 is-a的逻辑关联，目的在描述结构，而不是复用。
------
面向对象设计七大原则：“开闭原则”是总纲，告诉我们要“对扩展开放，对修改封闭”；“里氏替换原则”告诉我们“不要破坏继承体系”；“依赖倒置原则”告诉我们要“面向接口编程”；“单一职责原则”告诉我们实现类要“职责单一”；“接口隔离原则”告诉我们在设计接口时要“精简单一”；“迪米特法则”告诉我们要“降低耦合度”；“合成复用原则”告诉我们要“优先使用组合或者聚合关系复用，少用继承关系复用”
---------
开闭原则：对拓展开放，对修改关闭。
里氏替换原则：不该破坏类的继承体系，不应该复写父类的方法，子类可以拓展父类功能，但不能改变父类原有的功能。
依赖倒置原则：面向接口编程，而不是面向实现编程。
单一职责原则：尽量保持实现类的职责单一。
接口隔离原则：设计接口的时候要精简单一。
迪米特法则：降低耦合度，只和你的朋友交流。
合成复用原则：优先使用组合聚合关系，代替继承关系。
开闭原则实现途径：
里氏替换原则
依赖倒置原则
高内聚低耦合：
单一职责原则
接口隔离原则
迪米特法则
合成复用原则
面向对象编程时有以下几个选择：
1，多用组合，少用继承
2，针对接口编程，不针对实现编程
3，为交互对象之间的松耦合设计而努力
4，类应该对扩展开放，对修改关闭
5，依赖抽象，不要依赖具体类
作者：吕浩
部门：有赞美业
…提到设计模式，有一个非常有意思的现象： 理论学习中，几乎所有的开发人员都认为它非常有用很重要。 工作实践中，绝大部分开发人员在项目中找不到合适的应用场景。 设计模式学了一遍又一遍，却毫无用武之地。大概设计模式最好的归宿，就是存在程序员的深深的脑海里。
| 修改记录 | 修改时间 | 备注 |
|---|---|---|
| 新建 | 2021.02.09 | 整理自极客时间-王争的设计模式之美(推荐购买学习) |
理解：不要设计大而全的类，要设计粒度小、高性能单一的类。该原则的目的是为了实现代码高内聚、低耦合、提高代码复用性、可读性以及可维护性。
补充：在保证单一职责时，要避免过分拆分，否则会降低内聚性，影响代码可维护性。
/**
* 如果下面的用户信息类仅在一个场景中使用，则没有什么问题；
* 如果后面用户的地址信息在其他模块中使用时，就可以将地址信息进行拆分。
* 以及各个属性的操作方法都要进行聚合到一个类中，提高代码的维护性。
*/
dataThe Liskov substitution principle is the L in the well known SOLID acronym. The original principle definition is:
Methods that use references to base classes must be able to use objects of derived classes without knowing it.
At first glance …
As many, I started programming when I was a child 3 decades years ago. With no doubt, the most important practice I’ve adopted during my professional career is to write automatic tests. Not only there are plenty of short/mid/long terms …
As an architect, you know that programming to an interface is good. It’s what everyone should do.
But what does that mean? And why should you do it?
Searching the Internet for answers might only cause more confusion. There, you’ll …
近期评论