Interface attributes over method import parameters

I have a requirement of generating different report formats. It can be FLAT file format, PIVOT format or a some kind of different format and export to XLS (for now). During generation, how data is read, output structure is created, how values are bind to columns and how it is exported (XLS) is changing. I am trying to use strategy design pattern due to different behaviours of each report format, but interface parameters won't be used always. Is it a good approach to use them as variables only instead of parameters? So we have 4 main components;

1 - Data read from DB (it is either based on a config table where selections are stored, or it can be just by selection parameters without the need of config table)

2- Create output columns. (it is either based on config table where columns and datatypes are mentioned or a hardcoded output format specific to output format )

3- Column binding. (It should bind data from source table to target table where target table is created in point 2 ).

4- Generate XLS.

I created interface for each point. Also i had a confusion here, since some parameters are optional, should i declare as variable in interface and set them with a set_variable method or use as optional import parameter ?

1- DATAREADER_IF : it takes optional CONFIG_ID as parameter. There are 2 implementations of it. DATAREADER_BY_CONFIG or DATAREADER_BY_SEL . In config class, it uses the optinal parameter config_id to read from the config table and read source data based on config data. DATAREADER_BY_SEL using a parameter table IT_SEL where it contains selection conditions.

2)TABLECREATOR_IF: it takes another TABLE_CONFIG_ID parameter to populate output columns based on a config table. (lets say 40 columns) There are 2 implementations, either by config_id or a hardcoded table structure for a specific output format. Hardcoded implementation is for a format where we know it will never change and no need for dynamic . Hardcoded one can call another TABLECRETOR_IF implementation inside it. Because 80% of binding can be done via one of the implementations.

3) COLBINDER_IF : this is somekind of mapping. it takes source table, TABLE_BIND_ID as parameter creates a target format using tablecreator_if and starts moving values from source to target.

4) XLS_IF : for XLS wwriting.

sorry my code is not in java but will try to show in java syntax;

interface DATAREADER_IF {
  public Object[] READ(int iv_config_id OPTIONAL, string[] it_sel); // optional iv_config_id parameter
}
class DATAREADER_CFG implements DATAREADER_IF {
public Object[] READ(iv_config_id,it_Sel) {
// get table config by using IV_CONFIG_ID
//generate table and return dynamic array[].
}}

class DATAREADER_SEL implements DATAREADER_IF {
public Object[] READ(iv_config_id,it_Sel) {
// read data by using iT_SEL and return array[]
}}

and table creator;

interface TABLECREATOR_IF {
  public Object[] CREATE(int iv_table_id OPTIONAL); // optional iv_config_id parameter
}

class TABLECREATOR_CFG implements TABLECREATOR_IF {
public Object[] CREATE(iv_table_id) {
// get table config by using IV_TABLEID_ID
//generate table and return dynamic array[].
}}


class TABLECREATOR_TYPE1 implements TABLECREATOR_IF {
public Object[] CREATE(iv_table_id) {
//generate table and return dynamic array[].
}}

and column binder;

interface COLBINDER_IF {
  public Object[] BIND(object[] IT_DATA,int IV_TABLE_BIND_ID optional); // optional IV_TABLE_BIND_ID parameter
}

class COLBINDER_CFG implements COLBINDER_IF {
public Object[] CREATE(IT_DATA, IV_TABLE_BIND_ID) {
// get table config by using IV_TABLE_BIND_ID
// bind to a new array based on config
// return new array
}}


class COLBINDER_TYPE1 implements COLBINDER_IF {
public Object[] CREATE(IT_DATA, IV_TABLE_BIND_ID) {
// call COLBINDER_CFG implementation here, it will auto-bind 80% of columns.
// additional column binding here
// return new array
}}

XLS part for now not much important but, even above approach works fine i feel something are wrong with so many optional parameters. Do you have any suggestions ? I am trying to follow strategy design pattern here, but for my rest of the code, there is no any optional parameter during interface usage, but this report generation has so many conditions, i just don't like optional in interface.