💆🏼 📟 🏭 「O」なしのOOP 👩🏿‍🚒 🌬️ 👋🏻

この記事で公開されている資料が、あまりにも明白であるか、「信者」の気持ちをin辱する試みではないことを願っています。いずれにせよ、この記事は個人的な経験を共有するための試みであり、あなたの視点を促進するためではありません。

少しの背景：私は保守的な人で、「敵意を持って」すべての変更を受け入れますが、利点が明らかな場合は、熱意を冷やすことで「革新」に慣れようとします。そのため、PHPをマスターする過程でOOPに遭遇しました。最初、私はクラスとオブジェクトの作成を純粋なオーバーヘッドとして（そしてそれが間違いだと言うまでもありませんが）知り合いの過程で、OOPが与えた「構造化」と「秩序」によって宗教的なOOP狂信者になりましたこれ）。

同じ頃、仕事を変えて会社の多機能ポータルが純粋なPHPで（フレームワークを使用せずに）書かれている開発チームに入り、それぞれが可能な限り最高になりました。もちろん、高レベルの開発者はいましたが、既存のコードをリファクタリングする時間はほとんどありませんでした。ほとんどの時間は機能の拡張に費やされました。さらに、構造を変更し、すべてをゼロから書き直すことに疑問の余地はありませんでした。また、「悪いOOP」の例もありました。たとえば、クライアントコード（MVCと類推すると、ある種のコントローラー）には、コードに関係するすべてのオブジェクトが完全に作成されました（オートロードの希望なしに以前含まれていました）。そして最後になりましたが、委任パターンの外観がそれらに適用されました。mysqliオブジェクトが作成され、各オブジェクトのsqlプロパティに割り当てられました。空の不要なアクションの数と、どのような種類のメモリオーバーランが発生するかしか想像できません。

これが私の基本的な例です。

class A{ public function __construct(){ } public function doSomething(){ } public static function someStatic(){ } } class B{ public function __construct(){ } public function doSomething(){ } public static function someStatic(){ } } echo((memory_get_usage()/1024)."Kb"); //: 211.90625Kb

これらの測定値は、「空白ページ」の重みを推定するためのものです。つまり、ここではまだ単一のオブジェクトを作成しておらず、クラスのメソッドを使用していません。

ここで、そのような「役に立たない」オブジェクトを作成し、それらのメソッドを呼び出すために必要なコストを見てみましょう。

 $a=new A; $a->doSomething(); $b=new B; $b->doSomething(); echo((memory_get_usage()/1024)."Kb"); //: 214.15625Kb

ご覧のとおり、違いは目立っていませんが、オブジェクトとメソッドの両方が本質的にまったく何もしないという条件で。ご存知のように、PHPには、このクラスのオブジェクトに属する通常のメソッドやプロパティとは対照的に、クラスに属する静的なメソッドやプロパティがあります。クラスにはそのようなメソッドが含まれています（偶然ですか？-思わない）、それらの機能はこのクラスの通常のメソッドとまったく同じであるため、実際にはクラスを作成せずに同じアクションを実行できます。

 A::someStatic(); B::someStatic(); echo((memory_get_usage()/1024)."Kb"); //: 212.6171875Kb

「超小」数の比較では完全な全体像は得られないかもしれませんが、これはあなたが拒否できるオーバーヘッドです。オブジェクトを作成するのは好きではありませんが、これがこの記事の目的であり、静的なメソッドとプロパティを最大限に使用しようとしています。オブジェクトを操作するのが好きではない理由（別のメソッドに渡すとき）は、それが本人であると主張する人ではないという恐怖症があるためです。もちろん、instanceofを介して特定のクラスに属しているかどうかを確認できますが、予期しないことはありません結果の内容を確認するのは面倒な作業です。構造化クラスシステムの利点を使用して、スクリプトの実行中に必要な構造を組み立てるのは簡単です（さらに理解してください）。手続き型スタイル。しかし、コードに戻ります。

コンストラクター機能の実行の問題が心配な場合、これはselfを介して実装されます。

 class A{ public $prop; public function __construct(){ $this->prop='test'; } public function doSomething(){ } public static function someStatic(){ return new self(); } }

 $a=new A(); echo $a->prop; //test echo((memory_get_usage()/1024)."Kb"); //: 211.9140625Kb

 echo A::someStatic()->prop; //test echo((memory_get_usage()/1024)."Kb"); //: 211.5703125Kb

もちろん、最も丁寧で機知に富んだ人は、次のようなものを提案します（そして正しいでしょう）：

 echo ((new A())->prop); //test echo((memory_get_usage()/1024)."Kb"); //: 211.53125Kb

しかし、これは実行例が誇張されすぎているためであり、そのようなスキームでの実装は、メソッドがこのオブジェクト（$ this）を返す場合にのみ実現できます。

この一連の考え方は、オブジェクトアーキテクチャをOOPで作成する必要がないことを説明するためのものであり、アプリケーションアーキテクチャまたはパターンによって正当化されている場合を除き、メモリを節約することなく（原則として、不要な割り当てなしで）実行できます。あなたがオブジェクトを必要とする場合、極端に-オブジェクトを作成し、時にはそれなしではできません。しかし、何らかのアクションの結果がオブジェクトである場合は、すぐに操作を開始してみませんか？

「O」なしのOOP

More articles: