Recently I'm confronted with one issue and I want to know your opinion about this.
In one of my business tier class I had method register user:
According to new business rules I need to add 2 arguments to this methods (boolean isCustomBank and String customBankName).
All arguments in method are mandatory and I need them in registration process. It is also possible that in future it would be needed to pass more arguments to registerUser method (according to changes in business logic).
A) Create userContext (as map) and collect there some arguments that needed in registration process (it would be used not only in this method, so it also would contain some other arguments not needed in registration). Signature of this method would look like this:
Invocation would look like this:
B) Create userContext (as class � wrapper of map from previous solution) and collect there some arguments that needed in registration process (it would be used not only in this method, so it also would contain some other arguments not needed in registration). Signature of this method would look like this:
C) Create value object UserRegistrationData that would hold data ONLY for user registration method. Example of the signature:
And value object class:
D) Just add new arguments to method's signature:
E) your solution....
I don't tell you my opinion and pros and cons because I want to know your independent opinion.
Which of these solutions are good and why do you think they are good? Which of these solutions are bad and why do you think they are bad?
I think I like C, but wonder why you didn't roll user and type into the new class, too. Of course now the new class is going to be just complex to build as the method signature you're trying to avoid. Consider making it immutable (lose all the setters) and load it entirely in the constructor.
Map arguments like you sketched out offer a lot of flexibility but communicate nothing. This will certainly let clients know the signature has changed this time and any time in the future.
Will you be able to leave the old signature and default the new fields to false and none?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi