Brief description of my project structure.

I have some base classes like BaseView, BasePresenter ... . Also my project consists of modules, module represents one complete part of the application.
Each module has it own Presenter, View ...
But also each module has it own Base<ModuleName>Presenter ..., where specific module requirements are defined.
At first I used separate file for all these classes, but then I found another approach, which seems interesting to me.

The idea is create Contract class\interface where all module specific base classes\interfaces are located.

Here is an example.

public interface StatisticsContract {

    interface View extends BaseView<Presenter> {

        void setProgressIndicator(boolean active);

        void showStatistics(int numberOfIncompleteTasks, int numberOfCompletedTasks);

        void showLoadingStatisticsError();

        boolean isActive();

    interface Presenter extends BasePresenter {



public interface ModesListContract {
    static abstract class Presenter extends BasePresenter {


    interface View extends BaseView {


Personally I find this useful to group all base classes in one place and this becomes sort of pattern - Contract. I know where all base interfaces for specific module are located. I also saw such approach in google android source code.

But on the other hand, this seems like a violation of Single Responsibility Principle and some other known practices.

So I am not sure if it is fine to use this approach or this is bad practice that should be avoid.

I would be grateful for any response.


1 Answer 1


The idea is create Contract class\interface where all module specific base classes\interfaces are located.

This indeed looks like a violation of ISP to me.

I understand that your application has a set of standardized modules, for which you want to have low-coupling and the ability to swap module implementation. If that is so, I would suggest to create Application/Contract/Modules namespace (package in case of Java), create a subnamespace there for each of the modules and place all module-specific interfaces into it.

All interfaces, that are shared by all (or the majority of the modules) should go to Application/Contract namespace / package.

If you place module interface definition to a module itself, you will face a problem with swapping implementation for it. Your new module will depend on an old one, because the old one contains interface definition.

  • Thank you for response, appreciate it. So you mean that it would be better to keep interfaces/abstract classes as a separate file, but create package where all these stuff will be kept. This approach will let someone or yourself understand the idea and purpose of the app just navigating through the bunch of interfaces ? Am I right ?
    – CROSP
    Dec 19, 2016 at 11:36
  • @CROSP I would put it this way: go with one class / interface per file to follow the principle of least surprise. Isolate interfaces / common parts of the app into separate namespaces inside the application core. Put implementations / specifics into your modules. And follow narrative coding principle. Your application should be able to be read like a book. File tree serving as a contents, README as a foreword, tests as INTRO. Dec 19, 2016 at 11:41
  • Thanks for answer, I got your idea. So it should look probably like this. app/base/module/userlist/ package/namespace for keeping abstract classes and interfaces for userlist module here ? Am I right ?
    – CROSP
    Dec 19, 2016 at 11:55
  • @CROSP Yes, I think so. The naming scheme is irrelevant of course. It may be app/general/plugin/userlist. But you got the idea right. Dec 19, 2016 at 11:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.