In most examples of clean architecture (Android projects mostly, though) I've noticed that the use-case/interactor classes (units that encapsulate a feature) often share base class/interface, like here or here. Others do not (like here or here), instead allowing interactors to accept some parameters that are then used to execute some logic.Is either of these approach better than the other? I'm particularly interested in how parameterless approach handles use cases for something that requires user input for example - say we want to let user edit an entity and pass it to the server. We could inject the same entity into use case and whomever invokes it, but then it would have to be mutable, so that changes are reflected in both places. But then we can't create immutable models, which we may not want (because of threading issues etc). How to handle such case?Pardon me if I use the terms usecase/interactor incorrectly, but this is how they're used in Android land, which admittedly may be a bit behind on design patterns
Should use case/interactor `execute` method accept parameters
java;architecture