Os dois primeiros pilares da POO

Quando se trata de falar sobre programação orientada a objetos (ou POO), você provavelmente ouvirá sobre Os Três Pilares da Programação Orientada a Objetos ou Os Quatro Pilares da Programação Orientada a Objetos.

Dependendo do seu histórico, você pode já ter ouvido falar deles, saber o que são e realmente não precisa mergulhar muito nisso. Mas se você não tiver, acredito que entendê-los é fundamental para a programação orientada a objetos.

Cobrimos toda a fase de Análise da Programação Orientada a Objetos:

1. Análise, Parte 1
2. Análise, Parte 2
3. Entendendo as expectativas do cliente
4. Declaração de Trabalho
5. Termos e Condições

Com isso dito, vamos entrar nas discussões de design e implementação. Afinal, é para isso que muitas pessoas querem pular de qualquer maneira, não é?

Antes de escrever qualquer código, gostaria de fazer dois posts sobre os quatro pontos da programação orientada a objetos (porque sou um daqueles que concorda com a ideia de que são quatro).

Dois Pilares da POO

Novamente, entendê-los é a chave para entender os fundamentos da programação orientada a objetos. Sem eles, será difícil navegar pelo resto do que será discutido em posts futuros.

Com isso, vamos falar sobre cada um deles. Vamos cobrir os dois primeiros neste post e os dois últimos no próximo post.

1 Abstração

De um modo geral, esta é a chave para escrever código orientado a objetos. Com isso, quero dizer tudo o que está contido em uma classe. Abstraímos a ideia de algo em uma classe. Em muitos livros, veremos coisas como Animais ou Carros representados como classes.

Isso funciona, em teoria, mas na prática, não estamos programando animais nem estamos programando carros (embora eu ache que neste ponto da história, você poderia argumentar que estamos, mas eu discordo porque você sabe o que quero dizer).

Em vez disso, vamos abstrair ideias em suas classes. E há uma ideia chave aqui:

Uma classe deve representar um substantivo.

Ou seja, você não deve ter uma classe que represente algo como “Running". Em vez disso, você pode ter algo que é executado e, portanto,  a execução seria um método. E esse é o detalhamento geral de como a abstração funciona:

1. O que deve ser representado é a classe,
2. O que a coisa faz são seus métodos,
3. E a maneira como você descreve a coisa geralmente pode ser feita por meio de seus atributos ou propriedades.

Isso não significa que não tenhamos funções ou métodos que modifiquem suas propriedades, mas os três pontos acima são boas regras práticas. Então, quando você está criando uma classe, você pode perguntar coisas como:

• Estou escrevendo algo?
• Estou escrevendo algo para fazer?
• Ou estou escrevendo algo que descreve algo?

Porque se você está escrevendo uma ação, provavelmente é feito por algo (porque as coisas agem – elas fazem coisas). E se você está descrevendo algo, então provavelmente se refere a algo (quando foi a última vez que você descreveu nada?)

Faz sentido?

2 Encapsulamento

Então, se estamos escrevendo classes – boas classes – então precisamos escrevê-las de tal forma que estejamos encapsulando adequadamente seus dados. E encapsulamento é realmente apenas uma palavra “grande” que se refere à ideia de gerenciar suas responsabilidades (ou acompanhar seus dados).

Então, por exemplo, se estivéssemos escrevendo uma classe para representar uma postagem do WordPress, teríamos uma classe chamada Post com propriedades como publish, update, delete,  postData, publishDate, lastUpdatedData, deleteDate e assim por diante.

Então teríamos funções projetadas especificamente para agir em uma instância da  classe Post.

Caso em questão, podemos…

• publicar,
• atualizar,
• ou excluir uma postagem

Esses métodos provavelmente serão expostos de forma que outras classes possam aproveitá-los. Além disso, esses métodos provavelmente também aproveitarão outras propriedades, como o publishDate ou o deleteDate.

E é aí que entra o conceito de visibilidade. Na programação orientada a objetos, o encapsulamento não se refere apenas à ideia das informações que uma classe contém, mas como ela expõe os dados.

Isso é feito de três maneiras, todas definidas abaixo:

1. propriedades e funções públicas estão disponíveis para qualquer pessoa usá-las; no entanto,  as propriedades públicas  geralmente não são expostas. Em vez disso, garantimos que eles possam ser modificados por um  método público.
2. propriedades e funções protegidas estão disponíveis para serem usadas pela classe e qualquer outra classe que herde informações dela. Isso será discutido com mais detalhes no próximo post.
3. propriedades e funções privadas são aquelas destinadas exclusivamente a serem usadas no contexto de uma determinada classe. Essas podem ser propriedades usadas para rastrear status internos ou métodos usados ​​para funcionar como funções auxiliares para funções públicas para concluir seu trabalho.

À medida que continuarmos nesta série, veremos o papel que cada um deles desempenha ao escrever classes claras, fáceis de seguir e bem arquitetadas.

Por enquanto, porém, é importante entender que essas palavras, public, protected e private, são chamadas de modificadores de visibilidade porque, como você pode verificar, gerenciam a visibilidade de um método ou propriedade em relação à sua classe e ao classes que herdam dele e que interagem com ele.

Falando em herança, falarei sobre isso na próxima parte desta série.

Abstração, Encapsulamento e WordPress

As más notícias: aulas no WordPress

Aqui está a coisa: no WordPress, muitas vezes vemos classes muito, muito grandes. Isso não é uma coisa boa. Na verdade, esses são antipadrões chamados de classes de deus (a ideia é que você tem uma única classe que sabe tudo).

E quando você tem uma classe de deus, parece conveniente porque você pode colocar todas as funcionalidades em um só lugar. Mas

• é difícil testar,
• não escala,
• ele não funciona bem com outra classe (muito menos classes ou bibliotecas de terceiros),
• não se adapta bem à mudança.

Em última análise, quando você está fazendo isso, você não está fazendo programação orientada a objetos. Você está pegando funções e jogando-as em uma classe. E queremos fugir disso.

A boa notícia: aulas de redação no WordPress

No entanto, isso levanta uma questão: por que tentar aprender programação orientada a objetos com o WordPress se não for um exemplo sólido de programação orientada a objetos?

Isso porque você ainda pode escrever um bom código orientado a objetos no WordPress. Ele ainda pode interagir bem com o WordPress e ainda pode funcionar bem com muitos outros aspectos do WordPress.

Eu sei que parece contra-intuitivo, mas à medida que nos aprofundamos na escrita de código orientado a objetos no WordPress, isso deve ficar claro.