1 / 69

Programação Orientada a Objetos

Programação Orientada a Objetos. Projeto de Classes. Agenda. Projeto baseado na responsabilidade Acoplamento Explícito Implícito Coesão Classes Métodos Refatoração. Projeto. O que torna um projeto bom ou ruim ? Bons projetos Exigem mais esforços à curto prazo .

margo
Download Presentation

Programação Orientada a Objetos

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ProgramaçãoOrientada a Objetos Projeto de Classes

  2. Agenda • Projetobaseadonaresponsabilidade • Acoplamento • Explícito • Implícito • Coesão • Classes • Métodos • Refatoração

  3. Projeto • O quetorna um projetobomouruim? • Bonsprojetos • Exigemmaisesforços à curtoprazo. • A longoprazo, osesforçossãojustificados. • Implementaçãopoderealizarsuastarefas com classes mal projetadas. • O fato de executarumaaplicaçãonãoindica se elaestabemestruturadaounão.

  4. Princípios • Princípiosquedevem ser seguidos: • Projetobaseadonaresponsabilidade. • Encapsulamento. • Fraco acoplamento. • Alta coesão.

  5. Problemas • Surgememgeralquando: • Programador de manutençãotentafazeralgumasalterações • Corrigirumafalha. • Adicionar nova funcionalidade. • Classes bemprojetadas: • Tarefafácil e óbvia. • Classes mal projetadas: • Tarefamuitodifícil e envolvemuitotrabalho.

  6. Problemas • Grandesaplicações • Taisproblemasocorremdurante a implementação original. • Se o projetocomeça com umaestruturaçãoruim, terminá-lo pode ser muitocomplexo • Programanãopode ser terminado. • Podeconterfalhas. • Demorarmuitomais do quenecessáriopara ser construído.

  7. Adaptar e estenderumaaplicação • Muitos dos efeitos de um projetoruim se tornamevidentesquando se tenta: • Adaptar. • Estender.

  8. World-of-Zuul

  9. World-of-Zuul • Classes bemdocumentadas • Ilustraqueprojetoruimenvolvealgomaisprofundoquesimplesmente a aparênciadaclasseouquanto é boa suadocumentação.

  10. Introdução a Acoplamento • Qualidade de um projeto de classe: • Acoplamento (coupling) • Refere-se a interconectabilidadedaclasse. • Objetoscooperam via interfaces bemdefinidas. • O grau de acoplamentoindica a firmezaqueessas classes estãoconectadas. • Um bomprojeto de classe visa: • Baixograu de acoplamento • Acoplamentofraco • O grau de acoplamentoindicacomo é difícilfazeralterações

  11. Classes fortementeacopladas • Umaalteraçãoemumaclassepodetornarnecessárioalterarváriasoutras classes • Deve-se evitarisso, pois o efeito de fazerumaalteraçãopequenapodefacilmente se propagarportoda a aplicação • Além disso, localizartodososlugaresonde as alteraçõesdevem ser feitas e realmentefazer as alteraçõespode ser difícil e demorados

  12. Classes fracamenteacopladas • Pode-se alterarumaclassesemfazernenhumaalteraçãoemoutras classes.

  13. Introdução a Coesão (cohesion) • Número e diversidade de tarefaspelasquaisumaunidade de umaaplicação é responsável • Classes. • Métodos. • Ideal • Umaunidade de códigodeve ser responsávelporumaunidadecoesa (umatarefaquepode ser vista com umaentidadelógica) • Um métododeveimplementarumaoperaçãológica • Umaclassedeverepresentar um tipo de entidade

  14. Reutilização • Coesão visa reutilização • Se um métodoouumaclasse é responsávelporapenasumacoisabemdefinida • Bemmaisprovávelqueelepossa ser utilizadonovamenteem um contextodiferente.

  15. Vantagemcomplementar de Coesão • Quandoalgumaalteração é necessária, é provávelqueencontre-se todas as partesrelevanteslocalizadasnamesmaunidade

  16. Duplicação de Código • Forte indicador de projetoruim • Problemas: • Qualqueralteraçãoemuma parte deve ser feitanaoutra, casocontrário, a aplicaçãoficainconsistente. • Aumenta o trabalhoque um programador de manutenção tem de fazer e introduzperigo de bugs. • O programadorpodenãoacharcópia do código, nãoalterá-la e assumirque o trabalhoestaconcluído. • Nãohá nada queindiquequeumasegundacópia do códigoexiste • Sintoma de mácoesão

  17. Exemplo de duplicação de código • MétodosprintWelcome() e goRoom()daclasseGame System.out.println("You are " + currentRoom.getDescription()); System.out.print("Exits: "); if(currentRoom.northExit != null) System.out.print("north "); if(currentRoom.eastExit != null) System.out.print("east "); if(currentRoom.southExit != null) System.out.print("south "); if(currentRoom.westExit != null) System.out.print("west "); System.out.println();

  18. Raízes do Erro • Os doismétodosemquestãofazemduascoisas: • printWelcome() imprime a mensagem de boas vindas e imprime as informaçõessobre a localizaçãoatual • goRoom() altera a localizaçãoatual , e imprime as informaçõessobre a localizaçãoatual • Os doismétodosimprimem as informaçõesatuais de localização, masnenhum deles podechamar o outro, porqueelestambémfazemoutrascoisas. Isso é um projetoruim.

  19. Solução do Erro • Um projetomaisaprimoradoutilizaria um métodomaiscoesoseparandoem um únicatarefa a impressão das informaçõesatuais de localização. • Os doismétodospodemfazerchamadas a esse novo métodoquandoprecisaremimprimiressasinformações. • Dessamaneira, não e necessárioescrever o códigoduasvezes, e quandoumaalteração for necessária , seráprecisoumaúnicamodificação.

  20. FazendoExtensões • Tarefa • Adicionaruma nova direção de movimento. • Atualmente: norte, leste, sul e oeste. • Deve-se permitir: paracima e parabaixo.

  21. Localizandocódigorelevante • Duas classes: Room e Game • Room é a classequearmazena a saída de cadasala. • Gameutiliza as informações de saídadasalaatualparaimprimir as informaçõessobresaídas e para se mover de umasalaparaoutra.

  22. ClasseRoom • Adicionardoisnovoscampos • AlterarmetodossetExits(…)

  23. ClasseGame • Maistrabalhosolocalizar as modificações • Localizartodososlugaresexigepaciência e cuidado • Métodosquedevem ser alterados: • createRoom() • printWelcome() • goRoom() • Umapossivelsoluçãoseriaadicionar as novas direçõesemtodosessesmétodos • É a melhorsolução???????????

  24. Acoplamento • O fato de havermuitoslugaresondetodas as saídassãoenumeradas e sintomático de projetoruim. • Aodeclararvariáveis de saídanaclasseRoom • setExits()há um if porsaída • goRoom()há um if porsaída • printLocationInfo()há um if porsaída • Essadecisão de projetocriatrabalho: localizartodosesseslugares e adicionardoisnovoscasos • E se um novo requisito fosse adicionar as direçõescomonoroeste, sudeste????

  25. Soluçãomaisadequada • UsarHashMap<String, Room> paraarmazenar as saídas • Obriga-se a escrevercódigoquepodeoperar com qualquernúmero de saídas • Nãoobriga a tantaalterações no futuro • Essa e umaalteraçãonamaneiracomo a salaarmazenasuasinformações. Teoricamenteessaalteraçaodeveafetarsomente a classeRoom (como as informações de saídasãoarmazenadas), não a interface (o que a salaarmazena)

  26. Soluçãomaisadequada • De maneira ideal , quandoapenas a implementaçãomuda , outras classes nãodeviam ser afetadas. Issoseria um caso de acoplamentofraco. • Emnossoexemplo, issonãofunciona. Se as saídas de Roomforemsubstituídaspor um HashMap, a classeGamenãocompilarámais. • Sintoma de acoplamento forte.

  27. Encapsulamentoparareduziracoplamento • Problema principal: • Uso de campospúblicos • Aotornarpúblicas as saídas, a classeRoomexpôsemsua interface nãoapenas o fato de que tem saídas, masexatamentecomotaisinformaçõessãoarmazenadas. Issoquebra um dos princípiosfundamentais do bomprojeto, o encapsulamento.

  28. Encapsulamento • Diretriz • Ocultarinformações de implementaçãodavisualização • O queumaclassepodefazerdeve ser visível • Como a classe é, não. • Vantagem • Se nenhumaoutraclassesabecomo as informaçõessãoarmazenadas, pode-se facilmentealterarcomoelassãoarmazenadasemquebraroutras classes

  29. ClasseRoomModificada • Impôrseparação entre o que e como • Tornandooscamposprivados • Método de acessoparaobtê-los • A classeGamedeverá ser alteradatambém. Reduzindodrasticamente o código.

  30. ClasseRoomModificada • Até agora nãoalteramos a representação de saída. Somente a interface foilimpa. • A alteraçãoemGame e mínima. Aoinvés de acesso a campospúblicos, o uso de métodos , mas o ganho é significativo. • Agora pode ser alterar, como as saídassãoarmazenadasnaclasseRoomsem se preocupar com a quebra de qualqueroutraclasse. • A representaçãointernaemRoomfoicompletamenteseparadada interface.

  31. ClasseRoomAlterada • Agora que o projetoestácomodeviaestar, a troca dos camposseparadospor um HashMap é fácil. • Vale enfatizarquepode-se fazer a alteraçãosemmesmoverificar se qualquercoisaquebraráemoutra parte. PoisforamalteradosapenasaspectosprivadosdaclasseRoom. A interface permaneceinalterada. • Vantagensdaalteração: • ClasseRoommaiscurta. • MétodogetExit()foireduzidoaoextremo.

  32. ClasseRoomAlterada • Objetivo: inserirduas novas saídas. • MetodosetExitsaindaprecisa de aperfeiçoamento • Interface daClasseRoom • Alteraçõesafetamoutras classes • Não é possívelsepararcompletamente as classes, casocontrárioobjetos de classediferentesnãoseriamcapazes de interagir entre si. • Aoinvés disso, manter o grau de acoplamento o maisbaixopossivel.

  33. MétodosetExit() • public void setExit(String direction, Room neighbor) • Agora, as saídasdasalapodem ser configuradasumasaídaporvez e qualquerdireçãopode ser utilizadaparaumasaída. • Remove-se assimcompletamente a restrição de Room. A classeRoompodearmazenar as direçõesparacima e parabaixo, bemcomoqualqueroutradireçãoquepossaimaginar.

  34. Projetobaseadonaresponsabilidade • Uso de encapsulamentoadequadoreduz o acoplamento e podereduzirsignificativamente a quantidade de trabalhonecessárioparafazeralteraçõesemaplicações. • Poremessenão é o únicofatorqueinfluencia o grau de acoplamento. Outroaspecto é conhecidopelotermoprojetobaseadonaresponsabilidade.

  35. Projetobaseadonaresponsabilidade • Idéia • Cadaclassedeve ser responsávelportratarseuspróprios dados • Adição de novas funcionalidades • Qualclassedevemosadicionar um métodoparaimplementaressa nova função? • Qualclassedeve ser responsávelpelatarefa? • A resposta é: a classeque é responsávelporalguns dados tambémdeve ser responsávelpormanipulá-los.

  36. Responsabilidade e Acoplamento • Versão original do printLocation() com o métodogetExitString() • As informaçõessobresaédaestãoarmazenadassomentenaprópriasala, e a salaque é responsávelporforneceressasinformações. • A salapodefazerissomuitomelhor do quequalqueroutroobjeto, desdequetenhatodo o conhecimentosobre a estrutura de armazenamentointerno dos dados.

  37. Responsabilidade e Acoplamento • Objetivo • Reduziracoplamento • System.out.println(“You are ” + currentRoom.getDescription()); • System.out.println(currentRoom.getExitString()); • Implementaçãoaindapode ser melhorada • Se adicionarmositens as salas? • Oumonstros? • Ououtrosjogadores? • Tal descriçãodeveestarcontidanasala. • Porém se taisalteracoesfossemnecessárias, a classeGamedeve ser alterada (acoplamento)

  38. Responsabilidade e Acoplamento • Nova brechapara o projetobaseadoemresponsabilidade • Roommanteminformaçõessobre a sala • Elatambemdeveproduzirumadescriçãopara a sala public String getLongDescription() { return "You are " + description + ".\n" + getExitString(); } • Na classeGame System.out.println(currentRoom.getLongDescription());

  39. Minimizando as alterações • Outroaspectodaseparação e de princípios de responsabilidade • Procura-se criar um projetoquefacilitealteraçõesposteriores • Idealmenteapenasumaúnicaclasseprecisa ser alteradaparafazerumamodificação • Ocasionalmente, várias classes precisam de alteração, masobjetivamente com o mínimopossível de classes. • Além do mais, as alteraçõesnecessáriasemoutras classes devem ser óbvias, fáceis de detectar e fáceis de executar

  40. Minimizando as alterações • Alcança-se regras de bonsprojetosutilizando: • Projetobaseadonaresponsabilidade • Fracoacoplamento • Alta coesão • Teremmente: • Modificação e extensão • Importanteanteciparque um aspecto do programapodesofreralteração, a fim de facilitaressaalteração.

  41. AcoplamentoImplícito • Campos públicos • Praticaquetalvezcrie forte acoplamento • Necessárioalteraçãoemmais de umaclassepara o quedevia ser uma simples modificação • Campos públicosdevem ser evitados • Porém, háformaspiores de acoplamento • Acoplamentoimplícito • Umaclassedepende de informaçõesinternasdaoutra • Dependêncianãoóbvia • AcoplamentoExplícito • Não é bom • Porém é óbvio (aplicaçãonãocompila)

  42. AcoplamentoImplícito • Novo requisito • Adicionar nova palavra de comandoaojogo • look (imprimir a descriçãodasala e sairnovamente) • Solução • Introduziruma nova palavra de comando, no array validCommandsnaclasseCommandWords • Boa coesão • Aoinvés de definirmos o comando no Parser • Facilitaencontrarondeoscomandosestãodefinidos e acrescentaroutros • O autorestapensandonafrente, assumindoqueoutroscomandospodem ser definidos, e criouumaestruturaquetornaissofácil

  43. AcoplamentoImplícito • Apósfazer a alteração, issonãofunciona. • Aodigitar look nada acontece. • Palavra é reconhecida • Porémnãoháaçãovinculada a ela • Issopode ser corrigidoadicionando o método look naclasseGame. E adicionadomais um if no métodoprocessCommand. • O acoplamento entre as classes Game, Parser, e CommandWordparaser boa • Fácilfazer a extensão

  44. AcoplamentoImplícito • Emitircomando help • Nota-se um pequenoproblema • O novo comandonãoe listado • Fácilde corrigir • Editarstring do métodoprintHelp de Game • Feitorapidamente e nãoparece um grandeproblema • E se talerronãotivessesidonotado? • Vocêpensounesseerro antes de leraqui? • Problema fundamental • Novo comando • Ajudaprecisa ser atualiza • Fácilde esquecertalalteração • O programacompila e executa • O programador de manutençãopodemuitobemacreditarque o trabalhoestaterminado e liberar um programaque agora contemumafalha

  45. AcoplamentoImplícito • Comandosalterados • Texto de ajudadeve ser modificado (acoplamento) • Mas nada no fonte do programaindicaclaramenteessadependência(implícito) • Classebemprojetada • Evitaacoplamentoimplícito • Seguindo a regra do projetobaseadonaresponsabilidade

  46. AcoplamentoImplícito • ClasseCommandWord • Responsávelpelaspalavras de comando • Deve ser responsávelpelasimpressãodas palavras de comando • AdicionarmetodoshowAll() • ClasseGame • printHelp() • Aoinvésde imprimirtextofixo • Invoca um método de um objetoCommandWordparaimprimirtodas as palavras de comando

  47. AcoplamentoImplícito • Gamenãotem referênciaa um objetoCommandWords • Podeser adicionado • Diagrama de classerefletiriaisso (Gameteriarelaçãocom CommandWords) • Setas no diagrama de classesãoumaprimeira boa indicaçãodo quanto um programaé fortementeacoplado. • Maissetas, maisacoplamento • Bonsprojetos • Diagramas com poucassetas

  48. AcoplamentoImplícito • Gamenãoterreferênciaa CommandWordsé uma boa coisa • Issonãodeve ser alterado • Ponto de vista de Game • CommandWordsé detalhe de implementaçãodo Parser • Parser • Retornacomandos • Decisãode usar um CommandWordsparaissoououtracoisaé detalhe de implementação

  49. AcoplamentoImplícito • ProjetoAprimorado • AdicionaremGame • parser.showCommands() • showCommands()emParse • DelegaresponsabilidadeaoobjetoCommandWords

  50. Pensando a frente • Projetoatualé bemmelhorque o original • Contudoé possívelaperfeiçoa-lo aindamais • Característicade um bomprojetista • Capacidade de pensar a frente • O quepode ser mudado? • O quepermanecerainalteradodurantetoda a vida do programa?

More Related