Programação

Orientada a Objetos
 Programação
Orientada a Objetos

1ª edição
2018
 Autoria Samira Santos da Silva
Natália Gonçalves Machado
Parecerista Validador Adriano Donizete Pila

*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.

Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte

desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Unidade 3
3. Herança e Polimorfismo

Para iniciar seus estudos

3
Nesta unidade, você compreenderá os conceitos de herança e polimor-
fismo, dois grandes pilares da programação orientada a objetos. Quando
aplicados em sistemas, suas vantagens são muitas, como reúso de código,
facilidade na manutenção e organização do código, etc. Aprendendo
esses conceitos, você poderá aplicá-los no desenvolvimento de seus sis-
temas e desfrutar de todo o potencial das linguagens orientadas a obje-
tos. Pronto para começar?

Objetivos de Aprendizagem
• Conhecer os conceitos de herança e polimorfismo dentro do
contexto de orientação a objetos e da aplicação dos mesmos na
representação de projeto de sistemas através de diagramas de
classe UML e na codificação através da linguagem Java.

36
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Introdução da unidade
Nesta unidade, abordaremos os conceitos de herança e polimorfismo dentro da orientação a objetos. Conhe-
cer esses conceitos e saber utilizá-los é fundamental para o desenvolvimento de sistemas concisos e coerentes.
Além disso, apresentaremos as diferenças entre classes abstratas e interfaces, e você conseguirá compreender
quando utilizar cada uma das implementações nos seus projetos orientados a objetos. Por fim, mostraremos
como empregar os conceitos abordados na modelagem utilizando diagramas de classe UML e no desenvolvi-
mento de sistemas através da linguagem Java. A compreensão desses conceitos e o conhecimento de sua apli-
cação despertarão em você o senso crítico sobre em quais situações e em que tipos de sistemas utilizar cada
conceito abordado.

3.1 Herança e polimorfismo

Na unidade anterior, estudamos dois dos pilares da programação orientada a objetos: abstração e encapsula-
mento. Nesta unidade, vamos abordar os dois pilares restantes ligados à orientação a objetos: herança e polimor-
fismo. Além disso, vamos mostrar como esses conceitos estão relacionados com os conceitos de classe abstrata e
interfaces e como aplicá-los no diagrama de classes UML e na programação em linguagem Java.

3.1.1 Herança

A programação orientada a objetos permite com que o conceito de herança seja implementado. Neste contexto,
herança possui o mesmo significado do mundo real. Assim como um filho pode herdar algumas características
do pai, na orientação a objetos permite-se que uma classe herde atributos e métodos de outra classe.

Existem nomes especiais para as classes que estão envolvidas nessa relação de herança. A classe “pai” é chamada
de superclasse. É ela que vai ceder suas características para a classe “filho”, a qual chamamos de subclasse ou
classe derivada.

Na Figura 20, temos a superclasse Veículo. Esta superclasse possui três subclasses que herdam suas caracterís-
ticas: Carro, Ônibus e Avião. Outra maneira de entender é pensar que Carro, Ônibus e Avião são do tipo Veículo.

Figura 20 – Exemplo de classes que herdam da classe veículo

Veículo

Carro Ônibus Avião

Fonte: Elaborada pelo autor.

37
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Para que o conceito de herança seja empregado, apenas uma restrição é necessária. Os especificadores de acesso
das classes, métodos e atributos necessitam estar no modo “protegido” ou “público” para que outras classes pos-
sam herdá-los. Caso sejam “privados”, só poderão ser acessados via getters e setters.

A maior vantagem em se utilizar a herança é a possibilidade de reúso de código. No exemplo da Figura 20, todos
os três tipos de veículos possuem capacidade de passageiros, tipo de combustível e número de rodas. Caso a
superclasse Veículo não existisse, esses atributos deveriam ser especificados de forma repetitiva em cada uma
das classes: Carro, Ônibus e Avião. Como essas classes herdam-se da classe Veículo, esses atributos são definidos
uma única vez na superclasse e herdados pela mesma.

