By trying to make a API method more generalized- you make it too generalized.
ULSAC Anti Pattern
Failed Façade Command Pattern Problem
By trying to make a API method more generalized- you make it too generalized
- Trying to prevent code change
- Failing to program to interface, in the sense if the implemented class changes it should signal failures else where in the code base.
Create well defined methods (and names) that explain the exact nature of the method.
Consequences and Resulting Context
- The complexity of the call gets embedded with in a parameter.
- API can’t be readily understood.
- Functionally Overloaded method
- Hard to change.
- Difficult API to use.
What's Wrong with the Solution
Consider the following API which contains self describing methods that can be readily understood and used.
If a scenario arises in which a developer tries to prevent the API exposed to change by creating an overly generalized method
void getX(…., String actionDesc)
in which the actionDesc contains some sort of internal pseudo language which determines the correct data to return. i.e.
call getCustomerNumber(…) gets replaced with call getX(….,”CustomerNumber”);
call getCustomerNumber(…)+ call getCustomerAddress(…) gets replaced with call getX(….,”CustomerNumber,CustomerAddress”);
Try not to make a single method be all things to everyone. Rely on programming to interface and contractible programming it allows.