Regra simples:se uma classe
extends outra, então essa classe é essa classe pai (apenas ligeiramente alterada ou estendida). Você pode passar essa classe filha em vez da classe pai. Exemplo:class Foo { }
class Bar extends Foo { }
function baz(Foo $foo) { }
baz(new Bar);
Isso funciona,
baz() espera um Foo mas também aceita uma Bar , porque Bar é a Foo . Agora, é seus
Users um Database ? Não. Seus usuários não são um banco de dados. Seus usuários usam um banco de dados. Se for o caso, você deve usar composição :class User {
protected $database;
public function __construct(Database $database) {
$this->database = $database;
}
}
Uma classe deve ser quais são suas responsabilidades são . A responsabilidade de uma classe de gerenciamento de usuários é gerenciar os dados do usuário. Parte disso pode envolver falar com um banco de dados, mas isso não significa que a classe de gerenciamento de usuários é um banco de dados. Se
User extends Database , isso significa que ele pode fazer tudo que o Database classe pode fazer (e mais). Isso significa que você pode usar o User class em todos os lugares em vez de o Database classe, e isso não faz o menor sentido. Mantenha as responsabilidades separadas. Agora, ainda é discutível se essa é a estrutura certa ou não, mas vai na direção certa. Mas você pode realmente querer ter um
User classe, que representa um usuário . Você então tem um UserManager ou UserORM ou UserStorage ou qualquer outra coisa, que se preocupe em recuperar e armazenar User objetos em um banco de dados. Esta classe, por sua vez, usa um Database para fazer exatamente isso. Isso mantém as responsabilidades claras e separadas. O User classe representa os dados do usuário, o Database classe interage com o banco de dados, o UserORM/Manager/whatever no meio negocia entre os dois. 
