パート4– WordPressとオブジェクト指向プログラミング：WordPressの例–デザイン

この時点で、このシリーズのパート3で説明したように、明確に定義された要件があります（見逃した場合は、ここで確認してください）。

今こそ、新しく改良されたプラグインの設計について考え始めるときです！

この手順を自分のプロジェクトで試してみると、時間がかかる場合があることをお知らせします。 おそらく、最初からすべてが正しくなるとは限りません。 たぶん、あなたはデザインを思いつき、それを実装し始め、そしてあなたが戻ってあなたのアプローチを再考する必要があることに気付くでしょう。

努力する価値はありますが、すべてを正しく行うために必要なだけの時間をかけてください。 適切に構造化されたプロジェクトを使用すると、プロジェクトの保守と拡張が容易になり、他のプロジェクトでコードを再利用することもできるため、長期的には時間を有効に活用できます。

次に、プラグインのいくつかの重要な部分に焦点を当て、どのように設計を考案したかについて説明します。

設定ページの分析

プラグインの管理ページを詳しく見てみましょう。

タイトル（「ログイン試行回数の制限設定」）、いくつかのフィールドを含むいくつかのセクション、およびページの下部にある「オプションの変更」ボタンがあることに気付くでしょう。

各セクションは、「統計」などのタイトルといくつかのフィールドで構成されています。

各フィールドの左側にはタイトルがあり、残りのコンテンツは右側にあります。 テキストフィールド、ラジオボタン、チェックボックスがあり、「完全ロックアウト」などの一部は情報のみを表示し、管理者ユーザーが直接変更することはできません。

一部のフィールドには、「サイト接続」フィールドなどの説明も含まれていますが、すべてではありません。

上記を念頭に置いて、後でクラスになる概念的な部分に分解する必要があります。

WordPress設定APIを使用すると、設定ページ、それらのページ内のセクション、およびセクション内のフィールドを登録できます。

ページ→セクション→フィールド

プラグインを将来拡張しやすくするために、もう1つの「レイヤー」であるElementsを追加してみませんか。

ページ→セクション→フィールド→要素

したがって、ページとセクションはすでに上で説明したものであり、フィールドには右側に任意のコンテンツタイプの要素が含まれます。

これらのさまざまな種類の要素をすべて考慮して、さまざまな出力をレンダリングするチェックボックス、ラジオボタン、数値などについて、Elementクラスといくつかのクラスを拡張して拡張しました。

また、将来的にはさらにページやセクションを追加する必要があるかもしれません。 したがって、これらの管理ページとセクションクラスを拡張する必要がある可能性があります。

同じことがフィールドにも当てはまります。 「トータルロックアウト」、「アクティブロックアウト」などのクラスは、同じ（親）クラスを拡張します。

これらの関係を示す簡略化されたビジュアルを次に示します。

もちろん、すべての「コンポーネント」が図に含まれているわけではありません。

このような構造により、プラグインの拡張が容易になります。 必要に応じて、フィールド、要素、またはセクションを簡単に追加できます。 既存の子クラスを変更することなく、新しい子クラスを作成することで、フィールド、要素、セクションなどのコンポーネントを簡単に追加できるようになります。

思考と抽象化

今こそ、プラグインのさまざまなコンポーネントが何をするのかを考え始める絶好の機会です。 設計段階では、何かがどのように機能するかについて詳細に説明する必要はありません。

たとえば、すべての要素、テーブル、統計、およびユーザーに表示されるその他のほとんどすべてを考慮してください。 それらは共通点のない別個のコンポーネントである可能性がありますが、最終的にはすべて何らかの出力をレンダリングします。 したがって、一部の機能は、他の点では完全に無関係なコンポーネントに共通です。 もちろん、これは残りのコンポーネントにも適用されます。

上記のビジュアルでは、UIインターフェイスが複数のクラスによってどのように実装されているかを示しています。

UIインターフェイスは、親クラスと呼ばれるStatistics、Lockout Logs、Table、およびElementクラスによって実装されていることに注意してください。 Radio / Number / Checkbox Elementクラスは、親クラスからすべてのインターフェイスを継承するため、インターフェイスを直接実装する必要はありません。 ただし、子クラスはその親クラスのメソッドをオーバーライドできます。

プラグインが設定を処理することがわかっているので、値の読み取りと書き込みを安全に想定できます。 つまり、オプションを取得、設定、および削除できることです。

これらのアクションはすべて、クラスにまとめられます。 おそらく、WordPressデータベースなどにオプションを保存します。 今のところ、データを保存する方法や場所を気にする必要はありません。

get / set / removeオプションの抽象化を念頭に置いて、概念的に物事を単純化し、プラグインを設計し続けることができます。

メインプラグインファイル

ここでは、ヘッダーコメントを介してWordPressにプラグインに関する情報を提供し、初期化を実行します。 すべてを小さなクラスにラップすることで、コードを整理します。

プラグインのクラスがどのように連携するかに応じて、メインクラスはそれらのほとんどをインスタンス化する必要があります。 私たちが知る限り、これにはオプション、管理ページ、再試行、ロックアウトに関連するクラスが含まれます。

潜在的なクラス

必要なクラスを見つけるのに少し時間がかかり、次のようなリストになりました。

• 再試行
• ロックアウト
• クッキー
• エラーメッセージ
• 電子メール通知
• 管理者の通知
• ボタン
• ロックアウトログ
• アクティブ/トータルロックアウト
• IPアドレス

プラグインを構造化するための単一の「正しい」方法はないことに注意してください。 ソフトウェア開発のほとんどのものと同様に、問題を解決するための複数の、等しく有効な方法があります。

たとえば、「一般」セクションでは、クラス間の関係は次のようになります。

「統計」セクションは次のようになります。

最後に、「ロックアウトログ」は「統計」と非常によく似ています。

結論

これまでのところ、要件を定義し、新しく改良されたプラグインの設計について考えました。 構造をどのように考え出したかを説明し、クラスが互いにどのように関連するかを示す簡単な図もいくつか提供しました。

オブジェクト指向プログラミングシリーズのパート5を読むには、ここをクリックしてください

関連項目

• WordPressとオブジェクト指向プログラミング–概要
• パート2– WordPressとオブジェクト指向プログラミング：実際の例
• パート3– WordPressとオブジェクト指向プログラミング：ΑWordPressの例–スコープの定義