Além de reúso do código, existe outra questão afetada pela utilização de herança é a manutenção. A utilização
desse conceito faz com que os códigos sejam desenvolvidos de forma mais clara, deixando o código mais orga-
nizado e facilitando bastante a manutenção e a correção de possíveis erros.

3.1.1.1 Herança simples

Quando uma classe derivada herda propriedades (atributos e métodos) somente de uma classe, tem-se a cha-
mada herança simples. Na herança simples, uma classe tem somente uma superclasse. A Figura 21 exemplifica
esse conceito. A classe Canário herda somente da classe Pássaro.

Figura 21 – Exemplo de herança simples

Pássaro

Canário
Fonte: Elaborada pelo autor.

3.1.1.2 Herança múltipla

Na herança múltipla, uma classe herda propriedades (atributos e métodos) de duas ou mais classes. Sendo assim,
a classe derivada possui mais de uma superclasse. No exemplo da Figura 22, a classe Dragão herda de duas super-
classes: Pássaro e Lagarto. Isso significa que dragão é um pássaro e, portanto, possui as características de um
pássaro, ao mesmo tempo em que também possui as características de um lagarto.

38
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Figura 22 – Exemplo de herança múltipla

Pássaro Lagarto

Dragão
Fonte: Elaborada pelo autor.

Saiba mais

Uma classe pode derivar mais de uma classe, e isso não é herança múltipla. Na herança múl-
tipla, tem-se mais de uma superclasse para uma mesma classe. O caso em que mais de uma
classe herda de uma mesma superclasse é o de herança simples, sendo o caso mais comum
nos projetos.

Fique atento!

Para que uma subclasse acesse métodos e atributos herdados facilmente, é necessário
que eles sejam definidos na superclasse com os modificadores de acesso “protegido” ou
“público”. Caso sejam privados, só poderão ser acessados via getters e setters.

3.1.2 Classes abstratas e interfaces

Na programação orientada a objetos, existem dois mecanismos que permitem a criação de classes, contendo
apenas descrições de atributos e assinaturas de métodos, sem efetivamente implementá-los. Essa possibilidade
é útil para a definição de classes que nunca são instanciadas, como alguns exemplos de superclasses no rela-
cionamento de herança. Nesse caso, a implementação dos métodos fica, por exemplo, para suas subclasses. Os
mecanismos que permitem isso se denominam classes abstratas e interfaces e são muitas vezes confundidos.

Uma superclasse que possui métodos que não são implementados deve defini-los como abstratos. Métodos abs-
tratos são somente declarados (com nome, modificadores, lista de argumentos e retorno), mas não implementa-
dos. Se uma superclasse possui um método abstrato, a subclasse que herda esse método deve necessariamente
implementá-lo, seguindo a declaração especificada na superclasse. Se uma classe possui ao menos um método
abstrato, ela pode ser considerada uma classe abstrata. Uma classe pode ser declarada como sendo abstrata sem

39
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

possuir métodos abstratos; entretanto, caso possua algum método abstrato, suas classes derivadas devem imple-
mentá-lo. Classes abstratas em orientação a objetos são classes que não podem ser estanciadas de forma direta.

Assim, as classes abstratas podem conter métodos abstratos e não abstratos. Se a classe possuir apenas métodos
abstratos, podemos criá-la como uma interface. Sua funcionalidade é semelhante a de classes abstratas; porém, a
forma de declaração desse tipo de classe é feita através de palavras reservadas diferentes. Assim como classes abs-
tratas, interfaces também não podem ser instanciadas. Todos os métodos de uma interface são abstratos e públicos.

Uma das diferenças fundamentais entre interfaces e classes abstratas é que uma subclasse pode herdar de
muitas interfaces, mas somente de uma classe (sendo ela abstrata ou não). Assim, as interfaces permitem a
implementação do conceito de herança múltipla. O Quadro 2 descrita a seguir apresenta uma comparação entre
algumas das características de interfaces e classes abstratas.

