Compréhension approfondie des mots-clés statiques et de rendement en php

Cet article vous présente principalement les informations pertinentes sur les mots-clés statiques et de rendement en PHP. L'article les présente en détail à travers des exemples de codes. Il a une certaine valeur d'apprentissage de référence pour que tous les amis qui en ont besoin apprennent ou utilisent PHP. article Apprenons avec l'éditeur ci-dessous.

Avant-propos

Cet article présente principalement le contenu pertinent sur les mots-clés statiques et de rendement en PHP, et le partage pour votre référence et votre étude. Pas grand chose à dire ci-dessous, jetons un œil à l'introduction détaillée.

Parlons d'abord du mot-clé statique. Cet article ne parle que de l'utilisation de méthodes statiques et de la liaison tardive.

static Quand est-il utilisé pour modifier des méthodes ?

le mot-clé static est connu pour être utilisé pour modifier des méthodes et des attributs. Alors dans quels scénarios l’utilisez-vous dans vos projets ?

J'ai rencontré plusieurs projets qui nécessitent que toutes les méthodes soient statiques. Bien sûr, les méthodes du contrôleur ne peuvent pas le faire. L'une des raisons est la suivante : l'efficacité de l'exécution des méthodes statiques est élevée ? Alors analysons-le sur cette base.

Tout d’abord, je n’ai aucune objection à la haute efficacité d’exécution. Est-ce parce qu’il est très efficace qu’il faut l’utiliser sans retenue dans les projets ? Pour discuter de cette question, passons d’abord en revue l’histoire des langages de programmation. Au début, il n'y avait pas de programmation orientée objet et la programmation structurée était utilisée. À cette époque, toutes les méthodes étaient essentiellement des méthodes statiques. Puis l'orientation objet est apparue et le concept d'instanciation est apparu.

Comme le montre le bref processus de développement ci-dessus, s'il s'agit uniquement de performances, il ne semble pas y avoir besoin d'une existence orientée objet. Alors, que pensent ces maîtres de l'introduction de l'orientation objet et de l'instanciation dans des langages tels que C++ et Java ? Je pense que c'est parce qu'avec le développement, les projets deviennent de plus en plus grands, nécessitant une meilleure organisation du code et une meilleure réflexion sur la programmation.

En regardant statique, la méthode statique qu'elle définit est vraiment efficace, mais elle continuera à occuper de la mémoire. Le cycle de vie ne se terminera qu'à la fin du programme, et l'un des effets secondaires est qu'il ne peut pas l'être. détruit au cours de la période ; Deuxièmement, du point de vue du mode de conception, il a un couplage fort et les attributs statiques peuvent être modifiés de l'extérieur ; Troisièmement, il n'y a aucun moyen de remplacer la méthode définie par static, et des concepts tels que ioc di sont ; inutile ; quatrièmement, lors de l'exécution de tests unitaires, les méthodes statiques donnent mal à la tête aux gens.

Donc, sur la base de ce qui précède, j'ai l'impression que nous devrions cesser d'utiliser des méthodes statiques à l'avenir et simplement instancier et appeler les méthodes honnêtement ? Nous devons être rationnels, et nous ne pouvons pas être extrémistes au point de l’utiliser partout, ni même de l’utiliser du tout. Conclusion : apprenez à penser de manière orientée objet. Je pense que la première considération lorsque nous écrivons du code est : l'évolutivité (pour faire face aux changements rapides de l'entreprise) et la maintenabilité (pour réparer les problèmes en ligne en temps opportun). La haute efficacité doit être considérée en dernier lieu (car il existe de nombreuses façons d’optimiser l’efficacité, il n’est pas nécessaire d’ajouter : statique à chaque méthode). Si d'un point de vue orienté objet, cette méthode est complètement indépendante et n'a rien à voir avec les attributs de classe, alors utilisez static.

En bref, nous envisageons l'utilisation de la syntaxe dans une perspective orientée objet et au niveau de la conception logicielle, plutôt que de détruire la beauté du code dans un souci d'efficacité.

liaison statique tardive

Ceci est décrit en détail dans la documentation PHP, mais j'y ai rarement prêté attention auparavant . Cet endroit utilise essentiellement self:: pour appeler des méthodes et des propriétés statiques.

