Existem dois tipos básicos de relações entre objetos:

Relações de associação: Onde um objeto é uma parte menor de outro. Dizemos que um objeto tem outro.
Relações de herança: Quando um objeto é um tipo mais específico de outro. Dizemos que esse objeto é um exemplar do outro;
Essas relações permitem modelar corretamente as abstrações do mundo real dão real poder à orientação à objetos;

Composição
O tipo de agregação mais forte que existe é a relação de composição;
Nesta relação, um objeto B é uma parte componente do objeto A. Não há sentido em falar de A sem B, ou vice versa;
Nessa relação, é comum que o objeto A controle o ciclo de vida do objeto B
Quando A é criado, B é criado em seu construtor;
Quando A é destruído, B será destruído junto;
Representamos essa relação por um diamante cheio, que parte de A (Ship) para B (Cannon):

A seta indica navegabilidade. A classe Nave conhece o objeto da classe canhão, mas não o oposto;

Agregação
A segunda forma de associação é a agregação;
É uma relação um pouco mais fraca que a relação anterior;
Representa uma relação em que uma classe do todo esta presente nesse todo;
A classe do todo não tem obrigação nem de criar, nem de destruir essas partes;
Exemplo: Aluno e turmas, Animação e Imagens
Representamos essa relação por um diamante vazio, que parte de A (animação) para B (imagens)
O número indica a multiplicidade. Uma animação é formada por uma ou mais imagens;
O nome indica o nome da coleção que contém as imagens;
 Associação Simples
Muitas vezes, duas classes se relacionam sem que haja a criação de um todo e uma parte;
Por exemplo, a classe Piloto e a classe Nave;
O piloto dirige uma nave, mas ela não é parte dele;
Da mesma forma, o piloto não é parte da nave;
Essa relação é chamada de associação simples;
Representamos essa relação por uma linha, sem diamantes;
A implementação, no C++ é idêntica a composição. Porém essa relação costuma a ser mais fraca que a anterior;

Dependência
O tipo mais fraco de relação é a dependência.
Muitas vezes, um objeto só depende de outro por um curto período de tempo;
Pode ocorrer em dois casos:
Um objeto A usa dados de um objeto B para alguma operação;
Um objeto A cria uma instância do objeto B;
Um exemplo dessa relação é o canhão com os seus tiros;
Nessa relação, o objeto A não terá nenhum atributo do tipo do objeto B;
Representamos essa relação por uma linha tracejada entre as duas classes
É comum indicarmos o que uma classe faz com a outra por um estereótipo, marcado por << >>;

Herança
Herança representa a relação é um;
Ou seja, uma classe B é um tipo mais específico da classe A;
Todos os métodos e atributos de A automaticamente existirão em B;
Os atributos e métodos privados de A não serão visíveis na classe B;
Os atributos protected de A serão visíveis para a classe B, mas para nenhuma outra classe;
Os atributos e método public são vistos por todas as classes, inclusive B e usuários de B;

A relação de herança é representada por um triângulo. A ponta mostra a classe pai e a base a classe filha;
A classe mais genérica também é chamada de super classe, classe base ou classe pai/mãe;
A classe mais específica também é chamada de subclasse ou classe filha;
 Herança Multipla
Ocorre quando uma classe filha tem mais de uma classe pai;
O C++ suporta herança múltipla;
Entretanto, essa prática é desaconselhada;
Linguagens modernas proíbem herança múltipla;
Um problema da herança múltipla é o Diamante da Morte (DiamondofDeath);
Ocorre quando a classe A é pai de B e C, que por sua vez são pais de D;
Todos os métodos de A em D são considerados ambíguos;

Classes abstratas
Considere a seguinte hierarquia, criada na aula passada:
O método draw() de drawing é compartilhado
Mas imagens e animações desenham-se de maneiras completamente diferentes.
Como seria sua implementação na classe Drawing?
O problema aqui é que não sabemos como um Drawing genérico se pinta;
Então, não podemos fornecer a ele uma implementação;
Classes abstratas permitem que um método fique sem implementação;
As classes filhas, concretas, são então obrigadasa implementar o método;
Chamamos a reimplementaçãode um método na classe filha de sobrescrita;
Não confundir com sobrecarga que é quando damos duas assinaturas diferentes para métodos com o mesmo nome;
Para entender corretamente como esse mecanismo funciona, precisamos entender o conceito de polimorfismo;
Esse conceito permite que variáveis de uma superclasse comportem-se como seus filhos, da subclasse, desde que usem métodos virtuais;
Parece complicado? Mas nem tanto. Vejamos um exemplo prático.

O polimorfismo dá força a relação é um.

Se Image é uma Drawing, então é natural que as variáveis Drawing possam conter Images!
É uma das técnicas mais poderosas da orientação à objetos.
Através dela eliminamos duplicação de dados;
Eliminamos switches;
Permitimos que o software se torne flexível;
Implementamos plugins;
Classes abstratas possuem métodos sem implementação, chamados de métodos virtuais puros;
Sua declaração, no C++, é a seguinte:

Você não precisa fornecer uma implementação para um método abstrato;

Não é possível criar objetos de classes abstratas;
Mas é possível usá-los através de polimorfismo;
Sempre que criar uma classe com intenções de herança, deixe o construtor virtual;
Nunca sobrescreva um método não virtual;
Representamos classes e métodos abstratos pelo nome em itálico:

Interfaces
O último tipo de relação é o de interfaces;
Interfaces nada mais são do que classes que:
Não contém atributos;
Todos os métodos são abstratos (virtuais puros);
Contém um destrutor virtual;
Interfaces representam uma relação apenas de comportamento.
Chamamos essa relação de realização e não de herança;
Representamos interfaces por uma bolinha;
Usamos uma linha simples para designar a relação de realização
Interfaces tem várias vantagens sobre classes abstratas:
São um compromisso de comportamento e não de implementação;
Não sofrem do problema do diamante da morte e podem ser usadas com herança múltipla;
São muito adaptáveis;
Normalmente, é uma boa prática criar uma interface sempre que uma classe abstrata for identificada
Exemplo: Você percebeu que todas as entidades do seu jogo tinham em comum os métodos draw() e update();
Crie então uma classe chamada AbstractGameEntity para representar uma entidade em comum;
E uma interface chamada GameEntitypara representar o comportamento esperado por uma game entity.