As Leis do Mundo dos Objetos - Melhores Práticas em Orientação a Objetos

Introdu��o

O advento do computador pessoal (PC) deu o impulso comercial definitivo a �rea de Ci�ncias da Computa��o. Hoje em dia, � indiscut�vel a presen�a e import�ncia dos sistemas computadorizados em nossas vidas, seja atrav�s do PC, Internet, celulares, PDA�s, videogames, etc.

Para atender aos anseios dessa verdadeira Sociedade Digital, sistemas complexos com milhares de linhas de c�digo s�o produzidos todos os anos. Com isso uma quest�o se tornou imperativa: como lidar com a crescente complexidade do desenvolvimento de software?

A resposta veio atrav�s do Paradigma da Orienta��o a Objetos (POO).

Orienta��o a Objeto

Esse novo paradigma foi uma evolu��o natural da Programa��o Estruturada/Modular. A id�ia em si � genial: visualizar um programa como sendo uma rede de relacionamento entre objetos. A grande sacada � dividir a complexidade do sistema em pequenas unidades l�gicas (objetos), tornado-a mais facilmente gerenci�vel. E al�m do mais, � uma solu��o mais natural para n�s, visto que lidamos com objetos diariamente no "mundo real".

No mundo f�sico, cada objeto t�m um papel bem definido. Todos sabem para que serve um garfo, um telefone, uma caneta, etc. Podemos dizer que todo objeto t�m uma ou mais finalidades (comportamento) e caracter�sticas f�sicas (atributos).

Isso n�o � novidade para aqueles que lidam com linguagens OO. Mas o que muitos desconhecem � que, assim como no mundo f�sico, o mundo dos objetos virtuais tamb�m t�m suas "leis da f�sica" que, se respeitadas, resultar�o em sistemas bem projetados.

Figura 1: Rede de Objetos

As Leis da F�sica do Mundo dos Objetos

Voc� j� deve ter ouvido falar, principalmente de programadores seniores e arquitetos, termos como GRASP, SOLID, Design Patterns, D�bito T�cnico, Coes�o, Acoplamento, Lei de Demeter, Convention Over Configuration, TDD, DDD, DRY, Imutabilidade, Refactoring, etc. Essa sopa de letrinhas, embora presente amplamente na literatura sobre OO, n�o faz parte do card�pio de boa parte dos programadores de software, infelizmente. Por n�o respeitarem as "leis da f�sica" do mundo OO, acabam gerando sistemas altamente complexos, de d�ficil manuten��o e engessados.

Devemos ter sempre em mente que o objetivo da OO foi justamente administrar a complexidade dos sistemas, atrav�s de unidades de c�digo (objetos) bem definidos que se relacionam entre si. A quest�o chave est� em como montar esses blocos de informa��o de uma forma que o sistema resultante seja coeso e modular.

Para isso, �remos nos debru�ar sobre cada lei da f�sica desse mundo dos objetos, para que os desenvolvedores possam visualizar as vantagens de se adotar esses conceitos na sua programa��o di�ria.

Figura 2: Sistema OO Complexo

Primeira Lei da F�sica OO: Dois corpos n�o ocupam o mesmo lugar no espa�o

Segundo as leis de Newton, dois corpos n�o podem ocupar o mesmo lugar no espa�o. Essa lei f�sica, de f�cil entendimento, �, por sua vez, transgredida diariamente pelos desenvolvedores. Teimamos em desafiar constantemente as leis naturais, criando verdadeiras aberra��es f�sicas, objetos frankstein's, que fazem de tudo, que agregam demais, que sabem demais.

Por exemplo, temos a seguinte classe:

Figura 3: Classe Carro

A classe acima representa o conceito de carro do mundo f�sico e possue dois m�todos, frear() e tocarCD(). N�o h� nada demais nessa classe. Ser�?

Se pararmos para pensar, o m�todo tocarCD() realmente deveria fazer parte da classe Carro? Afinal quem toca o CD n�o � o carro, e sim o r�dio embutido nele.

Uma modelagem mais adequada seria ent�o:

Figura 4: Classes Carro e Radio

� assim que funciona no mundo real. Cada objeto realiza o seu papel. No caso da figura 3, � como se estivessemos criando um objeto h�brido, que desempenha a fun��o dos dois objetos, simultaneamente. Na verdade, essa classe nem merecia ser chamada de Carro, e sim Carradio (Carro + Radio).

