Насколько плохо использовать черту вместо наследования или композиции в этом случае для повторного использования кода?

У меня есть набор служб, которые расширяют общий класс, который обеспечивает некоторые общие функции между ними.

У определенной группы этих сервисов есть одна общая черта: они используют определенный ресурс в API, поэтому у них много общего кода (для подключения к API и выполнения некоторого GET или POST, применяя требования API, в основном). изменение конечной точки и количества параметров для передачи).

Мой вопрос, это плохо, чтобы абстрагировать этот код по признаку? и повторно использовать его в любых службах, которым требуется использовать этот конкретный фрагмент кода?

Вот несколько примеров:

trait ApiResource {
public function retrieve()
{
try {
// apply logic of the resource
} catch (\Exception $e) {
return false;
}
}
}

class Departments extends Generic {
use ApiResource;

public function createCache(Cache $cache)
{
$cache->storeDepartments($this->retrieve('departments', 200));
}
}

class Brands Generic {
use ApiResource;

public function createCache(Cache $cache)
{
$cache->storeBrands($this->retrieve('brands'));
}
}

3

Решение

Включая это как черта не по существу неправильно (каламбур), но я думаю, что это было бы более логичным, чем абстрактный класс, с помощью которого Generic расширяется или даже просто включен в Generic,

Предположительно этот метод будет применяться ко всем вашим ApiResourcesс, но это будет только когда-либо применять к вашему ApiResources — он не будет использоваться ни для какого другого класса. Так ApiResourceы должны просто наследовать это нормально.

Черты, как правило, используются для одного класса для наследования методов от нескольких источников или нескольких несвязанных классов для наследования метода — ни один из них, похоже, не имеет место здесь. Я видел очень мало случаев, для которых эти черты полезны, и, похоже, это не один из них.

2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector