Return to Question

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, which the original version never happens this. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version doesn't need to handle this, which I don't want to worry about adding a flow to handle this as it adds the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

Note: I'm not talking about avoiding "introduce parameter objects" in all cases: if the function already contains nullable parameters which I need to handle the null case, eg:

public void showInfo(String name, int age){
    if(name==null){
        //some error dialog
    }
}

I don't care to add a additional null handling to this:

public void showInfo(ShowInfoParameters showInfoParameters){
    if(showInfoParameters==null){
        //some error dialog
    }
    if(showInfoParameters.name==null){
        //some error dialog
    }
}

but at the case at top (showSchedule), the function originally have no nullable parameters, what I care is, it requires me to add null handlings to a function that originally doesn't need to handle null.

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, whereas with the original version this never happens. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version doesn't need to handle this, therefore I don't want to worry about adding a flow to handle this as it adds to the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

Note: I'm not talking about avoiding "introduce parameter objects" in all cases: if the function already contains nullable parameters which I need to handle the null case, eg:

public void showInfo(String name, int age){
    if(name==null){
        //some error dialog
    }
}

I don't care to add a additional null handling to this:

public void showInfo(ShowInfoParameters showInfoParameters){
    if(showInfoParameters==null){
        //some error dialog
    }
    if(showInfoParameters.name==null){
        //some error dialog
    }
}

but at the case at top (showSchedule), the function originally had no nullable parameters, what I care is, it requires me to add null handlings to a function that originally doesn't need to handle null.

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, which the original version never happens this. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version doesn't need to handle this, which I don't want to worry about adding a flow to handle this as it adds the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

Note: I'm not talking about avoiding "introduce parameter objects" in all cases, if the function already contains nullable parameters which need to handle the null case, eg:

public void showInfo(String name, int age){
    if(name==null){
        //some error dialog
    }
}

I don't care to add a additional null flow to this:

public void showInfo(ShowInfoParameters showInfoParameters){
    if(showInfoParameters==null){
        //some error dialog
    }
    if(showInfoParameters.name==null){
        //some error dialog
    }
}

but at the case above (showSchedule), the function originally have no nullable parameters, what I care is, it requires me to add null handling to a function that originally doesn't need to handle null.

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, which the original version never happens this. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version doesn't need to handle this, which I don't want to worry about adding a flow to handle this as it adds the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

Note: I'm not talking about avoiding "introduce parameter objects" in all cases: if the function already contains nullable parameters which I need to handle the null case, eg:

public void showInfo(String name, int age){
    if(name==null){
        //some error dialog
    }
}

I don't care to add a additional null handling to this:

public void showInfo(ShowInfoParameters showInfoParameters){
    if(showInfoParameters==null){
        //some error dialog
    }
    if(showInfoParameters.name==null){
        //some error dialog
    }
}

but at the case at top (showSchedule), the function originally have no nullable parameters, what I care is, it requires me to add null handlings to a function that originally doesn't need to handle null.

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, which the original version never happens this. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version don't need to handle this, which I don't want to worry about adding a flow to handle this as it adds the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

According to Should we avoid custom objects as parameters?, I know I can group related parameters to improve readability of the function, eg:

Original version:

public void showSchedule(long startDate,long endDate){
    //some code to display start date and end date
}

this.showSchedule(myStartDate,myEndDate);

"Introduce parameter objects" version:

public class ShowScheduleParameters{
    public long startDate;
    public long endDate;
}

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

ShowScheduleParameters showScheduleParameters=new ShowScheduleParameters();
showScheduleParameters.startDate=myStartDate;
showScheduleParameters.endDate=myEndDate;
this.showSchedule(showScheduleParameters);

which the object helps to display the name of parameters, reduce the chance of interchanging startDate and endDate like this.showSchedule(myEndDate,myStartDate); .

However, I found "Introduce parameter objects" version isn't perfect: I may pass null to showSchedule accidentally, which the original version never happens this. Although I can add a check to the function:

public void showSchedule(ShowScheduleParameters showScheduleParameters){
    if(showScheduleParameters==null){
        //some code to handle
    }
    long startDate=showScheduleParameters.startDate;
    long endDate=showScheduleParameters.endDate;
    //some code to display start date and end date
}

But in practice, the original version doesn't need to handle this, which I don't want to worry about adding a flow to handle this as it adds the complexity of the application. So I would rather keep the original version, is it the reason to avoid "introduce parameter objects"?

Note: I'm not talking about avoiding "introduce parameter objects" in all cases, if the function already contains nullable parameters which need to handle the null case, eg:

public void showInfo(String name, int age){
    if(name==null){
        //some error dialog
    }
}

I don't care to add a additional null flow to this:

public void showInfo(ShowInfoParameters showInfoParameters){
    if(showInfoParameters==null){
        //some error dialog
    }
    if(showInfoParameters.name==null){
        //some error dialog
    }
}

but at the case above (showSchedule), the function originally have no nullable parameters, what I care is, it requires me to add null handling to a function that originally doesn't need to handle null.