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

Question

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

Конкретная группа этих служб имеет одну общую черту: они используют определенный ресурс в 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')); 
    } 
} 

Answer 1

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

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

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