リモートファイル・サーバクライアント

ウィキペディア小見出し辞書

リモートファイル・サーバクライアント

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/04/30 03:24 UTC 版)

「依存性逆転の原則」の記事における「リモートファイル・サーバクライアント」の解説

リモートファイルサーバー(FTP, cloud strage ...)に対するクライアントを実装しなければならないケースを想像せよ。あなたはそのクライアントに抽象インターフェースを持たせる事を考えるだろう。 Connection/Disconnection (a connection persistence layer may be needed) Folder/tags creation/rename/delete/list interface File creation/replacement/rename/delete/read interface File searching Concurrent replacement or delete resolution File history management ... ローカルファイル、リモートファイルの両方が同じ抽象インターフェースを提供する場合、ローカルファイルと完全に実装された依存性逆転パターンを使用するどんな上位レベルモジュールもローカルとリモートの区別なくファイルにアクセスすることが可能になる。 ローカルディスクは一般的にフォルダーを使用し、リモートストレージもフォルダーを使用するかもしれない(もしくはタグのみ、フォルダーとタグの両方など）。 もし可能であればそれらを統一する方法を決めておく必要がある。 リモートファイルに対しては、作成と置換のみを行う必要があるかもしれない(ローカルファイルに比べてリモートファイルのランダムアップデートはあまりに遅く、実装も難しくなる可能性があるので、リモートファイルの更新は意味をなさない)。リモートファイルに対して部分的な読み込みと書き込みを行う必要があるかもしれない（少なくともリモートファイルモジュールの内部では通信中断後のダウンロードとアップロードの再開をできるようにする必要がある）。しかし、ローカルキャッシュを利用している場合を除き、ランダムリードは適さない。 ファイル検索は "pluggable" であるかもしれない ファイル検索は OS、特にタグや全文検索に依存し、異なるシステムでも実装する事ができる。(OS に組み込まれていたり、別に入手する事も可能) 並行実行される置換または削除の検出は、他の抽象インタフェースに影響を与える可能性がある。 概念的なそれぞれのインターフェースに対してリモートファイルサーバーを設計するときは、上位レベルモジュールが要求するサービスのレベル (必ずしも全てが要求されるわけではない）を良く考える必要がある。そして、どのようにリモートファイルサーバーの機能を実装するかだけでなく、アプリケーション内に既に存在するファイルサービス（ローカルファイル、既にあるクラウドクライアントなど）と新たしいリモートファイルサーバークライアントの間で整合を取るかについても同様に考える必要がある。 必要なインターフェースの設計が完了したら、リモートファイルサーバークライアントはこれらのインターフェースを実装すべきである。 また、既に存在するローカルファイルに対しての機能 (例えばファイル更新など）について制限を加えたい場合、同じ抽象インタフェースを提供するローカルまたは他の既存のリモートファイルアクセスモジュール用のアダプタを記述する必要があるかもしれない。また、コンピュータ上に構成されている利用可能なファイル互換システムを検索するために独自のファイルアクセス列挙子を記述しておく必要もある。 これらが完了すると、アプリケーションはドキュメントをローカルとリモートに透過的に保存する事が可能になる。さらに簡単に言うと、新しいファイルアクセスインターフェースを使用している上位レベルモジュールは使用の際にローカルとリモートファイルにアクセルするシナリオを意識する必要がなくなり、再利用性が向上する。 注意: 多くの OS がこの手の機能を実装し始めているため、新規実装のクライアントをこの既に存在している抽象モデルへ適用するのは控えた方が良いかもしれない。 この例では、モジュールを抽象インターフェースのセットとして考え、このインターフェースのセットに他のモジュールを適合させることで、様々なファイルストレージシステムに対し、共通のインターフェースを提供する事ができる。