Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação. Você receberá um email de confirmação. Somente depois de confirmar é que poderei lhe enviar o conteúdo exclusivo por email.

Email inválido.
Blog /Livros /Padrões de Implementação - Um Catálogo de Padrões Indispensável Para o Dia a Dia do Programador

Padrões de Implementação - Um Catálogo de Padrões Indispensável Para o Dia a Dia do Programador

Vinícius Thiengo19/02/2016, Sexta-feira, às 01h
(1046) (3) (10)
Go-ahead
"Construa uma voz e uma opinião em primeiro lugar e, em seguida, se essas ressoam com o público, então você vai ter uma audiência."
Adam Carolla
Código limpo
Capa do livro Refatorando Para Programas Limpos
TítuloRefatorando Para Programas Limpos
CategoriaEngenharia de Software
AutorVinícius Thiengo
Edição
Ano2017
Capítulos46
Páginas598
Comprar Livro
Conteúdo Exclusivo
Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação.
Email inválido
Capa do livro "Padrões de Implementação" de Kent Beck
Título
Padrões de Implementação - Um Catálogo de Padrões Indispensável Para o Dia a Dia do Programador
Categoria
Programação de computadores
Autor(es)
Kent Beck
Editora
bookman
Ano
2008
Edição
Páginas
153

Opa, blz?

Terminada a leitura de “Padrões de Implementação - Um Catálogo de Padrões Indispensável Para o Dia a Dia do Programador” de Kent Beck e editora bookman.

Tomara que o que eu vá falar agora lhe deixe com o sentimento de que você tem de ler esse livro. Fiquei surpreendido em não achar avaliações desse livro, na verdade, fiquei depois de ter lido ele. O autor é um dos criadores do JUnit e é o “cara” do Extreme Programming e TDD. Kent Beck é também frequentemente citado nos dois livros de Robert C. Martin, “Código Limpo” e “O Codificador Limpo”. Padrões de Implementação foi fácil o livro que mais me fez evoluir no quesito “padrões" em desenvolvimento de software.

Um dos dilemas do autor é que nós developers devemos sempre programar pensando no humano e não na máquina. Como assim? Tenta imaginar aquele método que você está deixando de realizar uma certa modificação devido ao tempo, cansaço, … e consequentemente a interface para o usuário persiste ainda um pouco mais complexa devido a essa não modificação. Esse é um exemplo de programar pensando na máquina (a complexidade da modificação) e não no humano (a melhora da interface com o usuário).

Outro exemplo é programar pensando no hoje e o amanhã que "se lasque", o prejudicado será você quando precisar voltar ao código ou outros developers que deverão mante-lo. Prejudicados se você não adotou alguns padrões para evitar repetição e se não utilizou, em variáveis e métodos, nomes que indicam a intenção deles.

Kent Beck deixa claro que nós devemos optar por um código limpo que atenda bem a outros developers como aos clientes (esse na interface do sistema), na verdade ele fala bem pouco de cliente e sim de outros developers. Ai pode vir em mente: ok, entendi, tenho de utilizar padrão para isso, para aquilo… Na verdade não, o autor indica que padrões somente devem ser utilizados se forem necessários, principalmente para evitar repetição de código, mas que se os padrões que temos em mãos não forem saudáveis ao projeto ou trecho de código no momento, não devemos utiliza-los.

Nos quatro primeiros capítulos não há padrões, são apresentações de princípios e valores dos padrões de implementação. O código deve comunicar, ser simples e flexível. Esses são os valores que são conseguidos através da prática de padrões dentro dos princípios: consequências locais, minimização de código, lógica e dados em harmonia, simetria, expressão declarativa e ritmo de mudança.

Em consequências locais o autor fala sobre estruturar o código de forma que qualquer mudança tenha consequências locais e consequentemente tenha menos chances de quebrar o sistema. Para se manterem locais as consequências se utiliza de minimização de repetição de código, alias no livro “Código Limpo” muito já falava Martin sobre esse problema e que a maioria dos padrões tem a repetição de código como problema a ser resolvido.

Dados e lógica em harmonia indicam que esses devem estar o mais próximos possível, de preferencia no mesmo método, se não for possível então no mesmo objeto e então, caso a única escolha seja essa, no mesmo pacote. Pois a mudança em um, segundo o autor, implicará muito provavelmente na mudança do outro, logo quanto menor o escopo, mais o principio das consequências locais é atendido.

Simetria é mais código que teoria. Basicamente seria algo como: ao invés de colocar o código count++ entre os métodos init() e output(), coloque um novo método que terá o conunt++ como conteúdo, esse novo método deve ter um nome que auxilie um fácil entendimento do código, processCount(), por exemplo. Então teremos: init(); processCount(); output().

Expressão declarativa se mantém na expressão da intenção do código por meio de nomes de variáveis e métodos, selecionados de forma correta além da ordem com que essas declarações são apresentadas. Ritmo de mudança é mais código, como em simetria. Como exemplo: se sua classe tem duas propriedades que sempre que uma é alterada a outra também é alterada, isso é uma clara indicação de que na verdade você tem é outra classe, logo essas propriedades vão para uma nova classe e sua classe atual passa a ter apenas uma nova propriedade, da nova classe.

Esses são os principios dos padrões de implementação. Com isso o autor segue apresentando os 77 padrões a partir do capítulo cinco. Muitos dos padrões são, provavelmente, técnicas que você já utiliza, por exemplo, ao invés de passar vários parâmetros como argumentos de métodos, isso repetidas vezes, o autor indica que coloquemos esses vários parâmetros em um objeto e então passar esse objeto. Isso é um padrão, Objeto Parâmetro. No Java pode ser um pouco mais chato de implementar, linguagem de tipagem forte. No PHP com a classe padrão stdClass é muito tranquilo.

O autor fala do problema de se utilizar interfaces de forma demasiada para não "queimar o tiro" utilizando herança com uma classe abstrata. O problema das interfaces reside em que se houver alteração em alguma das fornecidas, isso implica em alteração nas classes que a implementa, ou o programador implementa a alteração ou o código quebra. Isso atrapalha a evolução do código, pois o escopo de falha é muito grande. A solução fica em utilizar interfaces versionadas, que são interfaces novas que herdam das atuais e ampliam as funcionalidades, algo que o autor indica evitar.

A melhor coisa a se fazer é pensar corretamente se as funcionalidades que deveram ser implementadas por classes especializadas vão vir de uma entidade que poderá sofrer ainda mais alterações ou não. Caso sim para mais alterações, então é bom pensar em classes abstratas, pois essas permitem implementações dos métodos evitando o código quebrado.

Um padrão que é importante entender, ao meu ver, é o padrão Objeto Método. Onde quando há métodos grandes com implementações que não se enquadram na classe atual, cria-se uma nova classe para cada um desses métodos. Cada nova classe terá o mesmo nome do método. O conteúdo do método será enviado para um método dentro dessa nova classe, o método dessa nova classe, a principio, terá o mesmo nome anterior, na primeira classe. Todas as variáveis locais e de instancia que estão no método serão transformadas em variáveis de instancia. Agora sim começa a refatoração. Esse método grande na nova classe começa a ser desmembrado em métodos menores e ai é mais tranquilo de observar a necessidade de transformar o que era variável de instancia em variável local para limitar ainda mais o escopo delas, as variáveis.

O padrão Objeto Método é fácil de enxergar se você tem JOINs em suas SQLs. Alguma classe terá de ficar, ao menos, com o conteúdo inicial antes de chegar até ao código SQL, nesse caso ficam muitos objetos de tipos que não pertecem ao contexto classe sendo manipulados nela, impedindo até mesmo a refatoração criando métodos menores. O padrão Objeto Método resolve isso.

Outro padrão muito útil é o Clausula de Guarda, utilizado para evitar condicionais aninhados. O código ainda continua com as condicionais, porém ao invés de aninhamento de condicionais a verificação é em sequencia. Se o primeiro condicional for verdadeiro, por ser uma clausula de guarda, o condicional tem de estar verificando para falha, logo se for verdadeiro ele para a execução desse método, caso contrário vai para o condicional em sequencia, um após o outro até passar por todas as lógicas que podem indicar falha. Veja a implementação abaixo de um código sem Clusula de Guarda:

public function method(){
$server = $this->getServer();
if( !is_null($server) ){
$conn = $server->getConnection();
if( !is_null($conn) ){
// TODO
}
}
}

