Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Инверсия зависимости от HttpClient #3

Open
Anton3 opened this issue Dec 1, 2018 · 1 comment
Open

Инверсия зависимости от HttpClient #3

Anton3 opened this issue Dec 1, 2018 · 1 comment

Comments

@Anton3
Copy link

Anton3 commented Dec 1, 2018

Цель HttpClient должна быть - не описать самый крутой интерфейс HTTP-клиента, подходящий для любых целей (здесь нам не догнать существующих гигантов), а описать минимальный интерфейс, который нужен для работы ВК-клиента. Так же, как в Java VK API интерфейс TransportClient - минимальный интерфейс, который не претендует на общезначимость.

interface TransportClient {
    fun get(String url): ClientResponse
    fun post(String url, String body): ClientResponse
    fun post(String url, String fileName, File file): ClientResponse
    fun post(String url, String body, String contentType): ClientResponse
    fun get(String url, String contentType): ClientResponse
    fun post(String url): ClientResponse
    fun delete(String url): ClientResponse
    fun delete(String url, String body): ClientResponse
    fun delete(String url, String body, String contentType): ClientResponse
}

Можно взять его и добавить везде suspend. Такой интерфейс реализовать намного проще, чем тот, который сейчас лежит в common-http-client. Далее, HttpClient нужно переименовать во что-нибудь, ясно выражающее узкую специализацию. Сам интерфейс должен переехать в kotlin-vk-api, а вот его тривиальная реализация на Jre должна остаться в common-http-client.

@alatushkin
Copy link
Owner

Пока не совсем понимаю в чем именно будет выигрыш от такого изменения интерфейса + в чем такая реализация "намного проще".

При этом интерфейс в том виде в котором есть сейчас - допускает добавление нового поведение через компактную функциональную композицию. Причем делать это не затрагивая каждую конкретную реализацию клиента (код которой уже "протестирован") + не зашумляя его при чтении.
Хитрое логгирование, тротлинг, политика ретраев и таймаутов, которую не надо повторно реализовывать в каждом клиенте, кеширование - всё это гораздо компактнее реализуется когда интерфейс допускает функциональную композицию. VkMethodExecuter устроен аналогично по тем же причинам.
И чтобы отказаться от этого удобного подхода нужна веская причина.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants