ULSAC

by trying to make a api method more generalized- you make it too generalized.
anti-pattern name:
ulsac anti pattern
aliases:
failed façade command pattern problem
context
by trying to make a api method more generalized- you make it too generalized
forces
– trying to prevent code change
– failing to program to interface, in the sense if the implemented cl-ss changes it should signal failures else where in the code base.
solution
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.

void getcustomernumber(…);
void getcustomeraddress(…);
void getcustomertelephone(…);

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”);
lesson’s learned
try not to make a single method be all things to everyone. rely on programming to interface and contractible programming it allows.
correct patterns
author(s):
john wilson
date:
01/01/2009
references
keywords:
example