ファサードパターンによるJava構造変化

Question

Javaプロジェクトで特定のGUIコードを再構築しようとしています。プロジェクトから依存関係を削除し、コードを既存のAPIに移動して、プロジェクトAと呼びましょう。基本的に同じ機能/インターフェイスを必要とする別のプロジェクトがあります。他のプロジェクトでこれらの機能を再利用したいと思います。

GOFによるデザインパターンブックのファサードデザインパターンについて読み、ここで適用できると考えました。

ファサードパターンについて読む前に、私はImessagePasserというインターフェイスを作成しようとしました。これは、プロジェクト固有のコードをインターフェイスメソッドに置き換えるだけでなく、各クライアントが実装する契約として、たとえばProjectamessagePasserに置き換えます。これはファサードの半分を扱っているようで、GUIコードをAPIに移動できるようにします。

次のステップは、ProjectBmessagePasserとGUIコードの間に必要な通信を基本的に把握するために、ProjectamessagePasser内にさらにメソッドを追加してGUI依存関係を置き換えるプロジェクトAで同じことを行うことだと思います。

コードの大規模な再編の経験はあまりありませんが、これはすべて妥当と思われますか？すべての変更を最初に行わずに伝えるのは難しいです。これを行うためのより良い方法がある場合、私はそれを一つにして多くの時間を無駄にしたくありません。

Answer 1

より管理しやすくするために、アプリの機能領域向けのサービスを作成し、そこにリファクタリングを集中させることをお勧めします。あなたが行くときに、機能を検証するためにユニットテストを記述します。サービスに機能を備えたら、それらのサービスの周りにファサードを作成できます。

言い換えれば、アプリ全体を一度にリファクタリングするのではなく、分割して征服する方が簡単かもしれません。