Use a Cabeça! Padrões de Projetos

Capa do livro "Use a Cabeça! Padrões de Projetos" de Elisabeth e Eric Freeman

Opa, blz?

Finalizada a leitura do livro Use a Cabeça! Padrões de Projeto, 2ª edição, de Elisabeth Freeman e Eric Freeman, 496 páginas, 2007, editora Alta Books.

Como nos outros livros da série Use a Cabeça, com esse não foi diferente, conteúdo útil para qualquer desenvolvedor de software e muito bem explicado, muitas imagens, perguntas fora do comum em livros de tecnologia e, para ajudar a fixar o conhecimento, muita história.

O objetivo do livro é apresentar os padrões de projetos mais utilizados de maneira simples onde até mesmo os programadores sem muito tempo de experiência possam entender.

Os padrões abordados são: Strategy, Decorator, Factory Method, Abstract Factory, Singleton, Command, Adapter, Template Method, Iterator, Composite, State, Proxy (convencional, virtual e dinâmico) e o MVC (padrão composto). Esse último com uma variação para o ambiente Web chamada de Modelo 2.

A linguagem de programação adotada no livro é o Java. Os autores assumem que você sabe o mínimo, incluindo compilar e executar um código Java. Caso não tenha conhecimentos na linguagem é possível sim seguir com a linguagem que você já utiliza, os exemplos são realmente simples e podem ser facilmente migrados ente linguagens que também trabalham com orientação a objetos.

Somente quando há códigos da Swing API (dois exemplos do livro) é que a sua estrutura (utilizando PHP, por exemplo) muda bastante. Porém não se preocupe quanto a isso, pois são exemplos secundários, não tão importantes quanto os exemplos dos padrões abordados no livro (tirando o MVC que utiliza a Swing do início ao fim).

No livro os autores passam a verdadeira importância dos padrões de projeto, e pode acreditar, não é a solução do problema que eles estão propostos a resolver e sim a linguagem universal que eles promovem entre programadores.

Sério! Um exemplo: caso um programador da chinês utilize o padrão Observer ele tende a utilizar o nome Observer como parte do nome de cada entidade do trecho de código desse padrão no projeto (exemplo: MeteorologiaObserver, Observer, …).

Esse estilo padrão de nome é na verdade uma convenção na computação para quando você for utilizar padrões. Programadores dos mais diferentes níveis tendem a conhecer convenções de programação (lembra do CamelCase para variáveis, métodos e classes?), pois mesmo sem saberem do real benefício, convenções deixam o código simples de entender.

Ok, mas o que o nome do padrão sendo utilizado nas entidades que o aplicam tem haver com uma linguagem universal?

É ai que mora a “Linguagem Universal”, pois somente de ter o Observer como parte do nome é o suficiente para um programador dos Estados Unidos, Brasil e de qualquer outro lugar conseguir já entender o que está sendo feito, pois mesmo que o padrão Observer do developer chinês tenha sofrido alterações ele tem um funcionamento fundamental que é nada mais nada menos que o funcionamento definido pelo padrão Observer.

A princípio pode soar estranho saber que o principal ganho na utilização de padrões de software é a linguagem universal empregada por eles, mas com o decorrer do livro você realmente entende que essa é sim a parte que faz a diferença. Sabendo da importância de um código limpo fica ainda mais evidente a importância de uma linguagem universal.

Aliás, provavelmente você já deve ter lido algo sobre "Código Limpo", caso não tenha lido, veja essas resenhas que fiz sobre dois bons livros abordando esse assunto:

Código Limpo - Habilidades Práticas do Agile Software

O Codificador Limpo - Um código de conduto para programadores profissionais

Com isso você provavelmente deve saber também que o termo "Código Limpo" é muito abordado devido ao custo no entendimento de códigos alheios, isso, códigos que não foram escritos pelos atuais developers responsáveis por ele.

O custo gira na casa dos 90%. 10% fica para a refatoração / evolução do código.

Para ficar ainda mais claro vamos a um exemplo. Você não é developer e então contratou um time para desenvolver sua APP. Depois que acabou o contrato você preferiu seguir com outro time, devido aos custos. Do valor pago por hora para esse novo time, caso o código da APP não esteja limpo (respeitando os princípios de orientação a objetos e utilizando convenções de programação, pelo menos) o novo time vai gastar em torno 90% do tempo pago para entender esse código antigo. Isso até que ele se acostume com o modelo ou então mude tudo.

Tendo em mente essa problemática não é difícil entender que uma linguagem universal alivia em muito o entendimento do código, pois, como no exemplo acima do programador chinês.

Se sabemos que um Observer está sendo utilizado basta ir em algum catálogo de padrões de projeto (ou até mesmo no Wikipédia) para relembrar o diagrama e então no código atual buscar as classes similares as do diagrama que devem estar sendo utilizadas para seguir a leitura do algoritmo sem muitos desafios.

Obviamente que os autores deixam claro que a utilização de padrões é apenas parte da linguagem universal, ainda temos os princípios e convenções.

Alias, outro ponto que a princípio é ainda mais importante que padrões de projeto e é abordado no livro é a apresentação e estudo dos princípios da orientação a objetos.

Os autores explicam a importância de sempre seguir os princípios da orientação a objetos, algo diferente que quando pensando em padrões, que somente devem ser utilizados quando possível e enxergada a oportunidade de melhorar o código sem ter em mente algo ainda mais simples que um padrão.

