Refactoring to the Repository Pattern

preview_player
Показать описание

So instead of measuring I ended up refactoring, migrating from MutableList to a repository object that is much more amenable to implementation with a database, even if in the tests we still actually hold data in an ArrayList.

In this episode

* 00:00:44 Our current model is MutableList of Customer
* 00:02:09 REST is also a model
* 00:02:49 Fixing the response for an empty list
* 00:04:46 What is the problem with MutableList?
* 00:05:40 Start by introducing a typealias for MutableList of Customer
* 00:07:12 Now make the type alias an interface
* 00:08:31 IntelliJ import bug
* 00:10:44 We can't serialize our custom type, but we can sidestep
* 00:11:58 Implement findById
* 00:15:00 Implement addCustomer
* 00:16:08 Implement deleteById
* 00:17:09 Now make Customers not a List
* 00:17:21 Lean on the compiler to find issues
* 00:17:36 Distinguishing between production and test operations
* 00:20:36 Some final tidying and conveniences
* 00:22:47 Customers now lets us see the operations we are using
* 00:23:17 There is a problem with suspend though
* 00:23:58 that we'll punt into next week

Рекомендации по теме
Комментарии
Автор

Unfortunately I don't think there is a way to abstract over suspend and non suspend methods: once you go `suspend` then everything needs to `suspend`. I worked on a codebase some time ago that dealt with this and we just decided to always make interfaces suspend since once an implementation needs it then you're screwed. I guess this is the famous "function coloring" problem.

valcron-