I'm working on a legacy system that has a helper class that is symbolically linked into many different .Net projects within a solution. The logic is riddled with compiler directives that change it's internal behavior based on which .Net project it happens to be compiled in. For instance, there's a compiler directive that interogates a "HAS_UI" variable and if true, compiles in a frmProgress instances and displays progress to the user.
I'm trying to explain to colleagues why this is a poor design by referencing specific anti-patterns. All I can come up with so far are "positive" patterns that should have been used, like the Single Responsibility Pattern or the Observer pattern.
Can anyone suggest specific anti-patterns that might apply here?