メソッドのコレクションとしてクラスを使用するオブジェクト指向 PHP から始めるのは賢明でしょうか? このアプローチに欠点はありますか?
OOP がこれ以上のものであることは知っていますが、私の PHP プロジェクトは小さすぎて、OOP が提供するすべてを活用できません。一方で、私のプロジェクトは大きくなりすぎて、手続き型プログラミングだけでは更新/保守できません。
私は OOP に関する多くのトピックを読んできましたが、時々誰かが「OOP は単なる関数の集まりではありません」(またはこれらの線に沿った何か) と言います。それは本当かもしれませんが、そうするだけでオブジェクト指向プログラミングの世界についに飛び込むチャンスかもしれません。
では、これは実際に OOP の使用と学習を開始するための賢明な最初のステップでしょうか? または、知っておく必要がある深刻な欠点はありますか?
免責事項: しばらく php を扱っていないため、構文が間違っている可能性があります。
OOP という用語は少しあいまいです。つまり、人によって、それを聞いたときにわずかに異なることを考えるという意味です。そのため、矛盾したことを聞いても混乱しないでください。
クラスを使用して同様の関数を一緒に構造化しても、コードが損なわれることはありませんが、基本的にはクラスを関数の名前空間として使用するだけです。通常、システムの一部の側面をカプセル化する方法でクラスを定義する必要があります。つまり、そのクラスのコードのみがその側面を直接処理する必要があり、他のすべての人はそのクラスを使用するだけです。
たとえば、印刷ジョブ キューを管理するクラスを作成できます。ドキュメントを印刷したいコードがある場合、ジョブがキューに入れられる方法や場所、またはプリンターに送信される方法を知る必要はありません。印刷ジョブ キュー オブジェクト ( と呼びましょう$jobQueue)を知るだけで済みます。のようなメソッドを持つ場合があり$jobQueue->enqueue($document)ます。
ここで、「そのコードはグローバル関数enqueueJob($document)を使用することもできます」と主張するかもしれません。これは、複数のキュー (異なるプリンター用) と、異なる方法で動作するキュー (ジョブをデータベースに保存する) が必要になるまでは当てはまります。 、メモリ内、またはまったくない-ごみ箱に直接行くキューを想像してください:))。OOP では、この種のシナリオは問題ありません。これらの詳細は、ドキュメントを印刷するコードから完全に隠されています。気にする必要があるのは、enqueueメソッドを持つジョブ キュー オブジェクトがあることだけです。
ジョブ キューのこの種の「互換性」を得るには、ジョブ キューに共通のインターフェイス (この場合はenqueueメソッド) が必要です。これは、出力したいコードのすべてのニーズをカバーするように慎重に選択する必要があります。印刷キューがどのように機能するかについての仮定が多すぎます。たとえば、enqueueメソッドがファイルの保存場所をキューに伝える引数としてファイル パスを受け取ると想像できますが、そのインターフェイスはデータベースで動作するキューには役に立ちません。これは、優れた抽象化を見つける技術です。
元の質問に戻ると、新しいクラスが提供するはずの抽象化/インターフェイスについて考えない限り、関連する関数をクラスにまとめることは、私の意見では実際には OOP ではありません。それがなければ、この新しいクラスを使用するすべてのコードはそれを使用するように配線され、別の種類のプリンター キューが必要であると判断した場合は、変更または再検討する必要があります。:)
ただし、「OOP ではない」ということは、「良い考えではない」ということとは異なります。私はそれに行き、あなたの機能を再配置すると言います。私の意見では、すべてがオブジェクトである必要はなく、何らかの抽象化に適合する必要はないことを心に留めておくことが重要です。しかし、共通のインターフェースに抽象化できる、似たようなこと (ファイル内のキュー、データベース内のキュー) を行う関数がいくつかあることに気付くかもしれません。
あなたの質問は非常に幅広いものですが、オブジェクト指向の分析と設計 (OOAD) の世界への旅を続けている間、記憶して保管しておくことができる単純な答えに値します。
では、これは実際に OOP の使用と学習を開始するための賢明な最初のステップでしょうか? または、知っておく必要がある深刻な欠点はありますか?
ご想像のとおり、この質問に直接答えることはできません。何がスマートで何がそうでないかは、私たち自身の能力に大きく依存します。たとえば、一部の人にとっては、エラーを早期に停止するのに役立つため、賢明かもしれません。これが進むべき道です。他の人にとっては、エラーを見つけられないので完全な破滅かもしれませんが、エラーを見つけられなければ、これは完全に正しいと考えているため、ソフトウェアの開発を続けます。
では、このジレンマを解決するにはどうすればよいでしょうか。簡単です。OOP には 2 つの部分があり、簡単に学習して覚えておくことができます。1 つ目はSTUPIDと呼ばれます - 何かがこのカテゴリに分類される場合、それが何を意味するか想像できるかもしれません。
OOP は基本的に単なるメソッドのセットです。しかし、プログラミングの考え方は異なります。クラスでは、同様の機能をカプセル化します。コードが読みやすくなり、同じ機能を何度も書く必要がなくなります。また、より安全です（プライベートメンバー）。ライブラリを作成している場合、エンドユーザーは必要なものだけを変更できます。したがって、一連の関数で OOP をバイパスし、代わりに実際の OOP を使用することはお勧めしません。そうしない理由はありません。
私はお勧めしません.OOPとしてマスクされた手続き型コードを書くことに慣れるでしょう.これはあなたが本当に望んでいるものではありません. 最初は難しいかもしれませんが、OOP のすべての機能を学び、パターンについて読み、コーディング標準に重点を置き、最も重要なこととして、オブジェクト指向アーキテクチャーを使用したアプリケーションを学習します。
この質問は実際にはphpとは関係ありませんが、一般的にOOPとは関係がないため、この回答は多くの言語で有効です。
OOP には異なるパターンが存在します。「ギャング・オブ・フォー」について読むことをお勧めします。これは、OOP を行う際に使用できる最も基本的なパターンのいくつかを説明する、非常に優れた本です。
クラスを使用して一連の静的関数を保持する代わりに、すべての関数を名前空間に格納することを検討する必要があります。
多くの場合、クラスはオブジェクト (物理オブジェクトなど) を定義します。物理オブジェクトには、一連のプロパティと動作があります。
クラスを設計するとき、それらの動作とプロパティを定義しようとしています。たとえば、バッグ。
class Bag:
// Methods
function open: ...
function close: ...
function empty: ...
function add(item): ...
// Properties
array items: []
bool is_open: false
一部のプロパティまたはメソッドは、世界に対して非表示または表示にすることができます。私の例では、閉じたバッグを空にするか、オブジェクトを追加しようとするたびに、関数 add が例外をスローするようにすることができます。ここにあるすべてのメソッドが実際のオブジェクトに関連していることは明らかです。
バッグに関係のないメソッドまたは属性を追加する場合は、別の名前空間またはクラスに属している必要があります。それは本当にあなたがしようとしていることに依存します。