Dicas de herança múltipla em Sistemas Embarcados

Nós, como projetistas de Software Embarcado, temos que às vezes utilizar o paradigma de orientação à objetos. É excelente saber que podemos ter as diversas vantagens que esse recurso nos traz, tais como reutilização de código, maior segurança do sistema, redução do custo de manutenção, entre outros. Porém há algumas coisas que precisamos estar atentos para que tudo saia bem, como o uso de herança múltipla.

 

Para a nossa análise, utilizaremos a linguagem C++, que é a linguagem orientada a objetos mais comum para Sistemas Embarcados.

 

 

Herança Múltipla

 

Um dos recursos mais interessantes de se programar com Orientação a Objetos é a herança múltipla. Ou seja, nós podemos criar uma classe aproveitando o código de outras classes e essa nova classe poderá herdar todas as características de suas classes mães reutilizando código e facilitando a manutenção do mesmo.

 

Vamos a um exemplo. Imagine que em nosso projeto queremos criar uma classe TemperatureSensor destinado a gerenciar os sensores de temperatura. E que esta classe é filha das classes InputPeripheral e I2CPeripheral, destinada a gerenciar os periféricos de entrada e os periféricos que se comunicam pelo barramento I2C, respectivamente.

 

Exemplo de herança múltipla

Figura 1: Exemplo de herança múltipla

 

 

Ambiguidade de métodos homônimos

 

Para avançar na nossa análise, vamos criar alguns métodos nas nossas classes. Para a classe I2CPeripheral vamos criar readData() e getAddress():

 

 

Para a classe TemperatureSensor criaremos apenas o método getTemp(). No entanto sabemos que ele herdará todos os métodos de suas classes mães além desse:

 

 

Observe que ambas as classes I2CPeripheral e InputPeripheral possuem o método readData(). Imagine que em algum momento do código seja instanciado um objeto da classe TemperatureSensor, o objeto  “sensorTMP100”, que corresponde ao sensor de temperatura TMP100 da Texas Instruments e que seja dado o comando:

 

 

Teremos um problema de ambiguidade, pois o compilador não saberá se deve chamar readData() proveniente de I2CPeripheral ou readData() proveniente de InputPeripheral. Para resolver este problema devemos especificar de qual das classes mães o método deve ser chamado. Vamos chamar readData() da classe I2CPeripheral para exemplificar:

 

 

Para otimizar o código, podemos utilizar um encapsulamento, de modo que o cliente da classe não precise saber que um objeto TemperatureSensor é também um objeto I2CPeripheral. Para isso podemos especificar que readData() será proveniente de I2CPeripheral na definição do método dentro da classe TemperatureSensor:

 

 

 

O problema da duplicidade

 

Vamos supor agora que tanto a classe I2CPeripheral quanto a classe InputPeripheral sejam derivadas da classe Peripheral. Nosso modelo de Software ficará assim:

 

Superclasse Peripheral

Superclasse Peripheral

 

Agora vamos criar um atributo privado em Peripheral chamado deviceId. Também criaremos métodos públicos setDeviceId(short int id) e short int getDeviceId ():

 

 

Continuaremos no código. Vamos criar duas funções independente de classes: short int readDeviceId(I2CPeripheral& dev) que terá como parâmetro a referência de um objeto I2CPeripheral e void defineDeviceId(InputPeripheral& dev, short int n) que terá como parâmetro a referência de um objeto InputPeripheral e um número “n” que se deseja determinar como o “Id” do objeto. Instanciaremos o objeto sensorTMP100 e chamaremos as duas novas funções que criamos passando sensorTMP100 como parâmetro para ambas:

 

 

Há neste caso um problema de ambiguidade. Havérá dois atributos deviceId e o número “5” não será impresso na tela! Isso ocorre porque para o objeto sensorTMP100 será criado um espaço de memória para deviceId derivado de I2CPeripheral e será criado um outro espaço de memória para deviceId derivado de InputPeripheral. Precisamos que exista apenas um espaço de memória para ambos. E para resolver isto é simples. Basta declarar a classe Peripheral como virtual:

 

 

Esta solução se parece com a criação de membros estáticos em classes os quais são compartilhados por todos os objetos da mesma classe.

 

Espero ter ajudado com essas dicas!

 

 

Referências

 

Créditos para a imagem destacada: http://serviciosci.com/formacion/informatica/microcontroladores-de-hardware-libre/

 

Fonte bibliográfica: C++ - Bjarne Stroustrup (1983).

 

Fonte bibliográfica: http://www.dainf.ct.utfpr.edu.br/~jeansimao/Fundamentos2/Fundamentos2.htm

Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Software » Dicas de herança múltipla em Sistemas Embarcados
Talvez você goste:
Comentários:

Deixe um comentário

avatar
 
  Notificações  
Notificar

Séries

Menu

WEBINAR
 
Linux Embarcado: Desvendando o Pin Control Subsystem - Kernel Linux

Data: 26/02 às 19:30 h | Apoio: Mouser Electronics
 
INSCREVA-SE AGORA »



 
close-link