Before giving my opinion and suggestion, it is better to apprehend the definition from the previous cases:
Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of. https://blog.codinghorror.com/code-smells/
with that quote in mind and assuming a simple logic of your proposal summed in an example:
TimeTable.java
public class TimeTable{ private int time1; private int time2; private List<Location> locations = new ArrayList<>(); //getters } SchedulerValidator.java
public class ScheduleValidator{ public List<Location> getLocationsByTime(int time){ //some logic } public List<Location> getLocationsByTime(int begin, int end){ //some logic } } The above snippet in any form, is a great example of a FeatureEnvy on top of that against SRP Violation
To stay clean and complaint, the below solution meets all criteria:
public class TimeTable{ private final int time1; private final int time2; private List<Location> locations = new ArrayList<>(); //constructor public List<Location> getLocationsByTime(int time){ //some logic } public List<Location> getLocationsByTime(int begin, int end){ //some logic } //getters } public class ScheduleValidator{ public void validate(int timeValue1, int timeValue2, TimeTable timeTable){ //some validation against user inputs, in case throws an exception } } public class ScheduleChecker(){ public void check(int userProvidedTime1, int userProvidedTime2, TimeTable timeTable){ //some validation against the time table list and user inputs } } //I assume this is where you will use all public class ScheduleController{ private final ScheduleValidator scheduleValidator; private final ScheduleChecker scheduleChecker; private final TimeTableRepository timeTableRepository; //constructor public String saveSchedule(int time1, int time2){ TimeTable timeTable = timeTableRepository.find(1L); scheduleValidator.validate(time1, time2, timeTable); scheduleChecker.check(time1, time2, timeTable); //no exceptions further business logic carries on after this line } } This example is also testable, you can simply mock all easily and write Unit and Integration Tests.
Last of all, my suggestion is to approach breaking requirements down :
- Validator: If you receive an input and test whether they have some dirty data entries,
- Checker: Checks whether given user input corresponds to your system data