OOPの思想と設計

OOP - オブジェクト指向プログラミング。 OOP思考とはオブジェクト指向の考え方そのものを指します。 OOP 設計は、すべてのコードをクラスにカプセル化することを意味するものではありません。なぜなら、もしそうなら、それはオブジェクト指向プログラミングのみを指しているからです。

OOP - オブジェクト指向プログラミングは単なる練習です。 OOP の考え方は基本です。重要なのはアプローチではなく、達成すべき実際の目標です。 Java 言語は常にオブジェクト指向の目標を達成できます。理由は非常に簡単です。それは言語自体の制限によるものです。

JAVA のすべてはクラス内にある必要があります。クラス外のスタンドアロン関数は許可されません。デザインパターンはJAVAの出現によってのみ存在します。この観点から、JAVA はソフトウェア界の考え方を変えました。

OOP の目標は、コードを SOLID 原則に準拠させることです。これらの原則は、デザイン パターンに関する本の冒頭で紹介されています。

しかし、これは理論上の目標です。実際の目標は、なぜ私たちがそのようなことをしているのかに答えることです。未来は常に分からないからです。需要がどのように変化するかはわかりません。本日は期間限定で簡易バージョンのみを提供できる可能性があります。しかし、将来的には確実に拡大していくでしょう。私たちが行ったことで今日はすべてがカバーされたかもしれませんが、いつか、まだ考慮されていない要素が 1 つあることに気づくでしょう。

オブジェクト指向のアプローチがない場合は、最も単純な switch case 構造で完成させています。このため、コアコードを作り直す必要がありました。ただし、コードが SOLID 原則に準拠している場合は、既存のコードに新しい CLASS を追加するだけで済みます。

見つけるのは難しくありません。プラグインのアイデアは OOP から生まれました。したがって、現時点で OOP に注目すると、散在するコードをクラスにカプセル化するだけの問題ではありません。

私たちはSOLOD原則に従い、何が抽象的で何が具体的であるかを明確にする必要があります。限られた問題固有のコードのみを提供しますが、それらはすべて全体的な抽象化に依存しています。同じタイプの新しい特定の問題がある場合は、クラスを追加するだけで済みます。これがデザインパターンの考え方の核心です。

OOP デザインはそれとは程遠いです。コードの可読性と保守性は、ディレクトリとドキュメントにも依存します。表面的には、これは重要な詳細ではありません。しかし、現実は非常に重要です。特に、特定の問題に対するコア モジュールの設計、または PHP 開発フレームワークの設計。ディレクトリの読みやすさ、またはディレクトリが OOP に準拠しているかどうかによって、人々がどれだけ早くそれを理解し、どれだけ喜んで受け入れられるかが決まります。たとえば、SYSMFONY のディレクトリ構造はあまり良くありません。古いブランドですが、初期には大きな市場を占めていました。しかし、市場は依然としていくつかの新しい枠組みによって分断されています。振り返ってみると、KOHANA などのコードはあまりよく設計されていませんでしたが、CI は非常に受け入れられやすく、ディレクトリ構造も関係していました。これは、一部の国内フレームワークがユーザーに受け入れられる理由でもあります。中国版だからというだけではありません。

OOP デザインの考え方は、コードの観点だけではなく、アーキテクチャとデザインのあらゆる側面にあることがわかります。 PHP フレームワークの問題の主な原因は、大規模なプロジェクトを実際に経験したことのない人々がアーキテクトとして十分な経験を持っているオープンソース システムであることにあります。これはかなり許されます。しかし、企業がオープンソースを行う場合、何年も運用し続けるとシステムは大規模化、複雑化するため、使いやすく保守しやすい明確なアーキテクチャを持たないと悲惨なことになります。

これらの企業はこれを利用して、二次開発が必要な顧客のためにお金を稼ぐことができると言う人もいます。実際、この種のお金を稼ぐことには常に限界があります。なぜなら、優れたコア アーキテクチャが真のソフトウェア産業化をもたらすからです。そして大幅なコスト削減が実現します。来 実際、話を戻してみると、開発フレームワークは非常にシンプルです。これは非常にシンプルなので 1 ～ 2 文で要約できます。まず、ユーザーが呼び出すためのさまざまなクラス ライブラリを提供し、ユーザーが記述するコードの量を減らします。 2 つ目は、ユーザーが必要なプラグインを簡単に追加できるようにして、ユーザー開発を軽減できるようにすることです。これは実際には相互に呼び出しを行う関連システムです。 MVC システムでは、純粋な OOP フレームワークであり、後者はユーザーのコードを呼び出すフレームワークです。この点で最も顕著なものはユーザー インターフェイス コンポーネントです。 PHP には、このカテゴリのフレームワークが多数あります。しかし、それらはどれも非常に初歩的なものです。 JAVA の FCS や TYPESTRY に匹敵するものはありません。初心者の中には、200KB 未満のタグ エンジンを公開できる人もいます。コードを見なくても想像できますが、確かな原則どころか、デザインパターンも存在しません。そうなると、拡張と維持というのはかなり大きな問題になります。

そこで、PHP を使用して Web サイトを運営しているインターネット企業がどれだけあるのかを考えました。PHP は表面的にはコストを削減しているように見えますが、どの程度まで削減できるのでしょうか。重要なのはやはり OOP コードから OOP アーキテクチャまでです。OOP アーキテクチャのレベルによって、技術部門による開発の効率とコストが決まります。