Quadro 2 – Comparação entre as características de interfaces e classes abstratas

Característica Interface Classe abstrata

Herança múltipla Uma classe pode implementar Uma classe pode implementar
diversas interfaces. apenas uma classe.
Implementação Uma interface não pode conter Uma classe abstrata pode
nenhum tipo de implementação. conter métodos não abstratos
implementados.
Instanciação Somente da classe que Somente da classe que herda suas
implementá-la. propriedades.
Métodos Todos públicos e abstratos. Dependem do modificador.
Velocidade Lenta, requer trabalho extra Rápida.
para encontrar o método
correspondente na classe atual.
Funcionalidades adicionais Se você incluir um novo método Se você incluir um novo método
na interface, é necessário em uma classe abstrata, você
implementá-lo em todas as pode definir uma implementação-
implementações dessa interface. padrão que todas as subclasses
podem adotar.
Fonte: Elaborado pelo autor.

Fique atento!

Classes não abstratas são chamadas de classes concretas e podem ser instanciadas
diretamente.

3.1.3 Polimorfismo

O polimorfismo é um dos pilares da programação orientada a objetos e está diretamente relacionado ao con-
ceito de herança. A palavra polimorfismo significa “muitas formas” e está ligada à capacidade dos animais de se

40
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

adaptarem ou alterarem sua forma conforme a necessidade. Na herança, as classes “filhas” herdam as carac-
terísticas de seus “pais”, ou seja, métodos e atributos das superclasses são herdados pelas classes derivadas.
Entretanto, podemos desejar que a ação que um método tome para determinada subclasse seja diferente da
especificada na superclasse. Assim, o polimorfismo dinâmico ou de sobreposição consiste em alterar o fun-
cionamento de alguns métodos herdados dentro de uma subclasse.

No exemplo da Figura da seção anterior, temos as classes Carro, Ônibus e Avião, que herdam da classe Veículo.
Imagine que a classe Veículo possua o método acelerar( ) que é herdado por todas as suas subclasses. Entre-
tanto, a forma como a aceleração é executada em um carro, ônibus ou avião é diferente. Portanto, cada uma
dessas classes deve reescrever o método acelerar( ) a fim de adaptá-lo para a sua necessidade.

Outra forma de utilizar o polimorfismo é definir, dentro uma classe, várias declarações de um mesmo método
com assinaturas diferentes. A escolha de qual método será chamado é feita em tempo de compilação e depende
da assinatura do método sobrecarregado. Esse tipo de polimorfismo é chamado de estático ou sobrecarga
(overload), sendo muito utilizado para especificar construtores, por exemplo. Na instanciação de uma classe
Círculo, poderíamos ter dois métodos construtores: um que recebe dois objetos do tipo Ponto (indicando o ponto
do centro e um ponto do círculo) e outro que recebe quatro parâmetros, sendo dois valores correspondendo às
posições x e y do ponto central e dois valores correspondendo às posições x e y de um ponto do círculo. A decisão
por qual método chamar seria feita em tempo de compilação.

Diversas vezes, podemos ver o conceito de herança acompanhado do conceito de especia-

lização e generalização. A definição de uma superclasse pode ser vista como uma generali-
zação. A definição de subclasses específicas que herdam de uma superclasse é chamada de
especialização.

3.1.4 Representação em UML

Assim como os outros conceitos abordados nas unidades anteriores, a herança e o polimorfismo também podem
ser representados no diagrama de classes UML. Para representar relacionamentos em UML, utilizamos geral-
mente de ligações entre os retângulos que representam as classes. Para indicar o relacionamento de herança
entre duas classes, utilizamos a seguinte representação gráfica:

Figura 23 – Representação gráfica de herança no diagrama de classes UML

Fonte: Elaborada pelo autor.

