SOLID principles in practice: the Clean Architecture

SOLID principles in practice:
the clean architecture
Fabio Collini

@fabioCollini
linkedin.com/in/fabiocollini
github.com/fabioCollini
medium.com/@fabioCollini
codingjam.it
Android programmazione avanzata
Android Developers Italia
Ego slide

entitiesentities
Clean
architecture
S.O.L.I.D.
principles

./gradlew run —args=Firenze
Firenze (IT) - 25º min 4º max 29º
./gradlew run --args=Springfield
Springfield (US) - 8º min 4º max 27º
./gradlew run --args=sdfdsffdfdfds
No city found

class WeatherUseCase(
private val cityRetriever: CityRetriever,
private val repository: TemperatureRepository) {
suspend fun getCityData(s: String): String {
return try {
val cities = cityRetriever.findCity(s)
if (cities.isEmpty()) {
"No city found"
} else {
val city = cities.first()
val temperature = repository.getTemperature(city.id)
"$city - $temperature"
}0
} catch (e: Exception) {
"Error retrieving data: ${e.message}"
}1
}2
}3

return try {
"No city found"
} else {
}0
}1
}2
}3
Coroutines

return try {
"No city found"
} else {
}0
}1
}2
}3
Dependency Injection

class WeatherUseCaseTest {
val cityRetriever: CityRetriever = mockk()
val repository: TemperatureRepository = mockk()
val useCase = WeatherUseCase(cityRetriever, repository)
@Test
fun retrieveCityData() {
every { cityRetriever.findCity("Firenze") } returns
listOf(City(CITY_ID, "Firenze", "IT"))
coEvery { repository.getTemperature(CITY_ID) } returns
Temperature(10, 8, 20)
val cityData = runBlocking { useCase.getCityData("Firenze") }
assert(cityData).isEqualTo("Firenze (IT) - 10º min 8º max 20º")
}1
}2

interface TemperatureRepository {
suspend fun getTemperature(cityId: Int): Temperature
}7
interface CityRetriever {
fun findCity(name: String): List<City>
}6
return try {
"No city found"
} else {
}0
}1
}2
}3

}7
}6
class OpenWeatherTemperatureRepository(
private val api: WeatherApi
) : TemperatureRepository {
override suspend fun getTemperature(cityId: Int): Temperature {
val forecastDeferred = api.forecast(cityId)
val weather = api.currentWeather(cityId).await()
val temperatures = forecastDeferred.await().list.map { it.main }
return Temperature(
weather.main.temp.toInt(),
temperatures.map { it.temp_min }.min()?.toInt(),
temperatures.map { it.temp_max }.max()?.toInt()
)D
}E
}F
class JsonCityRetriever : CityRetriever {
private val allCities by lazy {
val text = javaClass.getResource("/cityList.json").readText()
Gson().fromJson<List<CityJson>>(text)
}A
override fun findCity(name: String): List<City> {
return allCities
.filter { it.name == name }
.map { City(it.id, it.name, it.country) }
.toList()
}B
}C

}A
return allCities
.toList()
}B
}C

return Temperature(
)D
}E
}F

}7
}6
return Temperature(
)D
}E
}F
}A
return allCities
.toList()
}B
}C
interface WeatherApi {
@GET("weather?appid=$OPEN_WEATHER_APP_ID&units=metric")
fun currentWeather(@Query("id") id: Int): Deferred<TemperatureWrapper>
@GET("forecast?appid=$OPEN_WEATHER_APP_ID&units=metric")
fun forecast(@Query("id") id: Int): Deferred<Forecast>
}Z

}Z

}Z
return Temperature(
)D
}E
}F
}7
}6
}A
return allCities
.toList()
}B
}C
return try {
"No city found"
} else {
}0
}1
}2
}3
suspend fun main(args: Array<String>) {
val api = RetrofitFactory.createService<WeatherApi>()
val weatherRepository = OpenWeatherTemperatureRepository(api)
val cityRetriever = JsonCityRetriever()
val useCase = WeatherUseCase(cityRetriever, weatherRepository)
val result = useCase.getCityData(args[0])
println(result)
}O

println(result)
}O

main
api
domain
weather
city
}Z
return Temperature(
)D
}E
}F
}7
}6
}A
return allCities
.toList()
}B
}C
return try {
"No city found"
} else {
}0
}1
}2
}3
println(result)
}O