Agora com o código implementando o padrão Clausula de Guarda:

public function method(){
$server = $this->getServer();
if( is_null($server) ){
return;
}

$conn = $server->getConnection();
if( is_null($conn) ){
return;
}

// TODO
}

Kent Beck explica no livro que sem aninhamento de condicionais, código em geral, suas chances de ter erro na lógica são menores.

O autor mostra que quanto menor o escopo de atuação das entidades de seu projeto, mais flexível ele é, pois o risco de alterar uma variável privada e consequentemente quebrar o código em outra parte do sistema é muito inferior quando se tem entidades protegidas ou publicas. Logo um caminho para criar classes, segundo o autor, é criando com todas as entidades, variáveis e métodos, sendo privados e somente ir mudando o tipo de acesso de acordo com a necessidade do projeto.

Novamente, como no livro “Código Limpo”, o autor fala que não montamos um código bonito de primeira, na verdade é tudo em um método somente para resolver a lógica necessária. Depois voltamos e refatoramos o código. Caso contrário, tentar logo de inicio ter um código limpo, segundo o autor é um escolha não inteligente, o tempo será bem maior para uma solução incerta.

O capítulo dez, o último, sobre evolução de framework eu quase pulei imaginando que não seria interessante, até porque não tenho planos de desenvolver um. Mesmo assim o li. Sem arrependimento, o capítulo é muito show de bola igualmente todo o restante do conteúdo. O autor informa que quando trabalhando com o desenvolvimento de framework o pensamento do programador deve ser diferente. No dev de aplicações pensa-se em código limpo para uma boa leitura por parte de outros programadores e até mesmo do developer do código, para a possível evolução do software. No caso das frameworks as vezes o caminho complexo para a evolução dele é o melhor caminho, pois dessa vez, tendo em mente que os clientes são outros developers, o framework não pode deixar de dar suporte as implementações antigas sendo ainda utilizadas, pelo menos por um certo período de tempo (período informado ao cliente do framework).

Ou seja, um estilo de pensamento tem foco no código limpo para outros poderem ler. O outro tem foco no código complexo para que versões antigas do framework ainda continuem com suporte.

O capítulo nove pode ser o que você ache não relevante, pois ele é especifico para developers Java, mas nada de muito complexo, o autor fala sobre Collections em Java. Alias os códigos utilizados em todo o livro são em Java. No começo do livro o autor informa sobre os códigos em Java, pode até parecer intimidador, mas não, se o maior código apresentado tiver 10 linhas é muito. uma vantagem do livro é que você não precisará de um IDE aberto para acompanhar, nem mesmo tem códigos completos.

O livro é se pouco excepcional. É bom que você tenha um conhecimento mínimo sobre o paradigma orientação a objetos. Com esse pré-requisito você vai evoluir muito na leitura dele. O autor é bem claro e não há aqueles blocos imensos de textos. O livro é pequeno, sem apêndice são 128 páginas, com um total de 153. No final do livro tem algumas dicas de leitura, incluindo filosofia.

Falei muito sobre os livros “Código Limpo” e “O Codificador Limpo” do Martin, realmente são bons, recomendo que os leia, mas se tiver dinheiro somente para um dos três, fique com o “Padrões de Implementação”. Vou de cinco estrelas “berando” fácil a sexta (e inédita) estrela.

Vlw.

Receba em primeira mão o conteúdo exclusivo do Blog, além de promoções de livros e cursos de programação.
Email inválido

Relacionado

Engenharia de Software: Código Limpo na PráticaEngenharia de Software: Código Limpo na PráticaDesenvolvimento Web
Código Limpo - Habilidades Práticas do Agile SoftwareCódigo Limpo - Habilidades Práticas do Agile SoftwareLivros
Amazon Web Services Em AçãoAmazon Web Services Em AçãoLivros
O Codificador Limpo - Um código de conduto para programadores profissionaisO Codificador Limpo - Um código de conduto para programadores profissionaisLivros

Compartilhar

Comentários Facebook (3)

Comentários Blog

Para código / script, coloque entre [code] e [/code] para receber marcação especifica.
Forneça seu nome válido.
Forneça seu email válido.
Forneça o comentário.
Enviando, aguarde...