41
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Na Figura23, observamos o símbolo utilizado para representar a herança no diagrama de classes UML. A seguir,
na Figura 24, exemplificamos o uso desse símbolo na herança entre a superclasse Veículo e suas classes deriva-
das: Carro, Ônibus e Avião.

Figura 24 – Classes que herdam da classe Veículo no diagrama de classes UML

Veículo
- combustível: String
- capacidade: Int
+ acelerar( ): void

Carro Ônibus Avião

- capacidadePortaMalas: Int - passageirosEmPe: Int - numeroHelices: Int
+ acelerar( ): void
+ acelerar( ): void + acelerar( ): void + voar( ): void

Fonte: Elaborada pelo autor.

O diagrama representado na Figura 24 descreve o relacionamento entre a classe Veículo e suas classes derivadas.
O símbolo da herança é utilizado de forma que ele ligue uma subclasse à sua superclasse, fazendo com que a
ponta do triângulo indique a direção da classe “pai”. Observando o diagrama, percebemos que Carro, Ônibus e
Avião são do tipo Veículo.

É importante notar que os atributos e métodos definidos na superclasse devem ser comuns a todas as suas sub-
classes. Em todos os veículos, existem um tipo de combustível utilizado e uma capacidade de passageiros, e
todos têm a capacidade de acelerar. Assim, essas são características destinadas à superclasse Veículo e que são
herdadas por suas subclasses.

As particularidades de cada classe são definidas dentro das mesmas. A classe Carro, por exemplo, possui um
atributo que define a capacidade em litros do porta-malas. Como os outros veículos não possuem porta-malas,
este é um atributo específico de carros. Da mesma forma, apenas o ônibus pode transportar passageiros em
pé. Sendo assim, somente ele possui o atributo que diz qual a capacidade de passageiros em pé. Por fim, como
somente o avião possui hélices, só faz sentido definir o número de hélices de um veículo que seja um avião.

No diagrama de classes UML da Figura 24, percebemos o polimorfismo através da reescrita do método acelerar( ),
que é um método herdado da classe Veículo, mas cada subclasse implementa de modo diferente. Isso é necessário
porque, apesar de todos os veículos possuírem a propriedade de aceleração, devido às diferenças entre cada um
deles, esta propriedade é implementada de formas diferentes. Sendo assim, faz-se necessário sua reescrita nas
subclasses. Nesse caso, estamos implementando o polimorfismo dinâmico.

42
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

3.1.4.1 Classes abstratas e interfaces em UML

Classes abstratas no diagrama de classes UML diferenciam-se das classes concretas apenas pela fonte do texto,
que é dada em itálico. Se uma classe possui pelo menos um método abstrato, dizemos que ela é abstrata. Para
definir que uma classe é abstrata no diagrama de classes UML, colocamos seu nome em itálico. Para especificar
quais métodos são abstratos, também colocamos seus nomes em itálico. A Figura 25 mostra a diferença na repre-
sentação da classe Pessoa como sendo concreta (lado esquerdo) e como sendo abstrata (lado direito). Podemos
observar que, na classe do lado direito, o método getNome( ) e o nome da classe (Pessoa) estão em itálico.

Figura 25 – Diferença entre uma classe concreta e uma classe abstrata

Pessoa Pessoa
- nome: String X - nome: String

+ getNome( ): String + getNome( ): String

Classe Concreta Classe Abstrata

Fonte: Elaborada pelo autor.

Representar interfaces em diagramas UML é ainda mais simples. Basta colocar o termo reservado <<interface>>
antecedendo o nome da classe. A Figura 26 ilustra um exemplo de uma interface chamada Pessoa.

Figura 26 – Descrição de uma interface no diagrama de classes UML

<<interface>>

Pessoa
+ getNome( ): String

Fonte: Elaborada pelo autor.

3.1.5 Codificação em Java

