同じ機能の2種類のデザインパターン

Question

すべて、

ftpを使用してファイルサーバーにログを書き込む機能を開発しています。ファイルサーバーへの書き込みは、ファイルサーバーが構成されている場合にのみ行われます。サーバが設定されていない場合、操作は終了してステータスを返します。流れは次のようなものです：

1.実行操作 2.ファイルサーバが接続されている場合は、ログに 3.リターン今

を書き、（DBおよびpingで確認してください）私があれば知りたいのですが同じ機能のデザインパターンですが、機能の範囲は設定の有無によって異なります。私はずっと2つのシナリオには、この上で助けいただければ幸いです：

1. 静的 - ポストのようにシステムをブートアップベースのファイルサーバーがあることを「仮定」またはすることはできません - DBの設定には、ブートアップ時の1時間があればDBからの読み込み

2. ダイナミック - システムが起動して実行中に、ファイルサーバーを起動してDBを構成することがあります。このシナリオでは、システムを強制的に再起動するのではなく、ファイルサーバーを検出してログを書き始めるのが理想的です。

この点に関するヘルプが必要です。あなたのデザインがSingle Responsibility Principleの違反のように見える

おかげ

Answer 1

。最初の問題は操作そのものであり、2番目の問題はログを中央の場所に送ることです。

コンポーネントを2つのより単純で独立したコンポーネントに分けることを考えてみましょう。そのうちの1人はビジネスオペレーションを実行し、ログをローカルファイルに書き込んでいます。それはそれです。他のコンポーネントは、ローカルファイルシステム上に新しいログが存在するかどうかをチェックし、それらを中央の場所にコピーします。

Answer 2

Log4Jなどの既存のロギングフレームワークを使用しているかどうかについては言及していません。そうでない場合は、おそらく良い考えです。独自のログフレームワークを公開しようとすると、ログレベル（INFO、DEBUG、ERRORなど）を扱うなど、予期しない複雑な問題に対処する必要があります。 。

オリジナルのメッセージに関しては、Factoryパターンを使用することを検討します。ファイルサーバーが使用可能かどうかを内部的にチェックできるファクトリクラスを作成し、ConsoleLoggerやFTPLogger。これらの両方が同じインターフェースを実装していることを確認して、呼び出しコードが使用しているロガーのタイプを気にする必要がなくなります。また、操作を実行するオブジェクトをラップできるDecoratorを使用することもできます。要求が完了すると、デコレータにロギングを依頼してください。

最後のコメント - ログするたびにファイルサーバーが使用可能かどうかを確認しないようにしてください。すべてのログ呼び出しでデータベースがヒットすると、パフォーマンスがひどくなる可能性がありますが、ロギングメソッドのエラー（DBロックなど）によって操作が失敗することはありません。