Apresentação – SOLID

Continuando os estudos sobre os princípios básicos de orientação objetos, segue uma ótima e ilustrada apresentação sobre o mesmo assunto:

“Porque, pela graça que me foi dada, digo a cada um dentre vós que não pense de si mesmo além do que convém; antes, pense com moderação, segundo a medida da fé que Deus repartiu a cada um.” Romanos 12:3

Anúncios

Flexibilidade OOP – S.O.L.I.D

“Hoje em dia, a maioria dos desenvolvedores de software esta utilizando linguagens orientadas a objetos, mas infelizmente, a maioria deles as utiliza sem o devido conhecimento, sem saber como extrair o máximo de benefícios dos recursos que elas oferecem. Muitos desenvolvedores, apesar de usar estas linguagens, programam de forma procedural, e assim o código fica muito complexo e pouco flexível. Por isso, muitas vezes culpam a linguagem que utilizam por um problema causado pela falta de conhecimento.”

Este ótimo artigo escrito por David Pereria na revista Java Magazine edição 79 discute e apresenta detalhadamente os cinco princípios mais básicos da orientados a objetos que devem estar na cabeça de qualquer pessoa que deseje escrever um código limpo, flexível e manutenível. Por este motivo, resolvi postar este resumo com objetivo de usá-lo como consulta rápida nos momentos críticos ai de desenvolvimento.

Single Responsibility– descreve que cada objeto deve encapsular apenas uma responsabilidade. Todo o seu serviço disponível deve estar alinhado a essa determinada responsabilidade.

Open Closed – descreve que entidades de software devem estar abertas para extensões e fechados para modificações. Ou seja, uma entidade pode permitir a mudança de seu comportamento sem alterar o seu código fonte original.

Liskov Substitution – define que não devem existir validações que envolva objetos concretos em estruturas polimórficas. As estruturas de execução precisam ser resolvidas 100% com polimorfismo.

Interface Segregation – define que objetos concretos não podem ser forçados a implementar comportamentos no qual não será usado por eles. As estruturas abstratas devem ser corretamente dividas de uma forma que estabelece estruturas polimórficas sem propagar comportamentos indevidos ou desnecessários para os objetos concretos.

Dependency Inversion – define que módulos de altos níveis não devem depender de módulos de baixos níveis. Ambos precisam depender de abstrações. As dependências devem ser injetadas via construtor ou método set por uma entidade externa a aplicações.

Um modo bacana de memorização é usar a dica do autor que concatenou as letras iniciais da cada principio chegando à palavra SOLID.

“O que a mim me concerne o SENHOR levará a bom termo; a tua misericórdia, ó SENHOR, dura para sempre; não desampares as obras das tuas mãos.” Salmos 138:8

MundoJava – 50% desconto nas edições anteriores

APROVEITE

Complete sua coleção comprando as edições da MundoJava que ainda faltam para você!!

Nesta promoção imperdível você poderá adquirir as edições anteriores pela metade do preço.

Verifique agora mesmo quais edições você não possui e faça seu pedido.

A promoção vale para pagamentos até dia 20/07/2010 ou até durar o estoque.

A solicitação de exemplares anteriores pode ser realizada através do site da revista.

“Todavia, o Senhor é fiel; ele vos confirmará e guardará do Maligno.”  2 Tessalonicenses 3:3

Filosofia Orientação Objetos

A arte da OOP define uma diretriz que apenas aponta para a direção de um caminho que pode ser seguido. Ou seja, ninguém é obrigado a andar por ela, mas o que eu percebo nos lugares que tenho passado é que as pessoas deixam de usá-la por questões relacionadas a uma falta de entendimento sobre a sua filosofia. Com isso, posso afirmar que a motivação é simples:

O objetivo primordial da OOP é fazer com que a infra-estrutura do projeto de software seje flexível ao ponto de dar ao próprio autor o controle total e pleno de suas estruturas internas de execução.

O assunto é tão badalado há muitos anos nas literaturas quanto na web justamente pelo fato de que no ciclo de vida de um sistema, os responsáveis gastam mais tempos alterando (80%) do que criando (20%). Exemplificando o caso, em um sistema de 10 anos de idade, os autores em media gastam dois anos para criar e oito para dar manutenção (correções ou novos requisitos). Com isso, não existe dúvidas de que aplicar a OOP na construção de um sistema é algo indiscutivelmente benéfico para todos os envolvidos. A elaboração e a construção de um sistema consistem em nada mais do que automatizar uma serie de rotinas que manipulam as entradas e saídas de informações que acontecem no mundo real. Como o objetivo é fazer o computador executar isso, as rotinas e as informações precisam ser identificadas e corretamente programadas para serem executadas dentro de um programa. É ai que entra a OOP com a sua filosofia de organizar todas estas rotinas e dados em entidades denominadas Objetos.  Dentro deste contexto, eu resolvi então escrever este artigo para discutir e resumir as diretrizes mais básicas e iniciais que devem ser consideradas e digeridas por qualquer pessoa que deseje aplicar com sucesso a OOP dentro de seu projeto de software.

