3

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.

DNB5brims
  • 29,344
  • 50
  • 131
  • 195
  • If compatibility is a matter: You cannot change the code. If not (and you have access to all code): Use a good IDE an make a refactor. – Christian Kuetbach Apr 24 '12 at 15:09
  • I can change the code, but finding all the creation of object, and add back the new `birthday` value to the object seems very messy. – DNB5brims Apr 24 '12 at 15:15

5 Answers5

4

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.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
3

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.

NimChimpsky
  • 46,453
  • 60
  • 198
  • 311
1

Create a wrapper that creates the User instance and he must receive the Date argument to set the Birthday, the validations and all the rules to create it. Also, as @NimChimpsky said, you should define an interface for this wrapper (interfaces are mainly for business logic classes, not for entities).

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
1

Changing APIs ripples in your code like so, there is no way around that. Not in a strongly Typed language at least.

As the others suggest you should have strict and clear separation between Interfaces and their Implementations.

Then you can version your APIs and their respective impl modules so that you don't break your APIs clients when your update your program. DB schema compatibility is another interesting problem. :)

In general, using Factory (pattern) for giving aroung instances of User Class and hide its implementation behind an interface, is a good encapsulation of creating objects. And, again as others suggest, using some good IDE with refactoring capabilities should make it a breeze.

Svilen
  • 1,377
  • 1
  • 16
  • 23
0

It shpuld be easy. Use a actual Java-IDE make a right click to your constructor and perform a refactoring. The problem will not be to change the code, but to get the value of "birthday".

Refactoring is quite easy (I prefer IntelliJ but I think Eclipse and Netbeans will do a good job, too).

Christian Kuetbach
  • 15,850
  • 5
  • 43
  • 79