A implementação do conceito de herança na linguagem Java é realizada através da palavra reservada extends pre-
cedida pelo nome da subclasse (que está sendo definida) e seguida pelo nome da superclasse que ela “estende”/
herda. A Figura 27, a seguir, ilustra um exemplo de implementação da superclasse Veículo.

43
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Figura 27 – Exemplo de superclasse Veículo

Fonte: Elaborada pelo autor.

A classe definida na Figura 27, por si só, não é ainda uma superclasse. No momento em que “estendemos” essa
classe utilizando a palavra extends, ela se torna uma superclasse, porque, então, outra classe herda suas proprie-
dades. Como podemos observar, essa classe possui atributos que são comuns a veículos de forma geral, como:
tipo de combustível, capacidade de passageiros e velocidade atual. Além disso, essa classe possui dois constru-
tores: um sem parâmetros, no qual se atribui à velocidade inicial do veículo o valor zero; e outro no qual o valor
desse atributo é um parâmetro do construtor. Por fim, são definidos dois outros métodos: o método acelerar( ) e
outro método que retorna o valor da velocidade atual.

A classe Carro herdando as características de Veículo é definida no código da Figura 28. Podemos notar a palavra
reservada extends na declaração da classe Carro indicando sua relação de herança com a classe Veículo. Assim,
Carro é subclasse, e veiculo é superclasse. Além das propriedades herdadas, a classe Carro possui um atributo
específico que denota a capacidade do porta-malas de um carro. Esta classe possui um construtor implemen-
tado que recebe como parâmetros a capacidade do porta-malas e a velocidade inicial do veículo. Este último
atributo é comum a todos os veículos e, portanto, existe um construtor na superclasse que instancia um Veículo
recebendo esse parâmetro. Dentro do construtor da classe Carro, podemos chamar o construtor de Veículo, pas-
sando esse parâmetro através do uso da palavra reservada super. Sua ação é chamar o construtor da superclasse
que se enquadre com os parâmetros passados.

Figura 28 – Subclasse Carro que herda os atributos da classe Veículo

Fonte: Elaborada pelo autor.

44
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Além do método construtor, a classe definida na Figura 28 reescreve o método acelerar( ) definido inicialmente
na sua superclasse. Para indicar a reescrita de um método herdado em Java, utilizamos a palavra reservada @
Override na linha anterior à declaração do método. Isso indica que instâncias específicas da classe Carro, ao cha-
marem o método Acelerar, vão executar a ação definida na reescrita só método, e não a ação inicial do método
herdado. A utilização de @Override indica a utilização do polimorfismo dinâmico.

Na Figura 29, observamos a instanciação de dois objetos diferentes. O objeto v é do tipo veículo e possui veloci-
dade inicial igual a 100. O objeto c é do tipo Carro, possui capacidade de 50 litros no porta-malas e velocidade
inicial também igual a 100. Primeiramente, chamamos o método acelerar( ) para o objeto v. Em seguida, chama-
mos o método acelerar( ) para o objeto c. O resultado dessa execução é apresentado na Figura 30.

Figura 29 – Instanciação da superclasse Veículo e da subclasse Carro

Fonte: Elaborada pelo autor.

Figura 30 – Impressão na tela gerada pelo código da Figura 29.

150

110

Fonte: Elaborada pelo autor.

Como observado na Figura 30, apesar de ambos os veículos (o genérico v e o carro c) possuírem velocidades
iniciais iguais, a velocidade atual de ambos após a aceleração é diferente. Isso acontece devido ao fato de que
a classe Carro sobrescreve o método acelerar de modo que, ao invés de esse método causar um incremento de
50 na velocidade atual, o valor desse incremento é igual a 10. Assim, quando chamamos c.acelerar(), estamos
chamando o método acelerar( ) definido na classe Carro. Quando chamamos v.acelerar(), estamos chamando
o método acelerar( ) definido na classe Veículo.

45
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

3.1.5.1 Classes abstratas e interfaces em Java

Na programação em Java, podemos aplicar os conceitos de classes abstratas e interfaces abordados anterior-
mente. Para fazer com que uma classe se torne abstrata, utilizamos a palavra reservada abstract, como mostrado
a seguir:

public abstract class Pessoa {

Para definir um método como abstrato, utilizamos a palavra abstract de maneira semelhante:

public abstract String getNome( );

Fique atento!

Métodos construtores nunca podem ser declarados como abstratos. Como construtores não
podem ser herdados, nunca seriam implementados.

Interfaces consistem em atributos que são constantes e métodos contendo apenas suas declarações, que vão ser
herdadas pelas subclasses. Ou seja, uma interface implica que todos os seus métodos são abstratos. Em Java, a
declaração de uma interface é definida pela palavra reservada interface substituindo a palavra class utilizada para
classes, como mostra o exemplo a seguir, ilustrando a interface Pessoa:

public interface Pessoa {

String getNome ( );

A interface Pessoa possui apenas um método abstrato chamado getNome( ), que suas subclasses devem imple-
mentar. Caso uma subclasse não implemente todos os métodos de sua interface, devemos declarar essa sub-
classe como abstrata. Abaixo, visualizamos um exemplo de classe Funcionário que implementa a interface Pes-
soa. Essa classe possui seus próprios atributos, além de implementar o método abstrato getNome( ) declarado em
Pessoa seguindo exatamente a declaração da interface.

46
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

public class Funcionario implements Pessoa {

private int idade;

private String nomeFunc;

public String getNome ( ) {

return nomeFunc;

Saiba mais

Os métodos dentro de uma interface são todos abstratos e públicos. Entretanto, não utiliza-
mos os modificadores public e abstract para esses métodos, pois isso causaria redundância. O
mesmo acontece com os atributos constantes dentro da interface.

Outro exemplo de utilização de interfaces é dado na Figura 31. Nesta figura, exemplificamos a codificação da
Interface FormaGeometrica, que descreve uma forma geométrica desenhada no plano cartesiano. Sendo assim,
qualquer quer seja a forma geométrica, podemos requisitar os valores de seu centro X e Y no plano cartesiano.
Além disso, também deve ser possível calcular e obter seu perímetro e área ocupada.

Figura 31 – Codificação da Interface FormaGeometrica em Java

Fonte: Elaborada pelo autor.

Na Figura 32, temos a codificação de uma implementação da Interface FormaGeometrica: a classe Quadrado. A
classe Quadrado possui os atributos referentes aos valores do ponto (X,Y) do seu centro. Além disso, para dese-
nhar um quadrado, basta saber o valor do lado e lembrar que um quadrado possui todos os quatro lados iguais.
Além de implementar os métodos abstratos que retornam o ponto central do quadrado, também implementa-
mos o método que calcula seu perímetro – que, no caso do quadrado, é a soma de todos os lados – e que calcula
sua área – que, no caso do quadrado, é o valor de (lado*lado).

47
 Programação Orientada a Objetos | Unidade 3 - Herança e Polimorfismo

Figura 32 – Codificação da implementação quadrado em Java

Fonte: Elaborada pelo autor.

Síntese da unidade
Nesta unidade, abordamos os conceitos de herança e polimorfismo na orientação a objetos. Dentro de herança,
elucidamos as diferenças entre herança simples e herança múltipla. Após definir o conceito de herança, defini-
mos classes abstratas e interfaces fazendo um contraste entre ambos os conceitos. Por fim, mostramos como
representar todos os conceitos abordados em diagramas de classes UML e como codificá-los em Java.

48
 Considerações finais
Com esta unidade, finalizamos a abordagem dos quatro pilares da pro-
gramação orientada a objetos: abstração, encapsulamento, herança e
polimorfismo. Conhecendo esses pilares, é possível ter-se uma boa ideia
do imenso potencial das linguagens orientadas a objetos.

49