Drink Remodeling Series [5]--named for Boolean methods

Overview

When a method contains a large number of Boolean parameters, the method is fragile, and there are two problems that may arise:

1. method is not easy to understand
2. causing some problems for the users of the method may result in some unintended results.

The refactoring strategy described in this article, "Named by Boolean method", can effectively avoid these two problems.

Problems with naming a large number of Boolean parameters for a Boolean method

The SomeClass in the SomeMethod contains 3 boolean arguments, and if there is no comment, the caller does not know what the 3 boolean arguments represent.

Even if detailed comments are provided for this method, it is easy for the caller to make an error at the time of the call.
An unexpected behavior can occur when the caller accidentally writes one of the parameters incorrectly.

In the actual business process, you may only use these 3 parameters to process two or three business case.
However, this method has 3 Boolean parameters, which is equivalent to providing 8 calls to the caller case!
Does your program need to provide 8 kinds of case? There is absolutely no need, because the other kinds of case may not happen at all!

var obj = new SomeClass (); obj. SomeMethod (False, False, false);  Way1obj. SomeMethod (False, True, false);   Way2obj. SomeMethod (False, True, true);    Way3obj. SomeMethod (False, False, true);   Way4obj. SomeMethod (True, true, true);     Way5obj. SomeMethod (True, false, false);   Way6obj. SomeMethod (True, true, false);    Way7obj. SomeMethod (True, false, true);    Way8

This is like the last century production of TV remote control, dozens of keys, users do not know how to use the manual!
For the user, a remote control to adjust the channel, the volume is sufficient.
To the user too much choice is not a good thing, the user will be too many choices and wandering, never to provide users with a complex way to use!

Refactoring policy

The "Name for Boolean method" strategy is intended to extract some Boolean parameters and replace the Boolean parameters with the appropriate naming of the methods.
Next, go to our example and illustrate the refactoring strategy with a practical example.

Example before refactoring

The CreateAccount () method is used to create an account, it provides 4 parameters, and the latter 3 are Boolean types.

public class bankaccount{public    void CreateAccount (Customer customer, bool withchecking, BOOL withsavings, BOOL with Stocks)    {        //do Work    }}

If you are the caller of this method, you might jump out of 8 calls in your head, but do you know how to invoke it?
I don't know what your answer is, my answer is: not clear.

After refactoring

Careful analysis of the "Create a bank account" business, we found that "create an account" will only produce two cases.

1. Verify and create an account
PS: When you go to a bank to open an account, you need to verify your identity information.

2. Verify and create the account and deposit the initial savings amount.
PS: When you go to the bank to open an account, you can deposit a portion of the initial amount into your bank card when the identity information is verified.
We have provided 2 ways to implement these 2 case, the 2 methods use meaningful naming, and the original CreateAccount () method to restrict its accessibility with private adornments.

public class bankaccount{public    void createaccountwithchecking (Customer customer)    {        CreateAccount ( Customer, True, false);    }    public void Createaccountwithcheckingandsavings (customer customer)    {        CreateAccount (customer, True, true);    }    private void CreateAccount (customer customer, bool withchecking, bool withsavings)    {        //do Work    }}

After refactoring, callers can only use the createaccountwithchecking () and Createaccountwithcheckingandsavings () methods, and the names of the two methods are also easy to know what they mean.

Drink Remodeling Series [5]--named for Boolean methods