Você deve ter se perguntado: Quando possível e enxergada a oportunidade?

Sim. Padrões somente devem ser utilizados quando eles melhorarem a eficiência do projeto, incluindo a leitura do código (lembre da linguagem universal), mas sempre deve ser ao menos testada uma solução ainda mais simples, que não necessite de padrões, pois alguns padrões, mesmo que úteis, têm implementação complexa.

No capítulo final do livro, Padrões no Mundo Real, os autores são muito esclarecedores sobre o que realmente são os padrões, quando utiliza-los, porque utiliza-los, porque não utiliza-los e como criar os seus próprios.

Criar os meus próprios?

Sim, nesse capítulo final há um roteiro do que deve ser realizado para você documentar seus próprios padrões.

Esse roteiro se resume na utilização de uma modelo de documento para a descrição do padrão e a utilização do padrão descoberto por você em ao menos três outros projetos do mundo real em que ele teve sucesso. Projetos de outros developers, não os seus apenas.

Por que três e não dois?

Bom. É aquilo, eu particularmente não sabia que existia um número mínimo de aceitação, mas segundo os autores Elisabeth e Eric, têm. Provavelmente é um acordo na comunidade de descobridores de padrões (padrões são descobertos e não criados), então vamos assumir três como sendo o número mínimo.

Pontos negativos

Os exemplos que utilizam o Swing API são realmente grandes, acredito que era possível apresentar os conteúdos que utiliza essa API sem ter de utiliza-la, pois em Java quando o assunto é interface com o usuário em sistema Desktop o código cresce consideravelmente.

A tradução para o português ficou um pouco confusa, por exemplo: as palavras cruzadas ficaram as vezes com termos traduzidos e as vezes não, além de ter em alguns pontos mais perguntas do que espaços na tabela de palavras cruzadas para serem preenchidos.

O livro, apesar de ser um tanto antigo, 2007, ainda tem um preço alto, a última vez que verifiquei (na construção desse post) estava em torno de R$ 143,90. E infelizmente para nós programadores esse é um tipo de assunto que não tende a sair de moda como acontece com algumas linguagens ou libraries, Cobol e Dojo em JavaScript, por exemplo.

No apêndice do livro são informados de forma resumida alguns outros padrões que os leitores podem estar estudando, são eles: Bridge, Builder, Chair of Responsability, Flyweight, Interpreter, Mediator, Memento, Prototype e Visitor.

Pontos de destaque

A explicação da importância de sempre adotar os princípios de orientação a objetos, pois diferente dos padrões eles são sempre úteis.

A orientação para sempre optar pelo mais simples e que nem sempre (quase sempre) a adoção de padrões é o mais simples, aliás se utilizados de forma excessiva eles podem acabar gerando problemas maiores. Os autores comentam sobre o problema dos iniciantes em partes de projeto: querer utilizar um padrão para até mesmo um simples “Hello World!”. Segundo eles, com a experiência sendo adquirida isso é superado.

Ao meu ver o maior destaque fica com a informação de que devemos saber apenas quando um padrão deve ser aplicado, quando utilizar um Observer, por exemplo. Assim que identificada a oportunidade de melhorar o código com um determinado padrão é importante voltar ao catálogo de padrões e então estuda-lo melhor para implementa-lo.

Isso mesmo, se você achava que deveria gravar os passo a passo em sua cabeça, não precisa, os autores mesmo falam que eles não fazem isso.

Conclusão

O livro é excelente e se você é programador ou conhece algum, estudar padrões de projeto é essencial para melhorar as habilidades como desenvolvedor.

Claro que sabemos que teoria é a menor parte do processo, a prática é que vai fixar o conhecimento e o livro Use a Cabeça! Padrões de Projeto explica de maneira simples e o faz implementar os projetos dos exemplos.

O livro é útil principalmente para aqueles que não tiveram contato ainda com padrões ou tiveram, mas ainda restam várias dúvidas sobre o assunto, incluindo os princípios de orientação a objetos.

A realidade é que diferente de algumas profissões em que muito se fala na continuação dos estudos, algo que nem sempre é seguido, developers não têm escapatória, têm de estudar e praticar sempre, muitas vezes a mesma tecnologia para se tornar especialista nela.

Sabendo ao menos o básico de orientação a objetos seu próximo passo são padrões e princípios para aumentar sua performance como coder. O livro apresentado aqui é um bom início.

Mas sabemos que o valor dele pode ser um impedimento por agora, mesmo tendo em mente que um livro técnico em sua área sempre é um investimento. Com isso, há “n” blogs e sites que abordam os assuntos padrões de projeto e princípios de orientação a objetos com no mínimo a mesma eficácia que o livro mostrado aqui, logo a lista de padrões mais utilizados você tem nesse post, basta começar as pesquisas e estuda-los.

Vlw.

Relacionado

Refatoração de Código: Unificar Interfaces Com AdapterAndroid

Monetização sem Anúncios utilizando a Huq SDKAndroid

As 33 Coisas que Todo Programador Deve Parar de FazerEmpreendedorismo

10 Sites que Ajudam Você a se Tornar um Expert em LínguasEmpreendedorismo

Comentários Blog (1)

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.

Enviar

Enviando, aguarde...

George Santos (1) (0)

13/08/2016

Aprende muito com esse livro. vale a pena.

Responder