Item 51: Design method signatures carefully

51. Carefully design the method signature

• Method names should be chosen carefully. It is easy to understand and should be consistent with other names in the package. Also, give a name that is widely and generally agreed upon. If in doubt, take a look at the Java Library API as guidance (some are bad, but many are good).
• Don't over-provide useful methods. Too many methods can be difficult to learn, use, document, test, and maintain. Consider providing methods that allow you to omit the description only if it is used frequently. If you get lost, don't make it.
• The number of arguments should not be large. The number of arguments should be kept to 4 or less. The user cannot remember many arguments, so he must use them while looking at the reference. Especially if you have many arguments of the same type. This is because even if the order of the arguments is incorrect, a compile error will not occur and processing may be performed differently than intended. There are three techniques to reduce the number of arguments.
• Divide one method into multiple methods. (** I gave examples of sublist, indexOf, and lastIndexOf of List, but I'm not sure **)
• Create a helper class. For example, if there is something that takes the pattern and number of playing cards as arguments, create an Entity that summarizes the patterns and numbers and take it as an argument.
• Use the builder pattern. (Item2)
• The argument type should take precedence over the interface over the concrete class. Making it a concrete class forces the user of the method to implement a particular implementation, sometimes forcing a costly copy.
• boolean Should be a binary enum rather than an argument. Because enums are easier to extend later (from 2 to 3 elements). Enums can also have methods in them. (Item34)