Je pense que la liaison tardive est, dans une certaine mesure, comme une surcharge de méthodes statiques. Voici un exemple tiré du document php pour le décrire :

<?php
class A {
 public static function who() {
 echo __CLASS__;
 }
 public static function test() {
 self::who();
 static::who();// 后期静态绑定
 }
}

class B extends A {
 public static function who() {
 echo __CLASS__;
 }
}

B::test();

S'il est appelé par self::who() , il affichera : A. Si c'est static::who(), il affichera B

De ce point de vue, est-ce équivalent à la classe B remplaçant la méthode who() de la classe parent A ? Ainsi, si vous utilisez cette fonctionnalité de manière flexible, vous pouvez rendre la statique plus flexible. Tirez pleinement parti de ses avantages en termes de performances et résolvez le problème de la mauvaise évolutivité. Bien sûr, c'est toujours pareil. D'un point de vue orienté objet, tout est fait avec modération.

Scénarios d'utilisation de rendement en PHP

Pour être honnête, pendant longtemps je ne savais pas que PHP avait un tel une syntaxe. Jusqu'au jour où j'ai rencontré ce mot-clé dans js. J'ai senti que c'était une chose tellement peu claire. Pourquoi n'est-il pas disponible dans la meilleure langue du monde ? En regardant la documentation, je constate que c'est effectivement le meilleur langage au monde.

Alors, quels sont les scénarios d’utilisation du rendement ? Quelqu'un sur SG m'a récemment demandé de régler ce problème. J'espère que vous pourrez l'utiliser davantage en conjonction avec votre propre entreprise. Il n'y a pas de comparaison entre le rendement et l'itérateur. Je crois qu'après l'avoir lu, vous pourrez comprendre lequel des deux est le plus bref.

先说它的使用场景，还是得先回顾历史，在没有 yield 之前，我们要生成一个数组，只能一次性把所有内容全部读入内存（当然也可以通过实现 Iterator接口实现一个迭代）。有了 yield 之后，我们可以通过一个简单的 yield 关键字，完成一个数组的生成，并且是用到的时候才会产生值，相对而言内存占用肯定会下降。空口无凭，咱们下面通过代码实际检验一下上面的结论。

先来看普通模式

<?php

function generateData($max)
{
 $arr = [];
 for ($i = 0; $i <= $max; $i++) {
 $arr[] = $i;
 }
}

echo &#39;开始前内存占用：&#39; . memory_get_usage() . PHP_EOL;
$data = generateData(100000);
echo &#39;生成完数组后内存占用：&#39; . memory_get_usage() . PHP_EOL;
unset($data);
echo &#39;释放后的内存占用：&#39; . memory_get_usage() . PHP_EOL;

运行得到结果：

开始前内存占用：231528
生成完数组后内存占用：231712
释放后的内存占用：231576

前后的差值是：184

使用yield后的效果

function generateData($max)
{
 for ($i = 0; $i <= $max; $i++) {
 yield $i;
 }
}

echo &#39;开始前内存占用：&#39; . memory_get_usage() . PHP_EOL;
$data = generateData(100000);// 这里实际上得到的是一个迭代器
echo &#39;生成完数组后内存占用：&#39; . memory_get_usage() . PHP_EOL;
unset($data);
echo &#39;释放后的内存占用：&#39; . memory_get_usage() . PHP_EOL;

运行结果：

开始前内存占用：228968
生成完数组后内存占用：229824
释放后的内存占用：229016

前后的差值是：856

奇怪，使用了 yield 后，内存占用反而上升了，这是什么鬼？别急。上面我们参数传入的是 1,000,00，我现在将传入参数改成改成 1,000,000试试。

第一个方法得到的结果是：

开始前内存占用：231528

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /test/yield.php on line 6

看了吧，一百万次的循环时，一次性载入内存，超出了限制。那么再来看 yield 的执行结果:

开始前内存占用：228968
生成完数组后内存占用：229824
释放后的内存占用：229016

前后的差值依然是：856

好了到这里，应该看出来了，yield无论数组大小，占用均是 856 ，这是因为它自身，它在你进行迭代的时候才会产生真实数据。

所以如果你的数据来源非常大，那么用 yield 吧。如果数据来源很小，当然选择一次载入内存。

总结

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!