Programação Orientada a Objetos no WordPress: Análise, Parte 1
Quando comecei a oferecer associações neste site, sabia que a primeira coisa que queria abordar era uma introdução à programação orientada a objetos.
É algo que parece ser interessante para a maioria das pessoas que trabalham no WordPress, mas há um problema que afasta muita gente ou gera resultados ruins:
A programação orientada a objetos pode ficar complicada rapidamente. E isso se torna desmotivador.
Aqui está o que quero dizer: Digamos que você seja um desenvolvedor WordPress que começa a pesquisar programação orientada a objetos. Ele começa falando sobre classes, construtores e funções, e tudo parece bem.
Mas então ele rapidamente entra em:
- métodos privados e protegidos,
- herança,
- polimorfismo,
- Padrões de design,
- Injeção de dependência,
- repositórios,
- e assim por diante.
É uma bola de neve, não é? E não é assim que tem que ser, mas é difícil encontrar uma introdução adequada, exceto por alguns recursos que estão por aí.
Com tudo isso dito (e servindo de pano de fundo para onde estou indo), eu queria criar uma série de conteúdos para quem:
- estão genuinamente interessados em programação orientada a objetos,
- não sabe por onde começar,
- querem desenvolver suas habilidades,
- quer começar do zero sem escalar para um material mais complicado muito rapidamente.
E é isso que estou começando hoje e no primeiro grande sério planejado para os membros. Com tudo isso dito, vamos começar.
Especificamente, vamos começar a falar sobre programação orientada a objetos, análise, design e por que ela deveria começar por aí.
Programação Orientada a Objetos: Análise
Quando se trata de escrever código, existem atualmente três maneiras populares de fazê-lo:
Sempre que estivermos trabalhando e lendo o código do WordPress, você estará lendo uma combinação de código procedural e código orientado a objetos.
Existem algumas razões pelas quais este é o caso, mas está fora do escopo de nossa discussão.
Isso ocorre porque o WordPress é construído com ambos e porque certos aspectos do desenvolvimento do WordPress podem ser escritos com código procedural, como plugins e temas, e outros requerem desenvolvimento orientado a objetos, como widgets.
Análise e Design
Muitas vezes, a primeira coisa que queremos fazer, como desenvolvedores (iniciantes ou não), é começar imediatamente a escrever código. Eu também recebo. É divertido. Temos uma ideia, queremos dar vida a ela, queremos começar a usá-la e queremos mostrá-la a outras pessoas.
Aqui está o problema de fazer isso: muitas vezes pulamos direto para escrever código para tentar fazer o projeto fazer o que queremos que ele faça.
Se este é um projeto simples (e quero dizer muito simples), então não é um grande problema. Honestamente, eu fiz isso (e o GitHub é a prova disso). Mas quando se trata do trabalho que fazemos na Pressware ; é uma história diferente.
Quando se trata de projetos como esse, queremos fazer um pouco de Análise e Design antes de escrever o código.
O que levanta a questão, o que é análise e design orientados a objetos?
Análise
Resumindo, pense assim:
A análise é o processo de pegar a ideia que o cliente ou que você tem e escavar o que realmente precisa ser construído.
Isso pode ajudá-lo a determinar qual é a vantagem do aplicativo e o que não é necessário para a primeira versão do aplicativo. Eu gosto de rotulá-los como os “must-haves" e quais são os “nice-to-haves”.
Uma boa regra de ouro é esta:
- must-haves são as coisas que são essenciais para o aplicativo e devem ir para a primeira iteração do projeto,
- nice-to-haves são as coisas que podemos eventualmente construir nele
Em última análise, isso nos ajuda a trabalhar em direção a uma primeira versão forte para o cliente. Talvez um exemplo seja para o WordPress:
- A primeira versão do WordPress precisava ter uma API de plugin ou só precisava ter a capacidade de as pessoas escreverem posts e publicá-los na web?
Se você estiver criando uma plataforma para blogs, ela precisa ser extensível desde a primeira versão? Isso nada mais é do que um exemplo, mas você entendeu.
O que torna a análise tão difícil?
Eu acho que muitas vezes tem a ver com personas.
Por exemplo, nós, como programadores, pensamos que um projeto deve sempre fazer o que o cliente deseja. A verdade é que nem sempre é assim.
Quer dizer, eventualmente, pode ser, mas a primeira versão do projeto não precisa necessariamente ser assim.
Além disso, um dos princípios da programação orientada a objetos é que não escrevemos muito código duplicado. Mas isso pode ser muito difícil de fazer se a análise apropriada não for feita.
Finalmente, aqueles que são mais experientes dirão que um bom software usará princípios testados e comprovados – sejam padrões de projeto ou não – mas que podem ser corrigidos facilmente ao longo do tempo. Isso, de certa forma, cresce organicamente.
Então, o que devemos fazer?
No próximo artigo, falarei sobre três coisas que podemos fazer, como desenvolvedores, para garantir que o software que estamos construindo para nós mesmos ou para outros nos leve na direção certa.
Não direi que é uma bala de prata porque não acredito que exista, mas direi que é uma abordagem bastante forte que encontrei outros para usar e bem como eu e que leva a uma direção muito boa em termos de análise orientada a objetos.
Isso acabará nos levando ao design. Mas ainda não estamos lá.