Mais uma parte da série Conceitos de Orientação a Objetos, com Daniel Moreira Yokoyama:
Herança (ou derivação)
Você criou um sistema de loja virtual que vende cd’s. A orientação a objetos te permitiu criar uma classe CD, onde vocÊ agrupou todos os dados que dizem respeito aos CD’s: Título, Artista, Lista de músicas, Ano de lançamento, Gravadora, etc.
Após alguns meses no ar, seu cliente lhe diz que pretende expandir seu negócio para vender DVD’s. Isso vai exigir um esforço imenso de criar novas rotinas e novos tratamentos para cuidar de um ítem completamente novo ao sistema.
Para que se possa entender os reais motivos de tal apêlo da Orientação a Objetos em busca da reusabilidade, este cenário nos faz entender perfeitamente os problemas que a falta dela implicariam. É claro que, do ponto de vista arquitetônico, este panorama está sendo observado sob uma perspectiva inversa da ideal. Mas o ideal é algo atingido pela experiência.
Com a experiência que é adquirida ao longo do tempo usando a orientação a objetos, o profissional é capaz de, mesmo sem ter a menor idéia do plano de expanção do sistema (o cliente poderia decidir vender livros ou eletrônicos), prever que os pontos cruciais para uma possível derivação.
A derivação na OOP acontece através de herança. Uma classe herda (ou deriva) as características de uma outra, passando a conduzir todo o grupo de informações que a outra já fazia e, além disso, implementando características específicas.
No caso apresentado, poderia ser criado uma classe base produto, que possuiria o que todos os produtos de uma loja precisam ter: Preço, Descrição, código.
Uma segunda classe, CD, seria criada, herdando as características de Produto, mas implementando dados específicos do CD, como o Título, o nome do Artista, Gravadora, e ano de gravação.
Desta forma, a inclusão do novo negócio, fôsse DVD, fôsse livro, fôsse eletrônicos ou instrumentos musicais, seria bem menos trabalhosa.
A técnica de criar classes bases para derivar outras classes vêm da experiência do uso da Orientação a Objetos e da arquitetura de software. No começo é impossível não haver algum retrabalho ao notar que partes de determinadas classes seriam mais aproveitáveis se estivessem centralizados em uma classe base para ser extendido por outras classes herdeiras. Com o tempo esse tipo de percepção se torna mais fácil antes mesmo de implementar a aplicação.
Dica: Tente sempre abstrair os conceitos. Uma loja de CD é, antes de tudo, uma Loja. Se começar por aí vai entender que uma Loja vende Produtos. Um controle de estoque de Bebidas é, antes de qualquer coisa, um controle de estoque. Ao pensar desta forma você estará sempre deixando seu sistema facilmente extensível para outros tipos de expanções que seu cliente possa se interessar em fazer.