Как должны взаимодействовать классы между собой?
==================================================

 Есть сервисный класс Service, который выполняет HTTP-запросы.  

  

Также есть класс Pagination, который настраивает параметры пагинации для запросов.  

  

Последний класс - это класс Filter, у него есть собственные поля, которые должны быть частью запроса.  

  

Должен ли я создать класс ConfigRequest, который зависит от класса разбивки на страницы и класса фильтра и остальных.  

  

Интересно, какие отношения должны быть между классами для настройки параметров http для службы, где находится метод get.  

  

Большое спасибо! 

 Я в чем-то согласен с Robur - данная схема классов больше напоминает карго-культ, классы сделаны по прниципу "шоб було". "У всех есть отношения и у меня будут!".  

От одного только названия "класса Service, который выполняет HTTP-запросы" хочется застрелиться. КАК, как вообще так можно, назвать класс, который делает HTTP запросы (причем, как я подозреваю, не любые вообще, а совершенно определённые), словом *Service*? Что должно быть в голове у человека, который, я не знаю, называет стакан для кефира словом "Штучка"?  

  

Но с его категорическим выводом я не согласен. Для практики в ООП и для лучшей структуризации кода разбивать его на классы можно и нужно. Но делать это надо с умом, а не тупо механически отрезая случайный кусок кода в отдельный класс.   

  

Поэтому для начала сделать два класса: класс, черт побери, HTTPRequest, который **выполняет НТТР запросы**, и класс для твоих запросов к конкретному сервису - с пагинацией, флагелляцией и что там у тебя ещё. **С названием, по которому можно понять, что он делает.** Потом посмотреть на этот класс, какие из его методов оказались очень раздуты, и подумать, какие из них можно вынести в отдельные классы. 

 Чтобы делать http запросы с фильтрами и пагинацией, вам достаточно одного класса Service. Иногда можно и одной функцией обойтись.   

  

Зачем вам все это, вы книжку по Java прочитали?  

Если все это рождается из конкретных условий и требований и это обоснованная сложность - напишите все это в вопросе.   

  

Если вам просто кажется что так правильно потому что вы знаете про SOLID, паттерны и ООП - то не стоит, любой инструмент нужен там где он нужен, эффективен и улучшает результат или процесс его получения а не там где абстрактно "так будет правильнее". 

 Тут нет единого верного решения как в математике. По сути если взять 10 разработчиков знающих solid, то все они выдадут 10 разных решений этой задачи, и все будут правы т.к ООП практики и solid - это просто рекомендации.   

  

Напиши исходник Service в виде единого класса, опубликуй здесь и послушай советы по улучшению.