https://kotlinlang.org logo
Title
u

ursus

01/30/2019, 3:17 AM
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?
d

dave08

01/30/2019, 7:28 AM
Try googling "Interface Segregation Principle".
u

ursus

01/30/2019, 5:38 PM
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 ..
d

dave08

01/30/2019, 5:46 PM
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...
u

ursus

01/30/2019, 5:52 PM
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.
but I wanted to proxy the methods to sub implementations via composition, okay nevermind im rubber ducking, thanks
a

Alan Evans

01/30/2019, 8:05 PM
If it's a true
interface
, then just:
interface BigInterface: NewSubInterface1, NewSubInterface2, ... NewSubInterfaceN
then depreciate
BigInterface
and slowly remove usages of it
@Deprecated("Use specific interfaces")
interface BigInterface: NewSu....
u

ursus

01/30/2019, 8:16 PM
im just desiging it now -- well porting logic from ios and they have it like that, giant interface
d

Davide Giuseppe Farella

01/30/2019, 8:52 PM
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, ... ]
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.
EditProfileFragment -> [ RenameUser, UpdateUserLocation, UpdateProfilePicture ] -> Repository -> [  UsersManager, PicturesManager, LocationsManager ]
u

ursus

01/31/2019, 5:15 PM
Arent you just moving the issue to the use cases? now rename uses knows about everyting etc.
d

Davide Giuseppe Farella

01/31/2019, 5:43 PM
You're not moving any issue 😁 your just transforming a bunch of unorganized classes in a meaningful architecture
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 ) 
    } 
}
RenameUser will know everything as you said, but all the informations are incapsulated and RenameUser has only one reason to exist
This is pretty verbose, but rock solid 😁
u

ursus

01/31/2019, 7:48 PM
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
you re just moving the issue of datamanager knowing too much, from viewmodel to rename usecase
d

Davide Giuseppe Farella

01/31/2019, 8:04 PM
Yes, but the informations will be hidden in your domain layer, instead of inside the presentation one
u

ursus

01/31/2019, 9:33 PM
yea I understand, but its the same issue just different layers, imo