Filosofia OO

Muitas pessoas ainda não perceberam que vivem em um mundo que é orientado a objetos. Indiretamente elas sabem disso, mas nunca pararam para raciocinar em cima da questão. Pare e pense… veja a sua volta. Responda as seguintes questões:

  1. Um cachorro é um ser humano?
  2. Uma pessoa pode voar?
  3. Uma caneta tem uma tampa ou a tampa tem uma caneta?

Todas as pessoas podem responder estas perguntas provando que qualquer um sabe lhe dar com os princípios da orientação a objetos, mas poucas podem tecnicamente explicá-las. Segue as respostas com algumas explicações bem simples, sem entrar em muitos detalhes ou variantes:

1. Não é porque o cachorro não aparenta ser e não se comporta como um ser humano – Objetos são classificados de acordo com sua aparência (propriedades) e comportamentos (métodos) que expressam o que este determinado objeto pode realizar. Já as classificações são agrupadores de objetos usados para definir aparência e comportamento geral para um conjunto de objetos e neste caso, o termo “Humano” é usado como uma classificação no qual estamos tentando colocar cachorro.

2. Não porque uma pessoa no mundo real não possui este comportamento – Objetos são capacitados de comportamentos individuais que refletem o que eles podem fazer. O que defini os comportamentos de um objeto é justamente a classificação na qual ele se encaixa e que neste caso, a pessoa no mundo real pode pertencer a varias delas, mas nenhumas delas expressa este comportamento.

3. Uma caneta tem uma tampa – Objetos existem para ser relacionar entre si e assim conseqüentemente gerar um comportamento maior. Este é o caso da maioria dos objetos existente do mundo real que nada mais é um aglomerado de objetos correlacionados entre si, gerando outro objeto maior composto. No mundo real, vemos que uma caneta não é um objeto, mas sim um ajuntamento de objetos menores, que poderíamos descrever como CANETA = TUBO + BICO + REFIL + TAMPA.

Veja que poderíamos até entrar em mais detalhes nesta análise de objetos ou abordar outras questões relacionados, mas meu único interesse é enfatizar que para se construir um programa OO é necessário visualizar as rotinas e os dados da automatização como se eles fossem objetos que acontecem no mundo real. Cada um precisa assimilar a idéia da filosofia no qual o paradigma se baseia, para que possa se desenvolver positivamente com sucesso.

Identificação de Objetos

Consiste na tarefa de identificar quais serão os objetos e suas responsabilidades do mundo real que serão automatizados para dentro do programa de computador. A palavra identificar foi destacado na frase acima porque tem alguns significados subliminares como: descobrir, abstrair, visualizar etc.… Também muito conhecido como Modelagem de Objetos que consiste no uso sistemático de algumas técnicas e metodologias comprovadas que podem ser usadas para se identificar os objetos na determinada solução. É aqui que a coisa pega, sendo que é o lugar de maior problema por que um projeto OO se torna inconsistente quando os objetos implementados na solução não refletem a realidade das ocorrências no mundo real. Craig Larman em seu livro Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process escreveu a seguinte frase:

A habilidade mais importante em um projeto OO é de atribuir responsabilidade a um objeto… por que ela influencia drasticamente a robustez, facilidade de manutenção e a reusabilidade de um componente de software.

Na prática, os projetos reais começam a ficar engessados e inflexíveis entrando no caminho da baixa manutenção devido às definições/implementações de objetos inconsistentes com o mundo real da solução. Exemplificando o caso, seria como se no mundo real existissem dois objetos interagindo entre si e na implementação desta aplicação, foi abstraído e implementado apenas um. Ou vice-versa, no mundo real existe apenas um objeto assumindo certa responsabilidade no qual o responsável do sistema implementou separado em dois ou mais objetos diferentes. Resumindo, o responsável pela modelagem do sistema OO não conseguiu por algum motivo visualizar e entender claramente as ocorrência dos objetos da solução. Depois da solução implementada, o sistema poderá funcionar lindo e maravilhoso sem nenhum problema no ponto de vista do usuário final, mas sua evolução e manutenção poderão estar comprometidas devido a sua estrutura de modelagem.

Algo que eu gostaria ressaltar neste tópico é que as aplicações OO estão em constantes evoluções à medida do tempo. Isso quer dizer que o um sistema não precisa implementar 100% da ocorrência do mundo real, em uma primeira versão. Ele precisa na verdade, passar por varias refinações incrementais, várias versões diferentes mas que todas elas sempre atendam duas necessidades básicas:

