これをphpでやると何が問題になるのでしょうか？

私がこの質問をした理由は、実際にはZhihuでこの回答を読んだためです:

PHP プログラミングでよくある低レベルのエラーは何ですか?

http://www.zhihu.com/question...

言及された間違ったアプローチ:
クラスを名前空間として使用すると、メソッドは単なるクラスの関数になります

これをすることの何が問題ですか?

返信内容:

私がこの質問をした理由は、実際にはZhihuでこの回答を読んだためです:

PHP プログラミングでよくある低レベルのエラーは何ですか?

http://www.zhihu.com/question...

言及された間違ったアプローチ:
クラスを名前空間として使用すると、メソッドは単なるクラスの関数になります

これをすることの何が問題ですか?

手続き型構造化プログラミングの使用は「イデオロギーの固定化」ですか? 私は、「オブジェクト指向」を普遍的な「万能のもの」として扱うことは「八本足のエッセイのようなイデオロギーの固定化」だと考えており、を完全に行うことさえ提案しました。オブジェクト指向 この種の「ワンサイズですべてに対応できる」プログラミング要件は、オブジェクト思考の最大の利点は、関連する関数をカプセル化して他の関数が呼び出すことができることだと思います。クラスを使用しない場合は、複数の関数の接頭辞を変更する必要がある場合があります。そのため、クラスを名前空間として使用することに問題はありません。

PHP 自体について見てみましょう。PHP が提供する関数には、関数ベースのカプセル化とクラスベースのカプセル化の 2 種類があります。関数ベースのカプセル化には、一般的に使用される文字列操作関数や配列操作関数などが含まれます。 SPL ライブラリなどが含まれます。オブジェクト指向は必ずしも手続き型プログラミングよりも高度で便利であるとは思いませんが、本当にオブジェクト指向に興味があるのであれば、すべてのライブラリがベースになっている Java を学ぶべきではないでしょうか。クラスのカプセル化に基づいており、「完全なオブジェクト指向」ですか?

Java マスター Wang ying がオブジェクト指向プログラミングについて考察します:

データ アクセスの方法としての「オブジェクト思考」には、一定の利点があります。 しかし、「オブジェクト指向」（「指向性」という言葉が追加されたもの）は、この本来良いアイデアをとりとめのない、突飛で、過剰に使用したものにすぎません。 多くのオブジェクト指向言語は「すべてはオブジェクトである」と主張し、すべての関数を「メソッド」と呼ばれるいわゆるオブジェクトに入れ、通常の関数を「静的メソッド」と呼びます。 実際、抽象化が必要になることはほとんどなく、オブジェクトに埋め込まれ、データと緊密に統合された「メソッド」を使用する必要があります。 実際には、データ間の変換操作を表現したいだけの場合もあります。これらは通常の関数を使用して表現でき、その方が簡単で直接的です。 すべての関数をオブジェクトに入れることは本末転倒です。関数自体はオブジェクトに属しておらず、オブジェクトに対する単なる変換操作にすぎないからです。 ほとんどの関数はオブジェクトから独立しているため、「メソッド」と呼ぶことはできません。 すべての関数を本来属していないオブジェクトに強制的に入れ、すべてを「メソッド」として扱うと、オブジェクト指向のコード ロジックが過度に複雑になります。 とてもシンプルなアイデアですが、それを明確に表現するには多くの回り道を経なければなりません。

多くの人は、自分たちが使用している「オブジェクト指向言語」の利点の多くが手続き型言語から受け継がれていることをまだ知りません。 ほとんどのオブジェクト指向言語には、ファーストクラスの関数を実装するための正しいメカニズムがありません。 Java 言語は極端で、関数をデータとして渡すことをまったく許可しません。 すべての関数をクラスにカプセル化して「メソッド」と呼ぶ必要がありますが、前述したように、これは誘拐です。 Java に非常に多くの「設計パターン」が存在する主な理由は、第一級の関数が欠如していることです。 一流の機能を手に入れれば、これらのデザイン パターンのほとんどは必要なくなります。

あくまで個人的な意見:

最大の問題は、

プロセスから抜け出すことができず、オブジェクト指向プログラミングで実際に何が変わるのか、インターフェイスはおろか、オブジェクト指向プログラミングの本当の利点は何なのかを理解できないことです。指向性のあるプログラミング。 思想的固化