たとえば、次のようなものがあります。
User
-FirstName
-SecondName
-Gender
のVIPUserサブクラスであるUser
VIPUser extends User
-GiftNum
-Birthday
しかし、突然、アプリケーションはポリシーを変更する必要があり、すべてが...Userを持っている必要があります。Birthdayそして、それはオプションのフィールドではなく、nullユーザーが設定することはもう許可されていません。新しい register の変数に入力する必要がありますUserが、私はnull既存のユーザーのために残すことができます...
したがって、すべてのUser作成方法を変更して を渡すBirthday必要があります。これには多くのコードが含まれます。メンテナンス性を高めるにはどうすればよいですか？ありがとう。
メンテナンス性を高めるにはどうすればよいですか？
あなたが本当に求めているのは、コードのリファクタリングを回避するための設計テクニックだと思います。
その答えは...残念ながら...Javaの優れた実践と見なされるような手法は存在しないということだと思います。最善の戦略は、API を設計する際に事前に考え、要件が変更されたときに積極的にリファクタリングする準備をすることです。
その他の質問に対するコメント:
インターフェイスを設計することは良いアドバイスであり、多くの場合、ある種のリファクタリングを簡素化できます。ただし、あなたのような問題には役立たないと思います。
新しい状態 (誕生日) をサポートするラッパーやものを作成することは、おそらく悪い考えです。ラッパー クラスは、さまざまな方法でコードベースを複雑にする可能性があります。このアプローチを何度も使用すると、コードベースがますます理解しにくくなることがわかります。完全に修正されていない問題の「技術的負債」を効果的に積み上げています。
はい。優れた IDE は、大規模なリファクタリングを行う際に非常に役立ちます。確かに、あなたの特定の問題は、リファクタリングがかなり簡単だと思います...優れたIDEを使用します。
インターフェイスへの設計、より柔軟で、1 つのクラスで複数のインターフェイスを実装できます。
User クラスをパラメーターの型として指定する代わりに、適切なインターフェイスを指定します。基になる実装は重要ではないため、保守がはるかに簡単です。
このように API を変更すると、コード内で波紋が発生します。これを回避する方法はありません。少なくとも強く型付けされた言語ではありません。
他の人が示唆しているように、インターフェイスとその実装を厳密かつ明確に分離する必要があります。
次に、プログラムを更新するときに API クライアントを壊さないように、API とそれぞれの impl モジュールをバージョン管理できます。DB スキーマの互換性は、もう 1 つの興味深い問題です。:)
一般に、ファクトリ (パターン) を使用してユーザー クラスのインスタンスを提供し、その実装をインターフェイスの背後に隠すことは、オブジェクトの作成を適切にカプセル化することです。また、他の人が示唆しているように、リファクタリング機能を備えた優れた IDE を使用すると、作業が簡単になります。
Userインスタンスを作成するラッパーを作成し、それを作成するための 、検証、およびすべてのルールをDate設定するための引数を受け取る必要があります。Birthdayまた、@ NimChimpskyが言ったように、このラッパーのインターフェースを定義する必要があります（インターフェースは主にビジネスロジッククラス用であり、エンティティ用ではありません）。
簡単なはずです。実際の Java-IDE を使用して、コンストラクターを右クリックし、リファクタリングを実行します。問題はコードを変更することではなく、「誕生日」の値を取得することです。
リファクタリングは非常に簡単です (私は IntelliJ を好みますが、Eclipse と Netbeans もうまく機能すると思います)。