Quantcast
Channel: Object Mentor Blog: Category Dean's Deprecations
Viewing all articles
Browse latest Browse all 46

Phantom (Menace) Dependencies

$
0
0

We’ve been working on new course materials lately. The other day we were discussing the bad dependencies in code that can occur when the Interface Segregation Principle (ISP) is violated.

We started calling these dependencies phantom dependencies. Here’s why…

In the simplest example of an ISP problem, several client components depend on a “server” component, but each uses completely independent facilities provided by that component. There are no direct or indirect connections between clients. So, none of the clients knows anything about the other clients, nor cares to, yet each client has an implicit dependency on the other clients.

Why? Because if a change in one client forces a change in the server component, the other clients are affected. At the very least, a rebuild may be required.

The solution is to hide the server component behind segregated interfaces, one tailored for each client, and have the server component implement those interfaces. Even better, if the features really are independent, then segregate the server component, too!

Anyway, we sometimes use the term back-channel dependency for this situation. However, while thinking about it, I remembered an article that I had read a few days before on the phantom pain phenomenon that amputees sometimes experience, where they feel pain in limbs that are no longer there. The ISP case is analogous; there is no traversable (“real”) connections from one client component to another, yet each “feels” the presence of the others. Hence, the term phantom dependency.


Viewing all articles
Browse latest Browse all 46

Latest Images

Trending Articles





Latest Images