1. Requisitos do Cliente –  a versão do sistema precisa fazer o que ele foi proposto a fazer, resolver algum problema ou automatizar algum procedimento/tarefa.
2. Arquitetura Manutenível – a versão do sistema deve possuir uma estrutura de objetos que expresse flexibilidade para sua próxima evolução.

Infelizmente o mais comum que encontramos nas empresas são sistemas que cumprem os requisitos do cliente sem modelagem nenhuma de objetos. Quem já passou pela péssima experiência em evoluir sistemas assim é que realmente pode dizer. Na OO existe uma pratica pouco divulgada nas instituições de ensino que é chamado de Principio da Responsabilidade Única que na minha opinião resolve a maioria destes problemas de identificação de objetos. Resumidamente a pratica diz que um objeto só pode existir para encasular apenas uma única responsabilidade que justifica a sua existência na modelagem. Ou seja, um objeto não pode fazer duas ou mais coisas  por que fará com que varias implementações de responsabilidades diferentes/relacionadas coexistem misturadas/costuradas na mesma unidade de implementação. Em outras palavras, se um objeto esta responsável por fazer duas coisas, quando uma destas sofrer manutenção, a outra terá como resultados efeitos colaterais de manutenção.

Identificação dos Relacionamentos

Juntamente com o levantamento dos objetos, surge à necessidade de identificar quais serão os relacionamentos existentes entre eles. Para a felicidade de todos, existem apenas três tipos:

Herança – relação de “paternidade/filiação” aonde objetos podem ser estabelecidos como filhos de outros objetos pais.
Associação – relação de “usabilidade independente” aonde objetos podem usar outros objetos sem nenhuma dependência entre eles. Também conhecido como agregação simples.
Agregação – relação de “usabilidade dependente” aonde objetos podem usar outros objetos, estabelecendo dependência entre eles. Também conhecido como agregação por composição.

Filosoficamente dizendo, poderíamos visualizar como se tivéssemos no mundo real estes três tipos de relacionamento. Então para se descobrir qual destes selecionar na implementação de um caso OO, é necessário primeiramente entender as suas particularidades especificas que eu deixarei de fora deste artigo. E assim, posteriormente olhar para mundo real da solução e verificar qual destes se encaixa melhor nas abstrações em modelagem. Um complicador de peso nos relacionamentos é que eles dependem das corretas definições dos objetos. Ou seja, se os objetos foram modelados inconsistentemente, os relacionamentos também apresentarão inconsistências.

Na prática, os projetos reais começam a caminhar no sentido da inflexibilidade devido a uma inversão de valores nos relacionamentos. Ou seja, aonde era para existir uma agregação, foi inconsistentemente colocado uma herança, e assim por diante. Cada decisão errada faz o projeto ir evoluindo gradativamente para o engessamento, uma vez que uma decisão arquitetural inconsistente vira fundamento para outras posteriores.

Conclusão

A construção de um sistema OO consiste na tradução de todos os dados e procedimentos do mundo real para unidades de execuções denominados de objetos com seus relacionamentos. A questão que pega é

“Será que conseguiremos traduzir e transpor o mundo real em automação de forma que reflita a realidade das coisas ?“

Implementar um programa OO é fácil, o complicado é modelar o sistema de tal forma que reflita o negócio em questão de forma que expresse uma estrutura de projeto flexível e reutilizável. O que eu gostaria de enfatizar é eu percebo uma inversão de valores, onde vejo os profissionais perdendo mais tempo escrevendo código dos sistemas que na verdade, deveríamos gastar mais tempo/esforços modelando as abstrações. O assunto é bem polêmico e levantam várias questões, nada melhor que deixar o artigo aberto para opiniões e comentários. Aquele forte abraços a todos.

“Que aproveita ao homem ganhar o mundo inteiro e perder a sua alma?” Marcos 8:36

Profissão Java 2010

 Profissão Java 2010, um evento organizado pela Globalcode

“O Profissão Java é um evento para profissionais que desejam entrar no mercado, que estão buscando uma recolocação profissional ou mesmo querem dar um novo rumo na sua carreira. O foco é carreira!
Mesmo assim, procuramos trazer à tona quais assuntos atuais que possuem relevância na área técnica e que podem ser diferenciais para o profissional.
Vamos contar com diversas experiências de pessoas realizadas profissionalmente e grandes empresas expondo o que buscam no mercado.
Queremos uma dinâmica de palestras bem otimizada, não queremos entediar a audiência com palestras gigantes de 1 hora. Também buscamos mais brevidade, foco e relevância no conteúdo das apresentações.”
Veja a programação completa no site oficial.

“Cantarei ao SENHOR, porquanto me tem feito muito bem.” Salmos 13:6