Я бы решил эту проблему, создав новый класс или структуру данных, которая будет инкапсулировать всю логику проверки и генерации URL, а затем использовать ее везде, где мне это нужно.
Вот пример класса.
class HeadLineParameters
{
private $params = [];
public function setQuery($query)
{
// validate/transform query data
$this->params['q'] = urlencode($query);
return $this;
}
public function setCategory($category)
{
// validate/transform category data
$this->params['category'] = $category;
return $this;
}
public function generateUrl()
{
return http_build_query( $this->params );
}
}
$params = new HeadLineParameters;
$params->setQuery($query)
->setCategory($category);
Вы просто передаете один аргумент и знаете, что это просто экземпляр HeadLineParameters.
$class->get_top_headlines($params);
Это решение не загрязняет ваш текущий класс ненужными состояниями или полями. Это легко проверить, и у него есть только одна работа. Вы можете легко расширять его, устанавливать значения по умолчанию, вы также можете проверять его по своему усмотрению.
Редактировать: Почему вы не должны добавлять больше полей в текущий класс?
Если вы добавите больше полей в ваш текущий класс, вы нарушите принцип единой ответственности, и любой метод этого класса также может изменить эти поля. Это не должно быть проблемой, если эти поля действительно принадлежат там, и для них требуется больше методов. Это нормально, если вы используете ООП.
Я не уверен, что другие люди думают о передаче связанных массивов в функции, но с ними трудно справиться, если у вас нет доступной документации. У меня были проблемы с ними при чтении какого-либо внешнего кода, и большую часть времени я не был уверен, с какими данными я имел дело.