How to make this object more maintainable?

Question

For example, I have something like this:

User
-FirstName
-SecondName
-Gender

and the VIPUser, which is the subclass of User

VIPUser extends User
-GiftNum
-Birthday

But suddenly the application need to change the policy, all the User must have the Birthday.... And it is not a optional field, which not allow to set null anymore for user, it becomes the MUST fill in variable for the new register User, but I can remain null for the existing user...

So, I will need to change all the User creation method, and pass the Birthday, it involves lot of codes. How can I make it more maintainable? Thanks.

Answer 1

How can I make it more maintainable?

I take it that what you are really asking is for some design technique that would avoid you having to refactor your code.

I think that answer is ... unfortunately ... that there is no such technique that would be considered as good Java practice. The best strategy is to try to think ahead when designing your APIs, and be prepared to aggressively refactor when the requirements change.

---

Comments on other questions:

• Designing to interfaces is good advice, and can often simplify some kinds of refactoring. However, I don't think it would help with a problems like yours.

• Creating wrappers and things to support the new state (the birthday) is probably a bad idea. The wrapper class is likely to complicate your codebase in various ways. If you use this approach a number of times, you will find that you codebase gets increasingly hard to understand. You are effectively building up a "technical debt" of problems that are not fully fixed.

• Yes. A good IDE can be extremely helpful in doing large-scale refactoring. Indeed, your particular problem strikes me as rather easy to refactor ... with a good IDE.

Answer 2

Design to interfaces, more flexible and one class can implement multiple interfaces.

Instead of specifying User class as parameter type you would specify the appropriate interface ... much easier to maintiain as the underlying implementation is not important.