4

Let's say you have a library StuffDoer which calls an external library MagicWizard to do its stuff. Then you add a reference to StuffDoer in UsefulApp.

In some scenarios, referencing StuffDoer requires UsefulApp to reference MagicWizard directly (it "leaks"), while in some scenarios, it does not. I think in .NET it depends on whether or not the public API of StuffDoer makes reference to MagicWizard's types, or if they are only referenced in private code?

So my question is, what do you call the reference in these scenarios?

I've been thinking some good names for the type of reference that "leaks" might be "transitive reference" or "external reference". And some good names for the type of reference that doesn't "leak" might be "nontransitive reference" or "internal reference".

Are there established terms to describe these types of references? I'd like to be on the same page as everyone else, of course! 🙂

Improve this question
3
  • 3
    This seems relevant but I'm not sure if the term '(non-)leaky abstractions' fits what you are looking for. Commented Jan 29, 2021 at 17:25
  • 1
    I thin you would say the reference "exposes its internals" Commented Jan 29, 2021 at 17:35
  • Not exactly what you're asking for, but the terms leaky abstration and encapsulation are relevant to this kind of discussion. Commented Jan 31, 2021 at 10:33

3 Answers 3

Reset to default
3

The term of indirect dependency may be used to accurately describe this kind of dependencies. It opposes to direct dependency.

Sometimes it’s called chained dependency. However, the term is more ambiguous, since there can be a chain without necessary having a leak.

Improve this answer
2
  • 1
    "Indirect dependency" also refers more generally to your dependencies' dependencies (and further out), regardless of whether or not they leak. Commented Jan 29, 2021 at 20:17
  • @AlexReinking exactly! “leak” suggests something negative and undesired. “indirect” is completely neutral. It may create an undesired coupling, but on the other side in some cases, it can be an unavoidable consequence of componentization (as suggested in the detailed description of the facade in GoF). Commented Jan 29, 2021 at 20:32
0

If you tried to run UsefulApp without having installed MagicWizard.dll in its folder (or probing path or GAC), it wouldn't work. Therefore it is called a "dependency." You have to have it. Whether or not it is referenced, you still have to have it.

The only time you'd need to set a reference is if you wanted to use its types, which can happen if StuffDoer uses its types in its public interface. But UsefulApp might also use its types directly. In either case, MagicWizard.dll would then become a "referenced assembly."

If you have a dependency and you don't set a reference to it, it is an "unreferenced dependency."

Improve this answer
-1

I would probably call the "leaky" dependencies exposed and the "non-leaky" ones internal or private. I don't think there's any standardised terminology for this distinction yet.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.