# Using Dependency inversion to avoid depending on volatile/heavy packages

**URL:** <https://discourse.julialang.org/t/using-dependency-inversion-to-avoid-depending-on-volatile-heavy-packages/74181>\
**Category:** General Usage\
**Tags:** package, dependencies\
**Created:** [January 7, 2022, 10:15am UTC](https://discourse.julialang.org/t/using-dependency-inversion-to-avoid-depending-on-volatile-heavy-packages/74181 "2022-01-07T10:15:56Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![bgctw](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bgctw/32/22050_2.png) [@bgctw](https://discourse.julialang.org/u/bgctw)\
**Post date:** [January 24, 2022, 8:02am UTC](https://discourse.julialang.org/t/using-dependency-inversion-to-avoid-depending-on-volatile-heavy-packages/74181/2 "2022-01-24T08:02:45Z")

</div>

After reading this [mulitple implementations answer](https://discourse.julialang.org/t/best-practice-to-support-multiple-implementations/74240/11) by @stevengj, I implemented a slightly more complex strategy. Using a type hierarchy allows the “interface” to comprise more than a single method.

I now have a method `optimize(f, ::AbstractDistributionFitOptimizer, lower, upper)` that calls the actual optimization routine. By specializing this method, different implementations can be used.  
Method [`DistributionFits.set_optimizer(::AbstractDistributionFitOptimizer)`](https://bgctw.github.io/DistributionFits.jl/dev/set_optimize/) configures the Optimizer used by the package.  
Again, Requires.jl is used to automatically set the default, if the Optim.jl package is in scope.

I am happy about critical feedback and advice on a Julian way of managing project dependencies in a way that higher-level code does not depend on lower-level code.

---

_[View the full topic](https://discourse.julialang.org/t/using-dependency-inversion-to-avoid-depending-on-volatile-heavy-packages/74181)._