10 Princípios Chave de Desenvolvimento de Software para Todo Desenvolvedor Mobile - Motivação e Programação Orientada a Objetos
- PROGRAMAÇÃO ORIENTADA A OBJETOS
- SOLID
- Injeção de dependência
- Git
- Gitflow vs. Trunk based development
- Code review
- Arquitetura
- Offline first pattern
- Testes unitários
- Integração contínua
O público-alvo desta série são desenvolvedores de software que trabalham diariamente produzindo software para plataformas móveis. Entretanto, você, leitor curioso, é também bem-vindo. Sempre temos algo a aprender.
Motivação
Tenho contato com desenvolvimento de software desde o ano de 2006, quando entrei na faculdade de Ciência da Computação. Atuo como profissional na área desde 2012. Com o passar dos anos, fiquei encarregado por corrigir testes realizados por candidatos a exercerem o papel de desenvolvedores Android.
Após a correção de cerca de uma dezena daqueles testes, percebi neles a ausência de boas práticas de desenvolvimento de software (não especificamente em tópicos voltados a mobile).
Após coletar alguns feedbacks, descobri que os principais motivos da ausência daquelas boas práticas eram a pressa por se concluir o teste; o costume dos candidatos trabalharem, no passado recente, em projetos individualmente; e a falta de uma base teórica mais forte em desenvolvimento de software (livros são e serão sempre muito importantes!).
Assim, através desta série, venho, de forma breve, apontar os principais tópicos sobre desenvolvimento de software que farão parte do dia a dia de um profissional que produz apps para dispositivos mobile. E, se possível, tentarei ao máximo mostrar o valor que cada um desses tópicos carregam, principalmente visando projetos de larga escala que atenderão milhões de usuários em seus smartphones/tablets/(e suas) centrais multimídia.
O que é OOP?
Programação orientada a objetos (Object-Oriented Programming - OOP) é um paradigma de programação baseado no conceito de objetos. Um objeto conterá dados e funções que manipularão esses dados.
Basicamente, OOP é baseada em troca de mensagens. Ou seja, ela envolve:
- O nome de um objeto
- O nome de um método
- E a mensagem a ser enviada ao objeto
Definições básicas
Classe/Objeto
Uma classe é formada por dados e funções/métodos que manipulam esses dados.
Por meio da definição de uma classe, viabilizamos a prática da OOP, pois a instanciação de entidades e a troca de mensagens entre elas se torna possível. Essas entidades são nomeadas objetos.
Campo/Atributo/Membro/Propriedade
São os dados que pertencem a um objeto específico. Dependendo da linguagem de programação, sua nomenclatura pode variar entre campo/atributo/membro/propriedade.
O local para suas declarações pode variar de acordo com a linguagem. Java, por exemplo, adota como convenção posicionar os dados no início da classe. Já outras linguagens como C++ dão espaço a esse tipo de declaração ao final da declaração de uma classe. Ou seja, não existe uma convenção global sobre onde declarar dados.
Construtor
Um objeto precisa ser instanciado para poder ser manipulado - ou seja, para que possamos enviar uma mensagem a ele.
A criação de um objeto se dá através de um método especial chamado de método construtor. Costumeiramente, independente da linguagem de programação, ele não precisa ser declarado, pois classes já definem implicitamente esse método.
Os quatro pilares da OOP
A programação orientada a objetos é sustentada por quatro pilares. O valor real desse paradigma vem, fundamentalmente, dos princípios que esses quatro pilares carregam consigo.
Abstração
Somente detalhes essenciais de uma classe devem estar disponíveis a seus usuários (outras classes) através de objetos. Esse princípio leva o nome de abstração.
Nós, desenvolvedores mobile - e você leitor curioso -, costumamos ver no “mundo real” esse pilar posto em prática quando tentamos acessar detalhes de implementação de uma classe do framework mobile com o qual estamos trabalhando, pois, caso contrário, estaríamos violando sua API pública e entrando em detalhes de implementação que não costumam ser expostos ao usuário da classe.
Encapsulamento
Dados definidos internamente em uma classe não podem ser acessados diretamente por usuários dessa classe. Isso é o que prega o princípio do encapsulamento.
Uma classe pode definir um conjunto de funções/métodos. E são esses métodos os quais podem manipular as informações contidas em classes. Os métodos formam a interface pública da classe. Eles servirão de assinatura a usuários daquela classe.
Uma classe bem encapsulada viabiliza ao seu(s) autor(es) refatorações mais simples sobre os dados, pois eles estarão protegidos pela API pública da classe quando essa está em uso por usuários (novamente, clientes da classe).
Herança
Este trata-se de um princípio que visa ao reuso de software. Em suma, um objeto círculo, por exemplo, é uma forma geométrica. Toda forma geométrica (poligonal) tem uma área. Logo, um (objeto) círculo pode implementar/sobrecarregar/sobrescrever a interface pública de uma forma, ao invés de definir do zero uma função/método para o cálculo dessa área.
Essa categoria de reuso de código, que expõe um relacionamento “é um” tem o nome de herança.
Poliformismo
Uma entidade pode assumir múltiplas formas. Essa é a essência do comportamento polimórfico que advém do princípio do polimorfismo.
Exemplificando, um círculo e um quadrado são formas geométricas poligonais. Logo, ambos têm uma área. Em termos de linguagem de programação, podemos ter a referência a uma forma. Essa forma carrega, primeiramente, um objeto círculo e temos acesso a sua área. Após, essa forma assume outra “roupagem” através da atribuição a ela de um objeto quadrado. E, assim, também temos acesso a área desse quadrado.
Por fim, o valor que o pilar polimórfico traz é podermos manipular entidades com comportamentos semelhantes por meio de uma interface (API) pública única.
Observações adicionais
- Como mencionado anteriormente, não existe convenção global sobre o local onde posicionar os dados de uma classe. Porém, no contexto de desenvolvimento mobile, eles são preferencialmente definidos no início da declaração da classe
- Construtores (padrão e não-padrão) são sempre declarados no início da classe, pois é o primeiro lugar para onde o cliente (desenvolvedor) mira para saber como instanciar objetos dela
- Modificações private devem ser sempre usados quando não quisermos expor dados e/ou métodos da classe (encapsulamento). A declaração de modificadores public é opcional, pois dependerá se ele é o modificador default da linguagem-alvo ou não. Por exemplo, em Kotlin, quando não explicitado, public é o modificador de visibilidade default; o mesmo não vale para Java
- Funções/métodos precedidos com private tem o nome de métodos utilitários, pois eles têm uma responsabilidade secundária dentro da classe. Sua declaração deve ser feita sempre no fim de uma classe, pois clientes nunca farão uso explícito deles
Assim, chega ao fim a primeira parte desta série. Nela, quis expor de forma breve - principalmente a desenvolvedores que produzem apps mobile - os pontos fundamentais e básicos sobre OOP. Construir apps também é desenvolver software… SÉRIO??? Sim! Sempre é bom reforçar, pois, por muitas vezes, abdicamos das boas práticas de desenvolvimento em troca de produzir apps em alta velocidade. Desta forma, a qualidade acaba ficando pelo meio do caminho e gerando débito técnico.
Consequentemente, a próxima fase desta série abordará um dos conceitos mais importantes em desenvolvimento de software: SOLID. E, se ele é tão importante para software, será de alta importância no software que rodará em dispositivos móveis também.
E-mail: orogersilva@gmail.com
Linkedin: https://www.linkedin.com/in/orogersilva/
Twitter: https://twitter.com/orogersilva
