Guia fundamental da programao orientada a objetos - Final

Agora que ns j vimos os pilares da POO e a sua importncia, est na hora de abordar mais alguns aspectos importantes de orientao a objetos neste ltimo artigo. Vamos falar um pouco sobre classes abstratas, interfaces e classes finais (conhecida como classe selada em algumas linguagens).

O que so classes abstratas?

Elas so classes que no podem ser instanciadas. Ou seja, voc no pode criar objetos a partir de uma classe abstrata. A voc pode pensar: Mas pra que serve uma classe que no pode virar objeto?. Bom, voc ainda pode fazer herana com uma classe abstrata, e a que vem a grande utilidade delas. Imaginemos que eu queira implementar algumas classes de Pagamento. Uma pra pagamento via carto de crdito, outra para pagamento com boleto, e por fim uma para pagamento via pix.

Muitas coisas nessas trs formas de pagamento so bem parecidas, no? Sempre existe uma pessoa que paga, um horrio em que o pagamento e tambm o seu valor. Essas informaes podem, e devem ser abstradas, no faz o menor sentido ficar repetindo coisas atoa.

E a que ns podemos criar uma classe PagamentoBase que no vai ser capaz de realizar um pagamento, mas ter a responsabilidade de guardar essas partes comuns a todos os tipos de pagamento.

E no faz o menor sentido criar uma instncia de PagamentoBase, j que ele no uma classe responsvel por fazer o pagamento em si, mas para abstrair ao mximo coisas para as outras classes usarem. Ento nesse caso, ns podemos marcar essa classe como sendo abstrata, ento ser impossvel de criar um objeto a partir de PagamentoBase.

Claro, classes abstratas tambm podem ter outras responsabilidades dependendo de como voc as implementa, mas na minha viso, a principal funo delas abstrair coisas para que outras classes normais consigam usar e se beneficiar, aumentando a reusabilidade do cdigo.

Alm disso, lembre-se que tambm possvel sobrescrever os mtodos da nossa classe abstrata, ento, por exemplo, eu posso sobrescrever o mtodo de notificar o usurio quando o pagamento feito com sucesso.

Abaixo implemento o exemplo citado nos pargrafos anteriores.

<?phpabstract class PagamentoBase{    protected float $valor;    protected DateTime $dataPagamento;    //etc...    public function notificarUsuarioSobrePagamento(): void    {        //imagine uma implementao    }    //Temos mais metodos abaixo que esto invisiveis...}class PagamentoViaCartao extends PagamentoBase{    private int $numeroCartao;    //etc...    //imagine que tem alguns mtodos aqui}class PagamentoViaBoleto extends PagamentoBase{    //Imagine que eu implementei alguns metodos aqui tambm}class PagamentoViaPix extends PagamentoBase{    public function notificarUsuarioSobrePagamento(): void    {        //A implementao  diferente pois como o pix  instantaneo        //eu preciso enviar essa notificao o mais rpido possivel.    }    //temos mais metodos e atributos nessa classe...}

O que so interfaces?

A primeira coisa que voc precisa ter em mente que interface NO so classes, logo impossvel instanciar objetos a partir da interface. Mas voc pode pensar, se eu no consigo criar objetos a partir de interfaces, como que eu vou usar elas no meu cdigo?, e eu vou te responder que interfaces so usadas como se fossem contratos.

Quando voc assina um contrato, voc obrigado pela lei a cumprir o que est escrito no contrato. Ou seja, o contrato uma forma de garantir que tu cumpra o que prometeu cumprir. Interfaces funcionam de forma parecida.

Digamos que eu tenha uma classe Carro, e uma classe Moto, e voc concorda comigo que todo veculo precisa andar para ser til, no mesmo? Ento, nessa situao, se essas classes no tiverem um mtodo andar(), elas sero inteis pra mim, pois um veculo que no anda intil.

E justamente nesse cenrio que as interfaces aparecem pra salvar o dia, eu posso criar uma interface chamada ContratoVeiculo e l colocar o mtodo andar(). Logo aps isso eu fao a minha classe implementar essa interface. Isso vai fazer com que essa classe seja obrigada a implementar os mtodos definidos na interface.

A interface no tem a obrigao de dizer como um mtodo deve funcionar (e nem pode fazer isso), por isso em interfaces ns no implementamos o mtodo, apenas escrevemos a assinatura do mtodo, ou seja, escrevemos o seu nome, quais parmetros ele recebe, e qual o tipo do retorno desse mtodo.

obrigao da classe que implementa esse interface dizer como vai ser toda a lgica do meu mtodo, mas esse mtodo precisa respeitar a assinatura da interface, ento ele precisa receber os mesmos tipos de parmetros e retornar o tipo de valor definido na interface.

A vantagem em ter essa abordagem (interfaces serem proibidas de ditar o funcionamento dos mtodos) que eu vou poder usar a mesma interface para classes diferentes, que tero lgicas de funcionamento diferentes. Como voc j deve saber, carros e motos andam de formas diferentes, mas como a minha interface ContratoVeiculo agnstica, eu consigo usar ela tanto na classe Carro quanto na classe Moto.

Abaixo eu mostro um trecho de cdigo PHP que implementa essas classes e interface citados acima.

<?phpinterface ContratoVeiculo{   public function andar(): void;   //Aqui eu digo que quero uma funo chamada andar   //que no recebe nenhum parametro e retorna void   //Ou seja, no retorna nada}class Carro implements ContratoVeiculo{   //Imagine que temos varios atributos   //e varios metodos aqui   public function andar(): void   {       print("O carro est andando
");   }}class Moto implements ContratoVeiculo{   //Imagine que temos varios atributos   //e varios metodos aqui   public function andar(): void   {       print("Andando como uma moto
");   }}

E o que so classes seladas?

E por fim, vamos falar um pouco sobre as classes finais, ou classes seladas, o nome varia de acordo com a linguagem de programao que voc estiver usando (em PHP e Java classe final e no C# classe selada).
Lembra que as classes abstratas no podem ser instanciadas, mas podiam ser herdadas? Com as classes finais acontece o oposto, elas podem ser instanciadas, mas no podem ser herdadas.

A razo para se usar uma classe desse tipo que a herana tambm tem o seu nus, e pode ser que em algum caso especifico voc quer evitar que algum outro programador extenda a sua classe. Deixo abaixo a opinio de um usurio do stackoverflow sobre o assunto.

uma forma de dizer que esta classe no pode ser herdada, o que costuma ser uma boa ideia. Desenvolver classes preparadas para serem herdadas muito mais difcil, a manuteno seguinte se torna um fardo. Acho at que o padro deveria ser a classe no herdvel.

Abaixo deixo um exemplo de classe final no PHP.

<?phpabstract class CarroGenerico{   public int $quilometragem;   public function ligar(): void   {       //logica para ligar o carro   }}final class ToyotaCorolla{   //implementa coisas especificas de um Corolla   //A ideia aqui,  que chegamos na nossa classe final   //No faz muito sentido extender um Corolla   //pois ele j  o produto FINAL}

Concluso

Bom, com esse artigo ns cobrimos todas as partes que eu considero fundamentais para que voc comece a usar a orientao a objetos. Existem muitas coisas que no foram cobertas nessa srie e que esto relacionadas com POO, como por exemplo funes amigas e generics. Mas falar disso fugiria um pouco da finalidade dessa srie, que cobrir os fundamentos da programao orientada a objetos. Vejo vocs em prximos artigos! :)