この記事の枠組みの中で、OOPが何であるかを思い出すと思います。それは余分なものなので、私は問題に直行します。
他のプログラミング言語からPHPにアクセスし、PHPのクラス（ここおよび以下ではPHPと呼びます）に遭遇する開発者は、その使用方法にまったく困惑します。 そして、すべてPHPでのスクリプトの寿命はアプリケーションソフトウェアの寿命よりもはるかに短く、1つの作業サイクルのみを構成するという事実に起因します。 その結果、世界は、PHPに存在しない名前空間のみをクラスが実装するコードです。
class A {
public static function b() {}
public static function c() {}
public static function d() {}
}
はい-このアプローチでも多くの利点があります。 たとえば、1つのデータ領域に属する関数をラッパークラスに分離することができました。これにより、コード内の関数名の競合の可能性が減り、コードの可読性と関数の動作の追跡がより透明になります。
User::register($name, $pwd);
//... a lot of code ...
System::Log($message, $code);
この例の各行はそれ自体を表しており、追加のコメントを必要としません。これは間違いなくプラスです。
しかし、OOPは、継承、カプセル化、ポリモーフィズムという基本的な機能が既に退屈しているプログラミングパラダイムとしてだけでなく、私たちを取り巻く世界として見てみましょう。 オブジェクトは何を教えてくれますか？ 私の眼鏡を例に取ります。 それらについて何が言えますか？ それらの重量とサイズ、色、密度を測定することができます-これらはクラス\ "メガネ\"のプロパティになりますが、これによりレンズを通過する光を破壊して屈折させることができます-これらはすでにメソッドです。 メガネの速度を測定するように、メガネからお茶を飲むことはできません。 これは何の話ですか？ クラス\ "メガネ\"には、相互作用の特定の範囲と機会があります。 PHPのクラスでも同じことができます。
スクリプトのライフサイクルは1つだけですが、美しく生きることができます！ これをしようとします...
私たちがソーシャルネットワークを持っていると想像してください（まあ、今日は彼らなしでどうですか？:)）; このソーシャルネットワークにはユーザーがおり、各ユーザーは自分のブログを持っています。 そして、提示された各エンティティのスコープを簡潔かつエレガントに表示してみましょう。
ユーザーには一連のプロパティがあります。 ログイン、パスワード、および電子メール。 ユーザーは、ログイン、ログアウト、ブログの作成、書き込みなどのアクションを実行できます。
ブログには、作成者、トピックコレクション、作成日というプロパティがあります。 ブログは自分自身に投稿を追加できます。
エンティティのメソッドとプロパティのこのセットに制限されています。 このような構造をコードで想像する最もエレガントな方法は何ですか？ 次のオプションをお勧めします。
class Blog {
public $topics_list;
public $creation_date;
private $data; // ,
public function __construct($id) { //id
//- $this->data,
}
public function getAuthor() {
static $author; // , , , -
if (empty($author)) {
$author = new User($this->data[\'author_id\']);
}
return $author;
}
public function addTopic(Topic $topic) { ... } // .
}
class User { ... } // , ,
だから-私たちは何を達成しましたか？ この方法で両方のクラスを作成した結果、各オブジェクトの責任範囲が明確になり、さらに、不必要なパラメーターを渡すことを避けられます。 たとえば、説明されているレイアウトに基づいて、ブログエントリ\ "昔ながらの方法\"を作成します。
昔ながらの方法で：
$user_id = $_SESSION[\'user_id\']; // id
$topic_message = \" \";
Blog::addTopic($user_id, $topic_message); //
ひとつのことを除いて、すべてが明確で自然なようです-トピックを作成するために引数を渡すと、ユーザーの役割は明確になりません。 新しいアプローチで同じコードがどのように見えるか見てみましょう：
$user = new User($_SESSION[\'user_id\']);
$topic_message = \" \";
$user->getBlog()->addTopic($topic_message);
ここでは、ブログとユーザーの関係がはるかに明白です...そして、トピックもオブジェクトであり、プロパティ\ "メッセージ\"を持っていると考える場合、次のようになります。
$user = new User($_SESSION[\'user_id\']);
echo $user->getBlog()->getTopics()->topic[$topic_id]->message;
このような短い例では、利点はそれほど明白ではないかもしれませんが、コードが数百、または数千のエンティティの相互作用システムに成長すると、それらのそれぞれのロジックはより透明で明白になり、サポートの容易さ、拡張性、および可読性に影響します。 このような短いスクリプトの寿命であっても...
質問を読んだ後、私はそれらに答えてうれしいです。
PS Habrのトピックでコードのセクションを描画する方法を教えてください。しかし、どういうわけかそれを読むことができませんでした:(