Figura 5: Uma clara viola��o das Leis de Newton

Evitar que objetos assumam responsabilidades que n�o lhe dizem respeito. � esse o significado do SRP (Single Responsibility Principle), o "S" do acr�nimo SOLID.

Quando um objeto faz coisas que est�o fora do seu contexto, dizemos que ele t�m baixa coes�o, ou baixa coer�ncia. A classe Carro � incoerente, pois tenta desempenhar tanto o papel de Carro como de Radio, o que distorce o modelo de dados (atribuir responsabilidades aos objetos de forma coerente � conhecido tamb�m como o padr�o Especialista da Informa��o, um dos pilares do GRASP).

Mas porque dever�amos nos preocupar em criar 2 objetos (Carro e Radio), se podemos simplesmente deixar todos os m�todos na classe Carro (ou Carradio)?

Para isso, devemos observar a segunda lei da f�sica OO.

Segunda Lei da F�sica OO: Princ�pio Fundamental da Din�mica (F = m.a)

Figura 6: Brinquedo Lego

Essa famosa Lei de Newton nos diz que massas diferentes, submetidos a mesma for�a, ir�o produzir acelera��es diferentes. Mas o que diabos isso tem a ver com OO?

Bem, quanto maior for o objeto (em termos de responsabilidade, objetos agregados, etc), maior o custo do sistema para (re)utiliz�-lo.

Vejamos o fascinante brinquedo Lego, que consiste em criar diversas estruturas atrav�s do encaixe de blocos b�sicos. A partir de pe�as simples, coesas e bem definidas podemos construir obras divertid�ssimas, elegantes e complexas. Esse simples jogo demonstra um dos objetivos principais da OO: prover a f�cil reutiliza��o (e integra��o) de objetos para a montagem de sistemas complexos.

Quanto mais simples for o seu objeto, mais propenso a reutiliza��o ele ser�. E � assim que o mundo f�sico funciona, pois cada objeto � a composi��o de outros objetos. O corpo humano � formado de org�os, que s�o formados por c�lulas, que s�o formados por mol�culas, �tomos, etc. Essa � a natureza fractal do mundo real. A OO tamb�m possue natureza fractal, pois um objeto ou � �nico, ou � composto de outros objetos.

Figura 7: Fractal

Fazendo outra analogia: atrav�s da madeira, podemos construir mesas, cadeiras, paredes, etc. O esfor�o para converter esse objeto simples em algo mais complexo � muito menor do que converter uma cadeira em uma mesa.

Objetos complexos possuem diversas desvantagens:

dif�ceis de mudar sem quebrar a rede de objetos
dif�ceis de serem reaproveitados
elevam o tr�fego de rede, seja atrav�s de RMI, XML, JSON, etc.
dificulta a mudan�a de regras de neg�cio
etc

Podemos, ent�o, resumir essas duas leis nos seguintes axiomas:

Crie objetos com uma �nica responsabilidade (alta coes�o).
De prefer�ncia a uma rede de objetos pequenos, especialistas, do que um objeto "faz-tudo" (granularidade).
Objetos pequenos e coesos s�o mais f�ceis de serem utilizados mais vezes na rede de objetos (reutiliza��o de c�digo).

Terceira Lei da F�sica OO: A Lei da Gravita��o Universal

Figura 8: Lei da Gravita��o

Objetos com muita massa s�o inconvenientes, pois necessitam de um enorme esfor�o para serem utilizados. Quanto maior, mais energia deve ser aplicada (realmente a gravidade � implac�vel).

Objeto pesados n�o s�o apenas objetos que assumem responsabilidades demais. Eles tamb�m podem ser considerados pesados quando possuem muitos componentes "agregados".

O que seriam "componentes agregados"? Uma analogia do mundo real ajudar� a compreender esse conceito.

Voc�, como consumidor, ao comprar um carro, pode optar por trocar v�rios de seus componentes ao longo da vida �til do mesmo. Vidros, portas, pneus, motor, etc. Isso � poss�vel gra�as ao design modular do carro, onde cada componente t�m uma interface bem definida com o restante do sistema e s�o extremamente coesos. Podemos trocar a bateria do carro, optando por diversas marcas, bastando que elas sigam a especifica��o que define como ligar a bateria com o resto do sistema daquele modelo de carro. O mesmo pode ser dito de computadores, motos, casas, etc.