Robert C. Martin Copyright (c) 2000 by Robert C. Martin. All Rights Reserved.
www.objectmentor.com 1
Design Principles and
Design Patterns
Robert C. Martin
www.objectmentor.com
What is software architecture? The answer is multitiered. At the highest level, there
are the architecture patterns that define the overall shape and structure of software
applications1
. Down a level is the architecture that is specifically related to the pur-
pose of the software application. Yet another level down resides the architecture of
the modules and their interconnections. This is the domain of design patterns2
, pack-
akges, components, and classes. It is this level that we will concern ourselves with in
this chapter.
Our scope in this chapter is quite limitted. There is much more to be said about the
principles and patterns that are exposed here. Interested readers are referred to
[Martin99].
Architecture and Dependencies
What goes wrong with software? The design of many software applications begins as
a vital image in the minds of its designers. At this stage it is clean, elegant, and com-
pelling. It has a simple beauty that makes the designers and implementers itch to see it
working. Some of these applications manage to maintain this purity of design through
the initial development and into the first release.
But then something begins to happen. The software starts to rot. At first it isn’t so
bad. An ugly wart here, a clumsy hack there, but the beauty of the design still shows
through. Yet, over time as the rotting continues, the ugly festering sores and boils
accumulate until they dominate the design of the application. The program becomes a
festering mass of code that the developers find increasingly hard to maintain. Eventu-
1. [Shaw96]
2. [GOF96]

Single responsibility
“A class should have one, and only one,
reason to change”

api
domain
weather
city
}Z
return Temperature(
)D
}E
}F
}7
}6
}A
return allCities
.toList()
}B
}C
return try {
"No city found"
} else {
}0
}1
}2
}3
main
println(result)
}O

Open closed
“You should be able to extend a classes
behavior, without modifying it”

Liskov substitution
“Derived classes must be substitutable
for their base classes”

open class Rectangle(
open var width: Int,
open var height: Int
) {
fun area() = width * height
}
class Square(size: Int) : Rectangle(size, size) {
override var width: Int = size
set(value) {
field = value
if (height != value)
height = value
}
override var height: Int = size
set(value) {
field = value
if (width != value)
width = value
}
}

var rectangle = Rectangle(2, 3)
var initialArea = rectangle.area()
rectangle.width *= 2
println(initialArea * 2 == rectangle.area())
rectangle = Square(2)
initialArea = rectangle.area()
rectangle.width *= 2
println(initialArea * 2 == rectangle.area())

Interface segregation
“Make ﬁne grained interfaces
that are client speciﬁc”

Dependency injection?
Inversion of control?

Dependency inversion
“Depend on abstractions,
not on concretions”

main
println(result)
}O
api
domain
weather
city
}Z
return Temperature(
)D
}E
}F
}7
}6
}A
return allCities
.toList()
}B
}C
return try {
"No city found"
} else {
}0
}1
}2
}3

Dependency inversion
“High level modules should not depend
upon low level modules. Both should
depend upon abstractions”

domain city
}6
}A
return allCities
.toList()
}B
}C
return try {
"No city found"
} else {
}0
}1
}2
}3

domain city
return try {
"No city found"
} else {
}0
}1
}2
}3
}6
}A
return allCities
.toList()
}B
}C

domain city
class WeatherUseCase
interface CityRetriever class JsonCityRetriever : CityRetriever
domain
city
class WeatherUseCase interface CityRetriever
class JsonCityRetriever : CityRetriever

“I declare an interface just
to implement dependency inversion or
when there are multiple implementations”
Anonymous at Droidcon London

“Declare an interface only
to implement a S.O.L.I.D. principle”

main
println(result)
}O
api
domain
weather
city
}Z
return Temperature(
)D
}E
}F
}7
return try {
"No city found"
} else {
}0
}1
}2
}3
}6
}A
return allCities
.toList()
}B
}C

city
entities
main
weather
api
domain

city
entities
main
weather
api
domain
city
entities
main
weather
api
domain

city
entities
main
weather
api
domain
repository
entities
UI
data source
domain

repository
entities
UI
data source
domain
entitiesentitiesentitiesentities
domain
repository
UI
data source
presenter

Prosentitiesentitiesentitiesentities
domain
repository
UI
data source
presenter

Framework
independence
domain
repository
UI
data source
presenter

Architecture
Vs
code conventions
domain
repository
UI
data source
presenter

TDDentitiesentitiesentitiesentities
domain
repository
UI
data source
presenter

Consentitiesentitiesentitiesentities
domain
repository
UI
data source
presenter

More codeentitiesentitiesentitiesentities
domain
repository
UI
data source
presenter

Architecture Vs
code conventions
TDD
Pros
Cons
More code
Framework
independence
domain
repository
UI
data source
presenter

Links
Demo Project
github.com/fabioCollini/CleanWeather
2000 - Robert C. Martin - Design Principles and Design Patterns
www.cvc.uab.es/shared/teach/a21291/temes/object_oriented_design/
materials_adicionals/principles_and_patterns.pdf
2005 - Robert C. Martin - The Principles of OOD
butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
2012 - Robert C. Martin - The Clean Architecture
8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

SOLID principles in practice: the Clean Architecture

Recommended

More Related Content

What's hot (20)

Similar to SOLID principles in practice: the Clean Architecture (20)

More from Fabio Collini (20)

Recently uploaded (20)

SOLID principles in practice: the Clean Architecture