# Slope-intercept library design

DevFeed: [Slope-intercept library design](<https://devfeed.tech/articles/slope-intercept-library-design-20972.md>)

Original publisher: [Read original article](<https://jakewharton.com/slope-intercept-library-design/>)

Published: 2022-04-05T00:00:00Z

Content type: opinion

Language: en

Sources: [Jake Wharton](<https://devfeed.tech/sources/jake-wharton.md>)

Topics: [Library](<https://devfeed.tech/topics/library.md>), [Picasso](<https://devfeed.tech/topics/picasso.md>), [Android](<https://devfeed.tech/topics/android.md>), [configuration](<https://devfeed.tech/topics/configuration.md>), [Dependency injection](<https://devfeed.tech/topics/dependency-injection.md>), [Scala](<https://devfeed.tech/topics/scala.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [dagger](<https://devfeed.tech/tags/dagger.md>), [dependency-injection](<https://devfeed.tech/tags/dependency-injection.md>), [http](<https://devfeed.tech/tags/http.md>), [jvm](<https://devfeed.tech/tags/jvm.md>), [library](<https://devfeed.tech/tags/library.md>), [picasso](<https://devfeed.tech/tags/picasso.md>)

## AI overview

The article proposes using slope-intercept form as a way to evaluate library design. The intercept represents the initial learning and setup cost, while the slope represents how complexity changes as requirements grow. It compares Picasso, Retrofit, and Dagger to show how libraries can trade a low initial barrier for steeper long-term complexity, or require more conceptual investment up front to remain easier to extend.

## Source excerpt

The equation y=mx+b defines a line in slope-intercept form. The line will intercept the y-axis at the value b and for each change in x its slope (the amount the line goes up or down) will change by m. Slope-intercept gives me a way to think about the design of libraries in relation to each other. The intercept is the initial cost of learning and setup for a library, and the slope is how the library's complexity changes over time. There's no real units here and the values are entirely subjective. Let's try it! Picasso Exactly 10 years ago today I introduced Picasso internally at Square. As an image loading library for Android, its primary selling point was a low intercept. It required no real configuration and only one line of code (even in a ListView adapter). Picasso.with(context).load("https://...").into(imageView); At the time this was a refreshing change from the existing libraries which required a lot of up-front and per-request configuration. The downside, however, was that as your needs grow the slope of complexity also grows faster than desired. Configuring the global instance, managing multiple instances, intercepting requests, and transforming images are all possible but more difficult than if the library was designed differently. Retrofit Retrofit is a declarative HTTP client abstraction for the JVM and Android. It requires configuration of a central object before you can use it to create instances of service interfaces. interface GitHubService { @GET("users/{user}/repos") Call<List<Repo>> listRepos(@Path("user") String user); } var retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .addConverter(MoshiJsonConverter.create()) .build(); var service = retrofit.create(GitHubService.class); This up-front configuration gives Retrofit a higher intercept on the y-axis. Exposure to these APIs gives you an entrypoint to discover functionality and encourages you to manage their lifetimes in an efficient way for your usage allowing the slope of com