Also, the calls are very similar, just they act on...

# codereview

[ursus]

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]

Try googling "Interface Segregation Principle".

[ursus]

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]

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]

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]

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

[Alan Evans]

If it's a true interface, then just:

interface BigInterface: NewSubInterface1, NewSubInterface2, ... NewSubInterfaceN

[Alan Evans]

then depreciate BigInterface and slowly remove usages of it

[Alan Evans]

@Deprecated("Use specific interfaces")
interface BigInterface: NewSu....

[ursus]

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

[Davide Giuseppe Farella]

Usually you would have many services that converge in a single repository that diverges into multiple use cases.

[ AccountManager, LocationManager, FooManager, ... ] -> Repository 

Repository -> [ UpdateUserLocation, RenameUser, UpdateLocationFoo, ... ]

[Davide Giuseppe Farella]

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]

EditProfileFragment -> [ RenameUser, UpdateUserLocation, UpdateProfilePicture ] -> Repository -> [ UsersManager, PicturesManager, LocationsManager ]

[ursus]

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

[Davide Giuseppe Farella]

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

[Davide Giuseppe Farella]

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]

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

[Davide Giuseppe Farella]

This is pretty verbose, but rock solid 😁

[ursus]

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]

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

[Davide Giuseppe Farella]

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

[ursus]

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