Agora imagine o seguinte cen�rio: ao comprar um carro, o fornecedor impossibilita altera��es nos componentes, limitando a nossa liberdade de customiza��o do mesmo. Isso com certeza seria um absurdo. T�o absurdo quanto uma imobili�ria definir os m�veis que devemos comprar na casa que adquirimos dela.

Se os consumidores ficam irritados quando compram produtos que n�o permitem altera��es, porque os programadores (que tamb�m s�o consumidores) produzem classes amarradas, limitando o uso por parte de outros programadores? Para ilustrar esse cen�rio, veja o seguinte exemplo:

Listagem 1: Classe Carro


   public class Carro {
      .... 
      public Carro() {
          this.motor = new MotorFord();
          this.portas = new ArrayList<Porta>();
          this.pneu1 = new Goodyear();
          this.pneu2 = new Goodyear();
          this.pneu3 = new Goodyear();
          this.pneu4 = new Goodyear();
          this.radio = new Pionner();
      }

      public void tocarCD(CDRom cdrom) {
          this.radio.tocarCD(cdRom);
      }

      public void buzinar() {
          this.buzina = new BuzinaTabajara();
          buzina.ativar();
      }
      ...
   }

O uso do operador new � indicador forte de um pr�ncipio claro: imposi��o. O criador dessa classe fez o mesmo papel do fornecedor mesquinho que lhe vendeu aquele carro n�o-customiz�vel, pois ao definir previamente os componentes do seu carro, retirou sua liberdade de escolha.

Em OO isso � conhecido como forte acoplamento entre objetos, e a solu��o para isso � conhecida como Princ�pio da Invers�o da Depend�ncia (outro componente do SOLID) ou Invers�o de Controle.

A partir da analogia com o consumidor, fica claro entender o papel da Invers�o de Depend�ncia: permitir a customiza��o de objetos e m�dulos. Para que isso seja poss�vel, devemos trabalhar com abstra��es e com a estrat�gia de Invers�o de Controle.

A Invers�o de Controle � conhecida tamb�m como o pr�ncipio de Hollywood ("n�o nos chame, n�s chamamos voc�"). Em OO, dir�amos que a classe Carro ir� transferir a responsabilidade de cria��o de suas depend�ncias para um cont�iner de inje��o de depend�ncia (Spring, Guice, PicoContainer), que � uma forma de se implementar Invers�o de Controle.

O exemplo do Carro t�m uma caracter�stica emblem�tica. Podemos trocar v�rios componentes do carro, n�o importa de que fornecedor ele venha, com uma �nica condi��o: que siga a especifica��o padr�o do componente para aquele tipo de carro. A palavra chave aqui � a especifica��o.

A especifica��o � um contrato entre o componente e o resto do sistema. O que se deve levar em considera��o s�o as funcionalidades que o componente prov� ao mundo exterior, e n�o como essas funcionalidades s�o implementadas. Temos 2 conceitos claros ent�o: a utilidade de um objeto e como ele implementa isso. Para ficar mais claro, usaremos um exemplo do mundo real: o garfo.

O garfo pode ser de metal, de pl�stico ou at� de madeira, mas isso n�o interfere no seu pr�posito, sua utilidade, sua atividade fim. Fica claro ent�o como a finalidade de um objeto � diferente da sua implementa��o, que pode variar.

Esse conceito de especifica��o, de contrato, dos servi�os que um objeto pode fornecer s�o implementados atrav�s de abstra��es como as interfaces, classes abstratas, polimorfismo, heran�a e at� padr�es de projeto em linguagens OO.

O Pr�ncipio de Invers�o de Depend�ncia � fundamental para a OO, pois atuando juntamente com Abstra��es e Desig Patterns, possibilita a cria��o de redes de objetos coesas e leves. Afinal, decidir a cria��o das depend�ncias (padr�o Criador do GRASP) pode ser responsabilidade demais para nossos estimados objetos.

Os axiomas dessa lei, s�o portanto:

