# Sub-dependencies { #sub-dependencies }

You can create dependencies that have **sub-dependencies**.

They can be as **deep** as you need them to be.

**FastAPI** will take care of solving them.

## First dependency "dependable" { #first-dependency-dependable }

You could create a first dependency ("dependable") like:

{* ../../docs_src/dependencies/tutorial005_an_py310.py hl[8:9] *}

# Global Dependencies { #global-dependencies }

For some types of applications you might want to add dependencies to the whole application.

Similar to the way you can [add `dependencies` to the *path operation decorators*](dependencies-in-path-operation-decorators.md){.internal-link target=_blank}, you can add them to the `FastAPI` application.

In that case, they will be applied to all the *path operations* in the application:

# Advanced Dependencies { #advanced-dependencies }

## Parameterized dependencies { #parameterized-dependencies }

All the dependencies we have seen are a fixed function or class.

But there could be cases where you want to be able to set parameters on the dependency, without having to declare many different functions or classes.

Let's imagine that we want to have a dependency that checks if the query parameter `q` contains some fixed content.

# Testing Dependencies with Overrides { #testing-dependencies-with-overrides }

## Overriding dependencies during testing { #overriding-dependencies-during-testing }

There are some scenarios where you might want to override a dependency during testing.

You don't want the original dependency to run (nor any of the sub-dependencies it might have).

In the same way, you can use `finally` to make sure the exit steps are executed, no matter if there was an exception or not.

{* ../../docs_src/dependencies/tutorial007.py hl[3,5] *}

## Sub-dependencies with `yield` { #sub-dependencies-with-yield }

You can have sub-dependencies and "trees" of sub-dependencies of any size and shape, and any or all of them can use `yield`.

# Classes as Dependencies { #classes-as-dependencies }

Before diving deeper into the **Dependency Injection** system, let's upgrade the previous example.

## A `dict` from the previous example { #a-dict-from-the-previous-example }

In the previous example, we were returning a `dict` from our dependency ("dependable"):

{* ../../docs_src/dependencies/tutorial001_an_py310.py hl[9] *}

The *path operation decorator* receives an optional argument `dependencies`.

It should be a `list` of `Depends()`:

{* ../../docs_src/dependencies/tutorial006_an_py39.py hl[19] *}

These dependencies will be executed/solved the same way as normal dependencies. But their value (if they return any) won't be passed to your *path operation function*.

* All these *path operations* will have the list of `dependencies` evaluated/executed before them.
    * If you also declare dependencies in a specific *path operation*, **they will be executed too**.
    * The router dependencies are executed first, then the [`dependencies` in the decorator](dependencies/dependencies-in-path-operation-decorators.md){.internal-link target=_blank}, and then the normal parameter dependencies.

You can define dependencies that in turn can define dependencies themselves.

In the end, a hierarchical tree of dependencies is built, and the **Dependency Injection** system takes care of solving all these dependencies for you (and their sub-dependencies) and providing (injecting) the results at each step.

    - tutorial/body-updates.md
    - Dependencies:
      - tutorial/dependencies/index.md
      - tutorial/dependencies/classes-as-dependencies.md
      - tutorial/dependencies/sub-dependencies.md
      - tutorial/dependencies/dependencies-in-path-operation-decorators.md
      - tutorial/dependencies/global-dependencies.md
      - tutorial/dependencies/dependencies-with-yield.md
    - Security: