3 ms·

Overloaded constructors where the parameter order is different in overloads doesn't seem like a great idea. Surely > public ErrorResponse(int successCount, in

Overloaded constructors where the parameter order is different in overloads doesn't seem like a great idea. Surely > public ErrorResponse(int successCount, int errorCount, String errorMsg, String warningMsg); > public ErrorResponse(int successCount, int errorCount, String errorMsg, String warningMsg, String successMsg); would cause fewer problems than > public ErrorResponse(int successCount, int errorCount, String warningMsg, String errorMsg); > public ErrorResponse(int successCount, int errorCount, String successMsg, String warningMsg, String errorMsg);

sa46 5y ago
They're a really bad idea, so much so that's it's the first item in Effective Java: > Consider static factory methods instead of constructors The reasons outlined in Effective Java include: - Unlike constructors, static factory methods can have names. - Unlike constructors, static factory methods are not required to create a new object each time they're invoked (immutable objects, flyweight pattern). - Unlike constructors, they can return an object of any subtype of their return type. - Unlike constructors, the class of the returned object can vary from call to call as a function of the input parameters. Effective Java even has advice for overloading: Item 52, "use overloading judiciously" > A safe, conservative policy is never to export two overloadings with the same number of parameters. I prefer stronger guidance for overloading that I'll paraphrase poorly from a forgotten source (Guava maybe): each overload should return pretty much the same thing and it should be obvious from the call site. The OP's article violates this principle since warnings should be distinct from errors.
karagenit 5y ago
Oh, absolutely! The problem was that different parameters were added at different times (by different developers), and they weren't careful enough to realize they were doing it incorrectly. Thanks for reading!

sa46 5y ago

They're a really bad idea, so much so that's it's the first item in Effective Java: > Consider static factory methods instead of constructors The reasons outlined in Effective Java include: - Unlike constructors, static factory methods can have names. - Unlike constructors, static factory methods are not required to create a new object each time they're invoked (immutable objects, flyweight pattern). - Unlike constructors, they can return an object of any subtype of their return type. - Unlike constructors, the class of the returned object can vary from call to call as a function of the input parameters. Effective Java even has advice for overloading: Item 52, "use overloading judiciously" > A safe, conservative policy is never to export two overloadings with the same number of parameters. I prefer stronger guidance for overloading that I'll paraphrase poorly from a forgotten source (Guava maybe): each overload should return pretty much the same thing and it should be obvious from the call site. The OP's article violates this principle since warnings should be distinct from errors.

karagenit 5y ago

Oh, absolutely! The problem was that different parameters were added at different times (by different developers), and they weren't careful enough to realize they were doing it incorrectly. Thanks for reading!