• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Changing method signature according to the new business logic

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
get schwifty. tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic