Resumo da Aula 7

Sumário

• Herança: derivação de classes
  • Herança pública: relação é um
    • Primeira tentativa de solução do dilema
    • Segunda tentativa
    • Solução
  • Construtores, construtores por omissão e cópia e atribuição por cópia
  • Ocultação
  • Hierarquias de classes
  • Problemas por resolver
  • Herança privada: redução/alteração de interfaces
  • Políticas de acesso
• Leitura Recomendada
• Referências

1  Herança: derivação de classes

Suponha-se que se pretendia construir uma aplicação para gestão do pessoal duma empresa.  Uma primeira análise do problema poderia levar à identificação de várias classes de empregado: empregados normais, secretários, chefes, motoristas, chefes dos motoristas, etc.  A mesma análise poderia indicar que a informação a guardar para um empregado normal consistia, para simplificar, apenas em nome e sexo.  Todas as outras classes de empregados possuiriam essa mesma informação adicionada de informação específica.  Por exemplo, para os secretários seria necessário guardar uma referência para o respectivo chefe, para os motoristas uma referência para os veículos à sua guarda, para os chefes informação sobre o nível de chefia e sobre o respectivo departamento, incluindo por exemplo uma lista de referências para os respectivos subordinados.  A análise de problemas desta índole leva também frequentemente à conclusão de que as várias classes identificadas estão relacionadas entre si.  Por exemplo, um chefe é um empregado (embora nem todos os empregados sejam chefes), um secretário é um empregado, um motorista é um empregado, um chefe dos motoristas é um motorista e é um chefe também, etc.

Esta relação é um é extremamente importante e deve ser claramente distinguida da relação tem um (ou é composto por um).  Por exemplo, é claro que um humano é composto, entre outras partes, por um coração, e pode ter, por exemplo, um anel.  Mas um humano, na mesma acepção, não é um coração, tal como não é um anel.  O mesmo se passa, por exemplo, com uma turma de uma universidade.  Uma turma tem um conjunto de alunos, tal como tem um nome, um delegado, etc.  Uma turma não é simplesmente um conjunto (ou lista) de alunos.  Esta diferença deve ser estabelecida mesmo em casos em que as classes identificadas parecem ter apenas um item de informação.  No âmbito de um projecto, por exemplo, as tarefas a realizar podem consistir inicialmente apenas numa duração.  Mas isso não significa que uma tarefa é uma duração.  Uma tarefa tem uma duração, tal como poderá vir a ter outros tipos de informação no futuro.

A relação é um que se referiu é na realidade apenas a forma habitual de referir uma relação mais particular: pode substituir um ou pode ser tratado como um.  É que, na linguagem corrente, também se usa a expressão "é um" para denotar a pertença a uma classe.  Por exemplo, pode-se dizer que o Sr. Fulano é um chefe.  Em C++ isso significaria que fulano seria uma instância da classe Chefe.  Mas a relação é um a que se alude nesta secção é uma relação entre classes, e não entre objectos e as respectivas classes!  Assim, é mais preciso dizer que "um chefe pode substituir um empregado" ou que "um chefe pode se tratado como um empregado".  Normalmente não se usam estas expressões, mas apenas porque elas são demasiado longas e pesadas.

Como se representam relações é um em C++? O que se ganha com esse tipo de relação?  É o assunto da próxima secção.

1.1  Herança pública: relação é um

1. Usa-se uma única classe Empregado, admitindo-se que empregados com nível de chefia zero (0) são empregados normais.
2. Usam-se duas classes.

A utilização de várias classes parece portanto ser melhor solução.  Seja então a classe Empregado*:

class Empregado {
  public:
    Empregado(string const& nome, Sexo sexo);

    string const& nome() const;
    Sexo sexo() const;
    void mostra() const;

  private:
    string nome_;
    Sexo sexo_;
};

inline Empregado::Empregado(string const& nome, Sexo sexo)
    : nome_(nome), sexo_(sexo) 
{
}

inline string const& Empregado::nome() const 
{
    return nome_;
}

inline Sexo Empregado::sexo() const 
{
    return sexo_;
}

inline void Empregado::mostra() const 
{
    cout << "Nome: " << nome() << endl
         << "Sexo: " << sexo() << endl;
}

class Chefe {
  public:
    Chefe(string const& nome, Sexo sexo, int nível);

    string const& nome() const;
    Sexo sexo() const;
    int nível() const;
    void mostra() const;

  private:
    string nome_;
    Sexo sexo_;
    int nível_;
};

inline Chefe::Chefe(string const& nome, Sexo sexo, int nível)
    : nome_(nome), sexo_(sexo), nível_(nível) 
{
}

inline string const& Chefe::nome() const 
{
    return nome_;
}

inline Sexo Chefe::sexo() const 
{
    return sexo_;
}

inline int Chefe::nível() const 
{
    return nível_;
}

inline void Chefe:: mostra() const 
{
    cout << "Nome: " << nome() << endl
         << "Sexo: " << sexo() << endl
         << "Nível: " << nível() << endl;
}

O segundo problema é que não há qualquer tipo de relação, do ponto de vista da linguagem C++, entre as duas classes definidas.  Ou seja, não é possível tratar um chefe como se de um empregado apenas se tratasse.  Ou seja,

Chefe o_zé("Zé", masculino, 2);
Empregado outro_zé_como_mero_empregado = o_zé;

A estas operações de retirar o que é específico de uma classe, chama-se em inglês slicing, e chamar-se-há aqui corte, uma vez que cortam informação deixando apenas as "fatias" de informação relevantes.  Esta operação é menos útil do que parece à primeira vista (na realidade até pode ser perigosa).  Bastante mais útil seria que se pudesse colocar o endereço de uma instância ou objecto da classe Chefe num ponteiro para Empregado.  Ou seja:

Chefe o_zé("Zé", masculino, 2);
Empregado* ponteiro_para_o_zé_visto_como_mero_empregado = &o_zé;

De igual forma seria desejável que referências para Empregados pudessem ser sinónimos de Chefes.  Ou seja:

Chefe o_zé("Zé", masculino, 2);
Empregado& também_sou_o_zé_mas_visto_como_mero_empregado = o_zé;

Note-se que nestes dois casos, ao contrário da inicialização de um empregado a partir de um chefe, a informação acessível através do ponteiro ou referência para Empregado inclui toda a informação sobre o chefe!  Isto é, não há corte (slicing).  No primeiro caso existiam dois objectos: um Chefe e um Empregado,  que funcionava como um sósia despromovido do Chefe (daí o pouco interesse prático do slicing).  Nos últimos casos existe apenas um objecto, da classe Chefe, que é acessível através de um ponteiro ou de uma referência.

Este comportamento permitiria, por exemplo, guardar todo o pessoal da empresa através de um única lista de ponteiros para Empregado.  Por exemplo, o seguinte código seria possível:

list<Empregado*> empregados;

// Inserção dos empregados:
empregados.push_back(new Empregado("João Maria", masculino));
empregados.push_back(new Chefe("Ana Maria", feminino, 4));

...

// Visualização dos empregados:
for(list<Empregado*>::iterator i = empregados.begin(); 
    i != empregados.end(); ++i)
    (*i)->mostra();

* Assume-se definido um tipo enumerado Sexo e respectivo operador de escrita num canal:

enum Sexo {masculino, feminino};

inline ostream& operator << (ostream& saída, Sexo s)
{
    return saída << (s == masculino? "masculino" : "feminino");
}

1.1.1  Primeira tentativa de solução do dilema

class Chefe {
  public:
    Chefe(string const& nome, Sexo sexo, int nível);

    string const& nome() const;
    Sexo sexo() const;
    int nível() const;
    void mostra() const;

  private:
    Empregado empregado;
    int nível_;
};

inline Chefe::Chefe(string const& nome, Sexo sexo, int nível)
    : empregado(nome, sexo), nível_(nível) 
{
}

inline string const& Chefe:: nome() const 
{
    return empregado.nome();
}

inline Sexo Chefe::sexo() const 
{
    return empregado.sexo();
}

inline int Chefe::nível() const 
{
    return nível_;
}

inline void Chefe:: mostra() const 
{
    empregado.mostra();
    cout << "Nível: " << nível() << endl;
}

Este tipo de solução não é, pois, o mais indicado para representar a relação é um existente entre chefes e empregados.  A utilização de atributos é mais indicada para representar relações de agregação (tem um) ou, melhor ainda, de composição (é composto por um).  Acontece que um chefe não tem um empregado (bom, pelo menos se formos precisos com a linguagem, pois um chefe pode chefiar vários empregados), nem muito menos é composto por um empregado (a teoria do homúnculo há muito que foi abandonada por absurda).

1.1.2  Segunda tentativa

class Empregado {
  public:
    Empregado(string const& nome, Sexo s);
    Empregado(Chefe const& chefe);

    string const& nome() const;
    Sexo sexo() const;
    void mostra() const;

  private:
    string nome_;
    Sexo sexo_;
};

inline Empregado::Empregado(Chefe const& chefe)
    : nome_(chefe.nome()), sexo_(chefe.sexo()) {
}

1.1.3  Solução

class Chefe : public Empregado {
  public:
    Chefe(string const& nome, Sexo sexo, int nível);

    int nível() const;
    void mostra() const;

  private:
    int nível_;
};

inline Chefe::Chefe(string const& nome, Sexo sexo, int nível)
    : ...
{
    ...
}

inline int Chefe::nível() const
{
    return nível_;
}

inline void Chefe::mostra() const
{
    ...
}

A sintaxe para definir classes por derivação corresponde a colocar : após o nome da classe derivada seguida de uma lista de classes base, que podem ser em número arbitrário.  Por exemplo, a definição

...
class D : public A, public B, public C {
    ...
};

A classe derivada herda todos os membros das classes base.  No entanto, os membros privados da classe base não ficam acessíveis directamente a partir dos métodos da classe derivada: se não fosse assim, estar-se-ia a "abrir a porta" da parte privada de uma classe a quem quer que definisse uma classe sua derivada, violando-se com isso o princípio do encapsulamento.

A herança ou derivação fez-se usando a palavra chave public.  Isso significa que:

1. Os membros públicos da classe base são herdados como membros públicos da classe derivada (daí que não seja necessário redefinir as operações nome() e sexo()).  Este facto resolve o primeiro problema identificado, pois acrescentar o número do contribuinte e respectivo inspector na classe Empregado leva à sua inclusão automática na classe Chefe.
2. Quaisquer instâncias da classe derivada são compatíveis com instâncias da classe base, o mesmo se passando com ponteiros e referências.  Este facto resolve o segundo problema identificado, sendo agora possível inserir todo o pessoal da empresa numa única lista de ponteiros para Empregado.

A derivação poderia ter sido feita também usando a palavra chave private (que é o tipo de herança por omissão para as classes, sendo a herança pública por omissão para as estruturas).  Nesse caso:

1. Os membros públicos da classe base são herdados como membros privados da classe derivada.
2. As instâncias da classe derivada não são compatíveis com instâncias da classe base, o mesmo se passando com ponteiros e referências.

1.1.4  Compatibilidade das classes

Chefe o_zé("Zé", masculino, 2);
Empregado um_novo_zé_mero_empregado = o_zé;  // corte (slicing), pouco útil.
Empregado* ponteiro_para_o_zé_como_empregado = &o_zé;
Empregado& também_sou_o_zé_mas_visto_como_mero_empregado = o_zé;

Chefe* ponteiro_para_o_zé_agora_como_chefe = 
    static_cast<Chefe*>(ponteiro_para_o_zé_como_empregado);
Chefe& também_sou_o_zé = 
    static_cast<Chefe&>(também_sou_o_zé_mas_visto_como_mero_empregado);

Raramente tais conversões são úteis.  Aliás, normalmente são sinal de fraco desenho das classes usadas para resolver o problema.

1.2  Construtores, construtores por omissão e cópia e atribuição por cópia

inline Chefe::Chefe(string const& nome, Sexo sexo, int nível)
    : Empregado(nome, sexo), nível_(nível)
{
}

A ordem pela qual as inicializações têm lugar num construtor é a que se segue:

1. Primeiro são inicializadas as classes base através da invocação dos respectivos construtores, por ordem de aparecimento na especificação das heranças na definição da classe derivada.
2. Depois são inicializadas os atributos de instância da classe derivada, por ordem de declaração, através da invocação dos respectivos construtores.
3. Finalmente é executado o corpo do construtor.

class Z {
    ...
};

class D : A, B, C {
  public:
    D(int i, Z const& z);
    ~D();

    ...

  private:
    static int const dim = 10;
    int i;
    Z const z;
    float m[dim];
    int* pi;
};

D::D(int i, Z const& z)
    : i(i), z(z), pi(new int(10))
{
    for(int i = 0; i != dim; ++i)
        m[i] = 0;
}

D::~D() 
{
    delete pi;
}

1. Construtor de A, para inicialização dos atributos herdados de A.
2. Construtor de B, para inicialização dos atributos herdados de B.
3. Construtor de C, para inicialização dos atributos herdados de C.
4. Construtor de int, para inicialização do atributo i.
5. Construtor de Z, para inicialização do atributo constante z.
6. Construtor de pi, para inicialização do atributo pi com o endereço de uma nova variável dinâmica.
7. Atributos de tipos básicos ou deles derivados não têm quaisquer construtores invocados implicitamente.  É o caso do atributo m.
8. Corpo do construtor, onde se inicializa a matriz m.

Como para qualquer outra classe, a linguagem tentará sempre fornecer implicitamente:

1. Um construtor por omissão (desde que não se tenha declarado qualquer construtor na classe).  Este construtor por omissão fornecido automaticamente limita-se a invocar os construtores por omissão de todas as classes base e de todos os atributos de instância (excepto se forem de tipos básicos e noutros casos particulares).
2. Um construtor por cópia (desde que não se tenha declarado explicitamente na classe).  Este construtor por cópia fornecido implicitamente limita-se a invocar os construtores por cópia de todas as classes base e de todas os atributos de instância.
3. Um operador de atribuição por cópia (desde que não seja declarado explicitamente na classe).  Este operador fornecido automaticamente limita-se a invocar os operadores de atribuição por cópia de todas as classes base e de todos os atributos variáveis de instância (como é óbvio, este operador não poderá ser fornecido se existirem atributos constantes ou referências instância).

1. Primeiro é executado o corpo do destrutor.
2. Depois são invocados os destrutores de todos os atributos de instância da classe derivada, por ordem inversa de declaração.
3. Finalmente são invocados os destrutores de todas as classes base por ordem inversa à do seu aparecimento na especificação das heranças na definição da classe derivada.

1. Corpo do destrutor, onde se devolve à memória livre a variável dinâmica cujo endereço se guarda em pi.
2. m e pi, não têm quaisquer destrutores invocados.  Um ponteiro não tem destrutor qualquer que seja o tipo apontado.  Uma matriz tem um destrutor que consiste em destruir cada um dos seus membros, pela ordem inversa à da construção, excepto quando, como neste caso, os elementos da matriz são de tipos básicos do C++.
3. Destrutor de Z, para a constante membro z.
4. Destrutor de C, para os atributos herdados de C.
5. Destrutor de B, para os atributos herdados de B.
6. Destrutor de A, para os atributos herdados de A.

1.3  Ocultação

inline void Chefe::mostra() const
{
    Empregado::mostra();
    cout << "Nível: " << nível() << endl;
}

Dada a definição da classe, o seguinte código

Chefe chefe("Zé", masculino, 2);
chefe.mostra();

Nome: Zé
Sexo: masculino
Nível: 2

chefe.Empregado::mostra();

Nome: Zé
Sexo: masculino

Ou seja, é possível invocar uma operação de uma classe base, mesmo que oculta.

1.4  Hierarquias de classes

class SerVivo {
    ...
};
class Animal /* reino */ : public SerVivo {
    ...
};
class Vegetal /* reino */ : public SerVivo {
    ...
};
class Cordado /* filo */ : public Animal {
    ...
};
class Vertebrado /* subfilo */ : public Cordado {
    ...
};
class Mamífero /* classe */ : public Vertebrado {
    ...
};
class Primata /* ordem */ : public Mamífero {
    ...
};
class Hominídeo /* família */ : public Primata {
    ...
};
class Homo /* género */ : public Hominídeo {
    ...
};
class Homo_sapiens /* espécie */ : public Homo {
    ...
};
class Homo_sapien_sapiens /* subespécie */
    : public Homo_sapiens {
    ...
};

Na figura que se segue pode-se ver um possível diagrama para as relações entre classes de veículos das forças armadas:

São subclasses de  uma classe todas as classes que dela derivem, directa ou indirectamente.  São superclasses de uma classe as classes de que ela derive, directa ou indirectamente.  Assim, as subclasses de VeículoAéreo no diagrama acima são Helicóptero, Avião e Hidroavião.

Fica como exercício para o leitor desenhar o diagrama do primeiro exemplo e o esqueleto da definição em C++ das classes do segundo exemplo.

1.5  Problemas por resolver

list<Empregado*> empregados;

// Inserção dos empregados:
empregados.push_back(new Empregado("João Maria", masculino));
empregados.push_back(new Chefe("Ana Maria", feminino, 4));

...

// Visualização dos empregados:
for(list<Empregado*>::iterator i = empregados.begin(); 
    i != empregados.end(); ++i)
    (*i)->mostra();

A situação é ilustrada pelo seguinte diagrama:

O único problema é que, como a operação mostra() é invocada através de um ponteiro para Empregado, todos os empregados são mostrados como simples empregados, apesar de entre eles haver empregados que são chefes, secretárias, ou motoristas.  A solução para este problema será vista na próxima aula, onde se apresentam as noções de polimorfismo, ligação estática e dinâmica e sua implementação em C++.

1.6  Herança privada: redução/alteração de interfaces

Suponha-se que se pretende, mais uma vez, implementar o conceito de pilha de inteiros, na forma da classe PilhaDeInt, de novo sem quaisquer limitações quanto ao número de itens, excepto as impostas pela memória disponível e pelos limites do tipo int.  Uma vez que a classe ListaDeInt está já desenvolvida, não impõe restrições quanto ao comprimento das listas, e possui todas as operações necessárias para implementar uma pilha, é natural pensar em implementar o conceito de pilha com base na implementação das listas já existentes.  Neste caso a relação que existe entre as duas classes é:

a classe PinhaInt funciona como uma ListaDeInt, mas apenas permite...

Então, uma primeira implementação das pilhas poderia ser:

class PilhaDeInt {
  public:
    typedef ListaDeInt::Item Item;

    int altura() const;
    bool estáVazia() const;
    Item const& topo() const;

    Item& topo();
    void põe(Item const& novo_item);
    void tiraItem();

  private:
    ListaDeInt lista;
};

int PilhaDeInt:: altura() const 
{
    return lista.comprimento();
}

bool PilhaDeInt::estáVazia() const 
{
    return lista.estáVazia();
}

Item const& PilhaDeInt:: topo() const 
{
    return lista.trás();
}

Item& PilhaDeInt:: topo() 
{
    return lista.trás();
}

void PilhaDeInt::põe(Item const& novo_item) 
{
    lista.põeAtrás(novo_item);
}

void PilhaDeInt::tiraItem()
{
    lista.tiraDeTrás();
}

Um resultado muito semelhante pode ser obtido por herança privada:

class PilhaDeInt : private ListaDeInt {
  public:
    typedef ListaDeInt::Item Item;

    int altura() const;
    bool estáVazia() const;
    Item const& topo() const;

    Item& topo();
    void põe(Item const& novo_item);
    void tiraItem();
};

int PilhaDeInt::altura() const
{
    return comprimento();
}

bool PilhaDeInt::estáVazia() const 
{
    return ListaDeInt::estáVazia();
}

Item const& PilhaDeInt:: topo() const 
{
    return trás();
}

Item& PilhaDeInt:: topo() 
{
    return trás();
}

void PilhaDeInt::põe(Item const& novo_item) 
{
    põeAtrás(novo_item);
}

void PilhaDeInt:: tiraItem() 
{
    tiraDeTrás();
}

Esta solução pode ser vista como uma alteração da interface da classe ListaDeInt de modo a proporcionar apenas os serviços de uma pilha.

O C++ proporciona uma forma simples de abrir excepções quanto ao tipo de herança.  Se se pretender tornar públicos membros cuja herança foi feita de uma forma privada, basta usar uma declaração de utilização do respectivo nome na parte pública da classe derivada.  Assim, a classe PilhaDeInt pode ser definida como:

class PilhaDeInt : private ListaDeInt {
  public:
    using ListaDeInt::Item;

    int altura() const;

    using ListaDeInt::estáVazia;

    Item const& topo() const;

    Item& topo();
    void põe(Item item);
    void tiraItem();
};

int PilhaDeInt::altura() const 
{
    return comprimento();
}

Item const& PilhaDeInt:: topo() const 
{
    return trás();
}

Item& PilhaDeInt:: topo() 
{
    return trás();
}

void PilhaDeInt::põe(Item item) 
{
    põeAtrás(item);
}

void PilhaDeInt:: tiraItem() 
{
    tiraDeTrás();
}

class PilhaDeInt : private ListaDeInt {
  public:
    using ListaDeInt::Item;

    using ListaDeInt::comprimento;
    using ListaDeInt::estáVazia;
    using ListaDeInt::trás;

    using ListaDeInt::põeAtrás;
    using ListaDeInt::tiraDeTrás;
};

A herança privada deve ser usada com muita parcimónia, pois introduz uma ligação muito forte entre a classe PilhaDeInt e a classe ListaDeInt.  Regra geral, portanto, deve-se usar a composição para este tipo de relações e usar herança pública para representar relações é um.

1.7  Políticas de acesso

1. Se um membro de uma classe é privado, só lhe podem aceder membros ou amigos dessa mesma classe.
2. Se um membro de uma classe é público, o acesso não tem restrições.
3. Os membros públicos de uma classe estão sempre acessíveis a membros e amigos de qualquer classe derivada.
4. Os membros públicos de uma classe só são acessíveis por intermédio de instâncias de uma classe derivada se essa derivação se tiver feito duma forma pública (herança pública).

class A {
  private:
    int i;
  public:
    int u;
};

class B : private A {
  public:
    void f();
};

void B::f()
{
    i = 1; // erro: i é privada de A.
    u = 1;
}

class C : public A {
  public:
    void f();
};

void C::f()
{
    i = 1; // erro: i é privada de A.
    u = 1;
}

void g() {
    A a;
    B b;
    C c;

    a.i = 1; // erro: i é privada de A.
    a.u = 1;
    b.i = 1; // erro: i é privada de A.
    b.u = 1; // erro: u é privada de B embora seja pública de A (herança privada).
    c.i = 1; // erro: i é privada de A.
    c.u = 1;

    a = b; // erro: um B não é um A (herança privada).
    b = a; // erro: um A não é um B.
    a = c;
    c = a; // erro: um A não é um C.
}

2  Leitura recomendada

Recomenda-se a leitura do Capítulo 14 de [1].

3  Referências

[1]  Michael Main e Walter Savitch, "Data Structures and Other Objects Using C++", Addison-Wesley, Reading Massachusetts, 1997.