# Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem

DevFeed: [Why Large Dependency-Injection Constructors Signal a Single-Responsibility Problem](<https://devfeed.tech/articles/the-forgotten-art-of-construction-25893.md>)

Original publisher: [Read original article](<https://proandroiddev.com/the-forgotten-art-of-construction-cfedc368e67f?source=rss-1331e67af4e1------2>)

Author: Danny Preussler

Published: 2020-06-22T17:39:16Z

Content type: opinion

Language: en

Sources: [Stories by Danny Preussler on Medium](<https://devfeed.tech/sources/stories-by-danny-preussler-on-medium.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [clean-code](<https://devfeed.tech/topics/clean-code.md>), [Dagger](<https://devfeed.tech/topics/dagger.md>), [koin](<https://devfeed.tech/topics/koin.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [clean-code](<https://devfeed.tech/tags/clean-code.md>), [code](<https://devfeed.tech/tags/code.md>), [code-smells](<https://devfeed.tech/tags/code-smells.md>), [constructor](<https://devfeed.tech/tags/constructor.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [koin](<https://devfeed.tech/tags/koin.md>), [kotlin](<https://devfeed.tech/tags/kotlin.md>)

## AI overview

The article argues that dependency-injection tools can hide overly large constructors. It presents large constructors as a code smell that may indicate a violation of the Single Responsibility Principle, and notes that they make classes harder to test.

## Source excerpt

How tools made us forget how to write sane constructors https://unsplash.com/photos/qvBYnMuNJ9A In an ideal world, developers get smarter every day. The code we write this year should be better than the code we wrote 10 years ago, which in turn should be better than the code 20 years ago. Today we have better tools, more modern languages, and better practices. But as often in life, we realize we are not living in that ideal world. In nearly every codebase I see today, there are things that would shock a developer two decades ago. I am speaking of what Mark Seemann called "Constructor Over Injection". We've all learned to inject our dependencies into constructors. And ideally use a tool for that like Spring or Dagger. If you look at some random classes from your codebase, how many fields are you injecting? Three? Five? More? I'm pretty sure you easily can find classes with even more, like this one: class ProfilePresenter @Inject constructor( @MainThreadScheduler private val mainScheduler: Scheduler, @IOScheduler private val ioScheduler: Scheduler, private val profileApi: ProfileApi, private val userRepository: UserRepository, private val analytics: Analytics, private val errorReporter: ErrorReporter private val referrerTracker: ReferrerTracker, private val shareTracker: ShareTracker, private val tracksRepository: TracksRepository, private val playlistRepository: PlaylistRepository ) If you would show this constructor to a developer from 20 years ago they would probably look at you as if you would be crazy. No one would want to call this constructor and provide all these parameters. But these days we don't care. We don't have to. We have a tool that will provide us with all those parameters, right? This does not make it right though! The proof If you would use some manual injection code or a service locator like Koin, you would notice more what's going on because you would need to write code like this: ProfilePresenter(get(), get(), get(), get(), get(), get(), get(),