• Post Reply Bookmark Topic Watch Topic
  • New Topic

Changing method signature according to the new business logic  RSS feed

 
Ostin Night
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear java community,

Recently I'm confronted with one issue and I want to know your opinion about this.

ISSUE DESCRIPTION:

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).

POSSIBLE SOLUTIONS:

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:



And UserCostants:



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:



Wrapper class:



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....

QUESTIONS:

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?

Thanks.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!