Also the calls are very similar just they act on different d

Question

Also the calls are very similar just they act on different domains think CRUD account CRUD message etc does it even make sense to break it up to AccountCrud er etc to keep the interface file shorter

dave08 · Answer

Try googling Interface Segregation Principle

ursus · Answer

Okay I did it says exactly what I wanted to do breaking ChanelManager interface into AccountCrud FooCrud etc my question was if I should join those interfaces into ChannelManager Google showed me examples of breaking apart ByteUtils with functions of read write trim into Reader Writer Trimmer but then composition ReaderWriter Reader Writer so I dont know now

dave08 · Answer

Depends on who s going to use it If all those that use this dependency need all functionality make one big one otherwise make smaller ones

ursus · Answer

Most likely each UI will need only certain subset Now Im wondering if it makes difference to provide it as multiple dependencies to the UI like AccountManager FooManager interfaces etc but both references would be singleton class DataManager AccountManager FooManager This way I can keep threads processing queues only in DataManager not share them between the sub interfaces implementations etc

ursus · Answer

but I wanted to proxy the methods to sub implementations via composition okay nevermind im rubber ducking thanks

Alan Evans · Answer

If it s a true `interface` then just ``` interface BigInterface NewSubInterface1 NewSubInterface2 NewSubInterfaceN ```

Alan Evans · Answer

then depreciate `BigInterface` and slowly remove usages of it

Alan Evans · Answer

``` Deprecated Use specific interfaces interface BigInterface NewSu ```

ursus · Answer

im just desiging it now well porting logic from ios and they have it like that giant interface

Davide Giuseppe Farella · Answer

Usually you would have many services that converge in a single repository that diverges into multiple use cases ``` AccountManager LocationManager FooManager gt Repository Repository gt UpdateUserLocation RenameUser UpdateLocationFoo ```

Davide Giuseppe Farella · Answer

In that way every UI components will have only the strictly needed few use cases without knowing on which source they re interacting with which they shouldn t care about

Davide Giuseppe Farella · Answer

`EditProfileFragment gt RenameUser UpdateUserLocation UpdateProfilePicture gt Repository gt UsersManager PicturesManager LocationsManager `

ursus · Answer

Arent you just moving the issue to the use cases now rename uses knows about everyting etc

Davide Giuseppe Farella · Answer

You re not moving any issue grin your just transforming a bunch of unorganized classes in a meaningful architecture

Davide Giuseppe Farella · Answer

Basically your use cases will be functions let me explain you ``` interface RenameUser operator fun invoke userId String newName String class UserEditorView private val renameUser RenameUser fun rename newName renameUser currentUser id newName ```

Davide Giuseppe Farella · Answer

RenameUser will know everything as you said but all the informations are incapsulated and RenameUser has only one reason to exist

Davide Giuseppe Farella · Answer

This is pretty verbose but rock solid grin

ursus · Answer

by moving the issue I mean if you stick a dependency into a viewmodel that has a dependency on DataManager instead of viewmodel having dependency on DataManager

ursus · Answer

you re just moving the issue of datamanager knowing too much from viewmodel to rename usecase

Davide Giuseppe Farella · Answer

Yes but the informations will be hidden in your domain layer instead of inside the presentation one

ursus · Answer

yea I understand but its the same issue just different layers imo