Эта проблема часто встречается в моих проектах. Предположим, что в качестве примера у меня есть два интерфейса, один для получения информации из API и другой для анализа этой информации.
public interface APIClient {...}
public interface APIParser {...}
Теперь, возможно, мне понадобятся разные API, поэтому у меня будет много реализаций для APICLient
, но для каждой из этих реализаций потребуется свой APIParser
.
Это приведет к этому типу структуры
public class APIClientA implements APIClient {...}
public class APIParserA implements APIParser {...}
public class APIClientB implements APIClient {...}
public class APIParserB implements APIParser {...}
...
...
Итак, в общем, это будет означать, что каждый раз, когда я хочу добавить новый тип API, мне придется создавать несколько классов для одного и того же типа и убедиться, что они взаимодействуют только друг с другом, а не с реализация других типов API.
Это выглядит очень похоже на то, что предлагает шаблон проектирования моста, но этот шаблон позволит любому APIClient использовать любой APIParser (я прав?)
Итак, есть ли лучшее решение? Или, может быть, это нормально, и нет необходимости в его рефакторинге.
Также, возможно, parse - не то слово, извините, но я хотел сказать, что я проанализировал ответ JSON / XML, чтобы получить из него конкретную информацию. То, как я анализирую каждый ответ, зависит от структуры, предоставляемой каждым API, поэтому мне понадобятся разные «парсеры»
EDIT:
Я немного расширю эту идею. Существует класс клиента, который использует APIClient для выполнения запроса с заданным типом параметров. Как только запрос удовлетворен ответом JSON, клиент использует соответствующий APIParser для получения конкретной информации об ответе.
public class ClientClass {
...
json = APIClientTypeA.makeRequest(city, day, ...);
temperature = APIParserTypeA.getTemperature(json);
...
}
Проблема здесь в том, что клиент должен убедиться, что используется правильная реализация APIClient и APIParser (они должны совпадать)