Наличие двух классов для цели, которую вы описываете, не обязательно плохо. Вместо того, чтобы усложнять вещи, у вас есть два класса с именами, указывающими на цель их существования, один указывает, что это запрос, другой указывает, что это объект передачи. Это также позволит вам самостоятельно изменить свой внутренний дизайн и запросы.
Я не уверен, что полностью понял вторую часть об интерфейсах для классов обслуживания. Лично при принятии решения о создании интерфейса я использую несколько простых рекомендаций:
1: использовать интерфейсы для абстрагирования поведения или функциональности
2: это поведение меняется.
3: этот интерфейс используется в качестве контракта
Пример: рассмотрим поведение записи данных. Определим интерфейс
interface DataWriter {
void write()
}
Теперь вы можете определить одну или несколько реализаций этого, чтобы указать несколько вариантов поведения в зависимости от требований.
Если вам никогда не понадобится несколько вариантов поведения, вам может не понадобиться интерфейс.
Если вы разрабатываете классы, которые общаются, и если над ними работают несколько разработчиков, наличие интерфейса облегчает задачу, выступая в качестве контракта на общение.