记录－交流－Web开发知识分享
在 MozillaWiki 中推荐了三种配置，分别是现代兼容性、中级兼容性（默认）和旧的向后兼容性。
现代兼容性
对于不需要向后兼容性的服务，以下参数提供更高级别的安全性。 此配置与 Windows 7，Edge，Opera 17，Safari 9，Android 5.0 和 Java 8 上的 Firefox 27，Chrome 30，IE 11 兼容。
|
1
2 |
大学有一门课程《软件工程》，研究如何组织和管理软件项目。
说实话，这门课不适合本科生，因为学生可能体会不到，课程到底要解决什么问题。只有亲身参与过大项目的开发，经历过大团队，才能感受为什么软件工程很重要，又很难做对。…
如果你在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 …
近期评论