1

私が取り組んでいる Web サイトでは、フロントエンドとバックエンド (CMS) で使用するメディア サービス オブジェクトを作成しました。このメディア サービス オブジェクトは、ローカル リポジトリ (DB) 内のメディアを操作します。ビデオをアップロード/埋め込み、画像をアップロードする機能を提供します。

つまり、Web サイトの訪問者はフロントエンドでこれを行うことができますが、サイトの管理者はバックエンドでもこれを行うことができます。

このサービスは、訪問者がフロントエンドで新しいメディアをアップロード/埋め込みしたときに管理者にメールを送信することを望みますが、バックエンドでメディアを自分でアップロード/埋め込みするときはメールを送信しないでください。

そのため、メール機能を模倣する null オブジェクトをバックエンドの Media Service に渡すのに適しているかどうか疑問に思い始めました。バックエンドにメール機能も実装する必要があると判断した場合、これが役立つかもしれないと思いました。

簡単に言えば、次のようなことをしたいと思います。

フロントエンド：

$mediaService = new MediaService( new MediaRepository(), new StandardMailService() );

バックエンド:

$mediaService = new MediaService( new MediaRepository(), new NullMailService() );

これについてどう思いますか？これは理にかなっていますか？それとも、今後の問題に備えていますか？

4

1 に答える 1

3

私はこのパターンのファンです。また、セマンティクスに合わせてオブジェクトの名前を変更することも好きです。

ご存じのように、NullObject を使用することで得られる 2 つの利点は次のとおりです
。1) コード内の null のチェックを回避できる、
2) null が返されたときに意味的に何が起こっているかを表すオブジェクトに動作を統合できる。

管理者がアップロードしたときに null を返す if ステートメントがある場合は、そうです。バックエンドのアップロードでメールを送信する可能性が低い場合でも、それをオブジェクトにキャプチャすることは安価で潜在的に役立つと思います。メールサービスを代わりに通知サービスと見なす場合は、FrontendNotificationService (メールを送信する) と BackendNotificationService (現在メールを送信しないが、アップロードに関する有用な統計 (数、合計サイズなど) を蓄積する可能性がある) があるかもしれません。 .)。

上記のいずれにも当てはまらない場合、個人的には、NullMailService を使用しないコンストラクターの方が読みやすく、StadndardMailService を使用するコンストラクターの方が読みやすいと思います。

良いニュースは、NullService が有用であると判断した場合、または NullService を試して有用ではないことがわかった場合に元に戻すことが容易なリファクタリングであることです。

HTH、
ベリル

于 2010-04-01T18:47:22.220 に答える