Favore�a o desacoplamento de c�digo (baixo acoplamento), atrav�s de conceitos como Invers�o de Depend�ncia ou Invers�o de Controle.
Uso de abstra��es / padr�es para separar funcionalidade de implementa��o. (encapsulamento, heran�a, polimorfismo).
Uso de abstra��es / padr�es para separar m�dulos do sistema (um m�dulo tamb�m pode ser visto como um objeto, geralmente representando uma rede de objetos. Por ser um objeto, est� sujeito as mesmas leis da f�sica do mundo OO, ou seja, o relacionamento entre os m�dulos tamb�m deve tamb�m privilegiar coes�o, baixo acoplamento, etc. Para isso existe conceitos como OSGI, SOA, etc).

Quarta Lei da F�sica OO: Teoria do Caos

Figura 9: Efeito Borboleta

A teoria do caos diz que, qualquer mudan�a no sistema, por menor que seja, pode lev�-lo a um comportamento imprev�sivel ao longo do tempo. O exemplo cl�ssico � o chamado efeito borboleta: um simples bater de asas de uma borboleta no Texas pode gerar um tuf�o em outra parte do mundo, o que demonstra a intrincada interliga��o do mundo.

Sistemas din�micos est�o sujeitos a esse efeito, pois lidam com dezenas de v�riaveis que influenciam na complexidade. Quanto maior a quantidade de vari�veis do sistema, mais complexo ele ser�, e mais propenso a imprevisibilidade tamb�m.

O que diremos ent�o dos sistemas com milhares de linhas de c�digo, que lidam com centenas de regras de neg�cio, intera��o entre objetos a n�vel micro (classes) e macro (m�dulos, subsistemas), etc? Alguma vez o seu Windows j� apresentou um comportamento inesperado?

Afinal, regras de neg�cio e requisitos mudam constantemente, for�ando os programadores a alterar essa malha de objetos, o que tende, se for feita de forma descuidada, a gerar as consequ�ncias do efeito borboleta, ou seja, comportamento inesperado do sistema (bugs).

Nota: Em IA, comportamento inesperado �s vezes � bem vindo, principalmente de algoritmos gen�ticos, redes neurais, etc.

Numa rede de objetos, todo e qualquer objeto e seus relacionamentos s�o importantes. Uma �nica linha de c�digo incorreta num sistema com milhares de linhas de c�digo pode comprometer a imagem do mesmo. A rede de objetos � como uma corrente, cujo valor equivale ao seu elo mais fraco.

Um dos conceitos do nosso ramo cient�fico que merece destaque � o TDD (Test Driven Development � Kent Beck). O TDD, se seguido corretamente, pode garantir a qualidade do seu sistema, pois ele ataca o problema da complexidade a n�vel at�mico (classes e objetos individuais), propagando-a nos n�veis subsequentes. Uma analogia sempre � bem vinda. No exemplo do carro, voc� espera que todos os seus componentes tenham sido testados (motor, freio, cd player, buzina, inje��o eletr�nica, pneus, etc), n�o � mesmo?

Realmente, o ramo de Engenharia � muito mais maduro do que a Ci�ncias da Computa��o, pois os engenheiros conseguem entregar redes de objeto complexas (imaginem quantos transistores, resistores, diodos, etc uma CPU possue?) com uma taxa de erros �nfima. As t�cnicas OO s�o o primeiro passo que todo o desenvolvedor deve seguir se quiser construir sistemas com o m�nimo de qualidade poss�vel. A passos curtos, a Ci�ncias da Computa��o vai ser tornando cada vez mais madura, mas ainda falta muito para chegar ao n�vel das outras ci�ncias exatas.

Os axiomas dessa lei, s�o portanto:

Use o TDD para controlar a complexidade no n�vel qu�ntico (objetos), estendendo aos m�dulos da baixo n�vel para os de alto n�vel.
Use ferramentas que possibilitem todo o tipo de teste: JUnit, JMock, Selenium, JMeter, etc.

Quinta Lei da F�sica OO: Entropia

Figura 10: Entropia

A Entropia, em linhas gerais, mede o grau de "desordem" de um sistema, at� que ele caminhe para a irreversibilidade.

Em OO, o acumulo de m�s pr�ticas propicia o surgimento do chamado D�bito T�cnico. O D�bito T�cnico seria ent�o, um indicador do custo de se alterar um sistema. Quanto maior for, mais esfor�o � necess�rio para se alterar uma regra sem gerar comportamento imprev�sivel (bugs).

