What is the best way to design a sql query storage in java?

I've encountered a somewhat difficult design problem:

I'm currently writing an application that frequently requests data from a Postgres database. Some of these requests of course need parameters, some don't. Some have the same return type, some don't.

Now since I've started this project to essentially learn how to structure code efficiently and especially modular, I've come across the question on how to manage the storage of all these requests.

My current approach was the following:

I've set up an enum of enums, where each of these sub-enums implements a different interface, where each of these interfaces declares a method stub. These stubs differ in parameters and return type.

It looks something like this:

public enum Queries {
  ;
  public enum Queries_TypeA implements TypeAInterface {

    SOME_QUERY_A {
      @Override
      public double execute(String id, Date date) {

      }
    },

    SOME_OTHER__QUERY_A {
      @Override
      public double execute(String id, Date date) {

      }
    };
  },
  public enum Queries_TypeB implements TypeBInterface {

     SOME_QUERY_B {
      @Override
      public String execute() {

      }
    },

    SOME_OTHER__QUERY_B {
      @Override
      public String execute() {

      }
    };
  }
}

So if I wanted to get the results of, e.g. SOME_QUERY_A, I'd just do the following:

double result = Queries.QueriesTypeA.SOME_QUERY_A.execute("0", date1, date2);

This is just a small excerpt. I haven't fully implemented it yet and that's why I'm asking this question. In the overwritten methods, the actual query would happen and the result would be parsed and then returned, but as this is not important here, I didn't specify the implementation.

In reality, there would be a lot more of enums, sub enums and interfaces.

Is there a better solution to this (I'm sure there is), especially regarding scalability and modularity? Or is there some kind of state-of-the-art way on how to handle this type of problem?

I'm really looking forward to opinions and ideas.

Regards, adurx