Para lidar com a crescente complexidade, e a mant�-la administr�vel, n�o basta apenas seguir as quatro leis anteriores. Elas ajudam e muito a manter o sistema coeso e prev�sivel, mas elas s�o leis estruturais, que definem conceitos como responsabilidade, cria��o, depend�ncia, granularidade, coes�o, ou seja, a parte arquiteturial da rede de objetos. E quanto ao lado din�mico da rede?

Como gerenciar ent�o as mudan�as de regras, a intrincada rede, cuidar tanto a n�vel qu�ntico como macro da rela��o entre objetos? Para isso, um grupo de f�sicos do mundo OO (Kent Beck, Martin Fowler, Craig Larman, Eric Gamma, Eric Evans, Uncle Bob, Scott Ambler, etc) criou t�cnicas como TDD, Refactoring, DDD, DRY, Convention Over Configuration, Integra��o Continua, etc (na verdade, muitos dessas t�cnicas s�o conhecidas desde os prim�rdios da programa��o Modular, mas que foram difundidas por esses cientistas da computa��o).

N�o se preocupe agora com essas siglas. Tenha em mente que o objetivo principal delas � atacar a complexidade do sistema, garantindo a qualidade do mesmo em todos os n�veis qu�nticos e relativistas, minimizando a imprevisibilidade.

Os axiomas dessa lei, s�o portanto:

Controlar a complexidade do sistema atrav�s de t�cnicas consagradas como Integra��o Continua, TDD, Refactoring, Invers�o de Controle, DDD, etc
Abordagem at�mica: todas as pe�as da engrenagem devem estar funcionando corretamente. Utilize TDD para garantir a qualidade a n�vel qu�ntico.
Sistemas de computador s�o sistemas din�micos e devem ser tratados com seridade.

Conclus�o

Espero que esse artigo possa contribuir para o entendimento das importantes Leis OO que regem o mundo dos objetos virtuais. Afinal, se os engenheiro conseguem entregar redes de objeto gigantescas com alta qualidade, n�s, cientistas da computa��o, n�o podemos ficar para tr�s. O foco � a qualidade.

Abra�os e at� a pr�xima!

Nota: Para mergulhar nessas "leis da f�sica", sugiro a leitura dos livros indicados em Refer�ncias.

Refer�ncia:

Leitura Recomendada:

UML e Padr�es � Craig Larman
Programador Pragm�tico - David Thomas Roberts; Whiteford, Andrew Hunter
Clean Code � Robert C. Martin
Agile Software Development, Principles, Patterns e Practices � Robert C. Martin
Refactoring � Martin Fowler
Design Patterns � Gang Of Four
Effective Java � Joshua Bloch
Padr�es Arquiteturiais de Aplica��es Corporativas � Martin Fowler
Test Driven Development � Kent Beck
Domain Driver Design � Eric Evans

Tecnologias:

Confira outros conte�dos:

Teste de Acessibilidade de Software

Boas Pr�ticas em TDD

Principais Anomalias Arquiteturais de...

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Marcelo Em 2012

Coment�rios nesta publica��o Escrever um coment�rio sobre conte�do

Erick Amaral

N�vel 0

Parab�ns, muito bom o artigo

há +1 ano

Marcelo Senaga

N�vel 0

Obrigado!

há +1 ano

Erick Amaral

N�vel 0

Parab�ns, muito bom o artigo

há +1 ano

John Leno

N�vel

Show de bola, parab�ns!

há +1 ano

Marcelo Senaga

N�vel 0

Obrigado!

há +1 ano

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso

As Leis do Mundo dos Objetos - Melhores Pr�ticas em Orienta��o a Objetos

Veja nesse artigo algumas das melhores pr�ticas em Orienta��o a Objetos, vistas de forma did�tica a partir de exemplos divertidos e concretos.

Introdu��o

As Leis da F�sica do Mundo dos Objetos

Primeira Lei da F�sica OO: Dois corpos n�o ocupam o mesmo lugar no espa�o

Segunda Lei da F�sica OO: Princ�pio Fundamental da Din�mica (F = m.a)

Terceira Lei da F�sica OO: A Lei da Gravita��o Universal

Quarta Lei da F�sica OO: Teoria do Caos

Quinta Lei da F�sica OO: Entropia

Conclus�o

Refer�ncia:

Leitura Recomendada:

Confira outros conte�dos:

Teste de Acessibilidade de Software

Boas Pr�ticas em TDD

Principais Anomalias Arquiteturais de...

Perguntas frequentes

Nossos casos de sucesso