Oi gente, hoje teremos uma aula bem importante, onde vamos falar sobre padrões de projetos de software orientado a objetos. Vocês já conhecem todos os conceitos básicos de orientação a objetos, então chegou a hora de ver algo pouco mais sofisticado, pouco mais complexo e que é absolutamente fundamental para quem quer ser excelente desenvolvedor de software. Então, o excelente desenvolvedor de software precisa conhecer obrigatoriamente padrões de projetos de software, e é isso que a gente vai ver agora. Então, a ideia dos padrões de projeto de software orientados a objetos é incluir dentro deles conhecimentos sobre especialistas desenvolvimentos e arquitetura orientada a objetos e transmitir isso para outras pessoas como nós por exemplo. Nós pobres mortais. O termo inglês para padrões de projetos é Design Patterns. Então inglês seria Object Oriented Software Design Patterns. Falamos de Design Patterns, de Patterns. Português alguns traduzem para Padrões de Desenho de Software orientado a objetos ou falam simplesmente padrões. Mas eu diria que o termo mais correto, e hoje dia é o mais conhecido é padrões de projeto. Então, quando a gente estiver falando padrões de projeto, a gente está querendo se referir aos Design Patterns, tá? Qual que é a ideia aqui? A ideia surgiu quando alguns cientistas da computação tiveram contato com trabalho de arquiteto, mas arquiteto de prédios que constrói prédios, urbanista que desenhava cidades ele era chamado de Christopher Alexander. Que ele trabalhava na Universidade da Califórnia, era professor de arquitetura e 1997 no contexto de arquitetura ele criou essa ideia de patterns, de padrões só que naquela época os padrões deles eram para construir projetos prédios, projetos de cidades. E ele descreveu o padrão, ele definiu o que é padrão dessa forma assim: "Cada padrão descreve problema que ocorre repetidamente de novo e de novo nosso ambiente, então descreve a parte central da solução para aquele problema, de uma forma que você pode usar essa solução milhão de vezes sem nunca implementá-la duas vezes da mesma forma." E o pessoal de software olhou para isso e falou: "Nossa quando eu estou programando, desenvolvendo software orientado a objetos também acontece isso." Tem alguns problemas que acontecem vários sistemas diferentes, vários contextos diferentes, mas a solução geral é comum termos de orientação a objetos. Então eles decidiram que tal a gente colocar essa solução para problemas recorrentes na forma de padrões de software orientado a objetos. O Christopher Alexander naquela época ele escreveu livros que vocês podem até consultar hoje dia na biblioteca das faculdades de arquiteturas normalmente têm esses livros, por exemplo The Timeless Way of Building que fala sobre como a humanidade ao longo dos milênios seguia alguns padrões para construir prédios e salas. Eu lembro por exemplo eu tenho padrão sala de espera. Ele falava que numa sala de espera é interessante você ter uma cadeira, mas é interessante ter uma janela também para você ficar olhando uma paisagem então, com a solução faça uma sala de espera com uma janela coloque uma cadeira voltada para a janela de forma que a pessoa possa se se sentar confortavelmente e olhar pela janela. Então, padrões desse tipo de arquitetura mas que o pessoal de computação se inspirou para para software, né? Outros livros, tem o livro A Pattern Languade Towns, Buildings, and Construction, que daí tem conjunto de Padrões. Então uma Pattern Language, uma linguagem de padrões, é conjunto de padrões para resolver problemas relacionados. Então, nesse caso ele fala sobre padrões sobre construção de cidades e de prédios e de métodos construtivos geral. Mas chega de falar de arquitetura de prédios, vamos voltar para a arquitetura de software. Então os padrões de projeto de software ajudam ajudam a gente a definir a arquitetura de software. E eles funcionam como catálogo de soluções. Porque cada padrão encerra dentro de si o conhecimento de uma pessoa muito experiente determinado assunto geral, orientação a objetos no nosso caso aqui, de uma forma que esse conhecimento pode ser transmitido para outras pessoas menos experientes. Então, se a gente ler esses padrões a gente aprende boas soluções de arquitetura orientada a objetos e pode começar a implementar software de boa qualidade porque a gente aprende com os mais experientes. Outras ciências já tem isso. Então, por exemplo química tem catálogos de como produzir substâncias químicas a partir de reações químicas. Então, químicos têm catálogos alí de centenas as vezes milhares de páginas as vezes explicando como construir como sintetizar substancias químicas. As engenharias, a engenharia civil por exemplo, tem catálogos de como construir pontes dizendo vários tipos de pontes, quais são as metodologias que você deve seguir para construir uma ponte e assim por diante. E a ciencia da computação não tinha catálogos até então. E agora, desde 1995 a área de desenvolvimento de software passou a ter o seu primeiro catálogo de soluções para projeto de software que foi o primeiro livro de padrões. Depois vários outros livros apareceram, mas esse primeiro livro que apareceu 1995 é este aqui. É o Design Patterns Elements of Reusable Object-Oriented Software. Que foi criado por esses quatro pesquisadoes o Erich Gamma que trabalhava na IBM, o Richard Helm que era consultor de desenvolvimento de software lá na Austrália. O Ralph Johnson que é professor na Universidade de Illinois Urbana–Champaign e o John Vlissides que trabalhava na IBM. Eu falei que o o Erich Gamma ele trabalhou pouco na IBM mas na verdade, na época desse livro ele estava fazendo a tese de doutorado dele. Então a tese de doutorado dele foi sobre padrões Depois o Erich Gamma ficou bem famoso porque ele se tornou o arquiteto chefe do projeto Eclipse. Então, durante muitos e muitos anos o Erich Gama que definia e liderava a implementação do software Eclipse. Mas lá 1995 eles fizeram esse livro, por serem quatro eles acabaram apelidados como a Gangue dos Quatro, The Gang of Four. Então, computação se você ouvir falar do livro Gang of Four, ou simplesmente GoF, você já sabe que é esse livro de Design Patterns que é dos livros mais vendidos da história da computação. Já vendeu quase milhão de cópias que é aí número bem grande para livro técnico de computação. E o que que esse livro apresenta? Com ele a gente passou a ter vocabulário comum para conversar sobre projetos de software, porque ele é catálogo de vários padrões de software orientado a objetos. Então, soluções que os progamadores já faziam e não tinha o nome agora passam a ter nome. Cada padrão tem o seu nome e quando eu falo para algum programador experiente agora eu vou usar o Observer, é uma única palavra, Observer ele já sabe exatamente que é certo conjunto de classes com algum relacionamento, com alguma característica na cabeça de desenvolvedor de software experiente, a palavra Observer já tem todo significado que é explicado através de várias páginas alí desse livro o Gang of Four. Então, vez de discutirmos sistema sobre conceitos de baixo nível tipos filas, pilhas, árvores interligadas a gente passa a falar de coisas muito mais alto nível como fábricas, fachadas, observador, estratégia. Cada palavra dessa é nome de padrão, e ele inclui três ou quatro ou cinco classes diferentes e as relações entre as classes. Então, cada padrão são algumas centenas de linhas de código que ao falar uma única palavra eu já estou transmitindo todo esse conhecimento incluído nessas centenas de linhas de código. Então, o nosso vocabulário para conversar fica muito mais rico. A maioria dos autores desses livro eram entusiastas da linguagem Smalltalk, principalmente o Ralph Johnson. Então, eles usaram muito o Smalltalk como exemplos no livro mas na época a grande linguagem orientada a objetos mais popular era C++ então eles decidiram que eles iam também ter exemplos C++ para que tivesse impacto maior alí junto a comunidade de computação. E o pacto na verdade foi enorme, o livro rapidamente vendeu centenas de milhares de cópias. Hoje dia chegou a quase milhão de cópias vendidas e os exemplos do livro são C++ Smalltalk mas se você procurar na web você vai achar exemplos qualquer linguagem de programação. Aqui nesse curso a gente vai usar exemplos Java basicamente. Como funciona esse livro? Esse livro então tem esses 23 padrões e cada dos padrões segue formato bem rígido de descrição. Sempre padrão ele tem nome que geral é uma ou dua spalavras só daí ele tem uma parte que descreve qual é o problema que aquele padrão aborda, qual é o problema que ele tenta resolver, daí qual é a solução que ele apresenta para resolver aquele problema e daí quais são as consequências ou as forças envolvidas quando a gente usa aquele padrão. Porque ao aplicar padrão você melhora algumas coisas do seu software por outro lado você piora outras. Sempre tem essa relação de você ganha de lado e perde do outro e o texto do padrão descreve que você ganha e o que você perde. Existem outros tipos de padrões que a gente vai ver mais mais pra frente, mas nessa parte do curso a gente vai se concentrar nos padrões, no design patterns do livro GoF. Esse livro tem formato bem específico. Então como que é o formato dos padrões no livro do GoF? Tem o nome como eu falei, normalmente uma única palavra e depois entre parênteses o número da página onde aquele padrão aparece no livro. Porque os padrões se refere a outro, fazem referência a outro porque eles trabalham muito bem conjunto. Então a medida que você vai lendo, toda vez que aparece ele se refere a outro padrão, ele fala o nome do padrão e o número da página de forma que você possa rapidamente pular para aquele outro padrão. Nas versões web do livro, geral é link que você clica no link ele já vai para aquele outro padrão. Depois tem uma descrição bem sucinta geral, uma única frase que é o objetivo do padrão, a intenção do padrão. Depois se o patrão tem apelido, porque as vezes o padrão tem dois nomes, vem ali escrito qual que é o outro nome do padrão. Daí tem uma motivação. Uma motivacão é gerar uma historinha que tem meia página, uma página, explicando algum contexto onde aquele padrão é útil. Dando exemplo para motivar a importância do padrão cenário. Depois ele fala sobre a aplicabilidade. Quando que vale a pena aplicar aquele padrão e quando que não vale a pena. Depois tem uma definição da estrutura do padrão. Essa estrutura na época que o livro foi lançado ainda não tinha o padrão UML, então se usava esse outro padrão, OMT e às vezes diagrama de interação num padrão chamado Booch. Hoje me dia a gente só usa diagramas UML, então nesse curso eu só vou mostrar os diagramas UML. Então a estrutura vai ser diagrama UML, normalmente diagrama de classes mostrando quais são as classes que fazem parte do padrão e as inter-relações entre elas. Os participantes são as classes si, os objetos que fazem parte do padrão, as colaborações, como essas classes colaboram entre si e depois as consequências. Discute as consequências de eu aplicar aquele padrão. Tem vantagens, desvantagens e relações de custo-benefício, os trade-offs que a gente tem. Depois fala sobre implementações específicas do padrão diferentes linguagens de programação. Vem exemplos de código do livro C++, Smalltalk, mas aqui a gente vai falar de Java. No livro GoF tem sempre esses usos conhecidos. Sistemas reais de domínios diferentes e diferentes áreas onde o padrão é utilizado. Particular, o Ralph Johnson fala padrão só é padrão se você encontra três sistemas de diferentes áreas que usam o mesmo tipo de solução. Se a mesma solução é usada três contextos diferentes, aí sim você pode dizer que é padrão. E daí finalmente padrões relacionados, padrões que podem ser usados conjunto como este, ou padrões que são alternativas a este. Então esses aí são os formatos dos padrões do livro GoF. Além disso, tem três tipos diferentes de padrão nesse livro que a gente vai ver exemplo de todos eles. Padrões de criação que falam sobre formas de criar novos objetos de uma forma mais flexível, mais poderosa do que simplesmente usando o comando New diretamente da linguagem Java, por exemplo. Como estruturar melhor a criação de objetos. Depois tem os padrões estruturais, que é como organizar estruturas complexas, estruturas de dados formadas por várias classes no nosso software, de forma que nosso software seja mais flexível. E finalmente padrões comportamentais, que falam sobre o comportamento, a dinâmica de sistema também para tornar o sistema mais flexível, mais robusto. Então a gente vai ver exemplos dessas três coisas, mas na aula de hoje já para começar com exemplo vamos ver padrão estratégia. Inglês é o padrão strategy, que é definido na página 315 do livro. Ele é padrão comportamental. E eu gosto de começar com ele porque é o meu padrão preferido. Então padrão estratégia, definida na página 315. Qual é o objetivo dele? É definir uma família de algoritmos e encapsular cada desses algoritmos uma classe de forma a torná-los intercambiáveis, de forma que a gente possa plugar algoritmo ou outro diferentes momentos. Esse padrão estratégia permite que o algoritmo varie independentemente dos clientes que estão usando aquele algoritmo. Eu diria que é uma forma de a gente extrair da classe algo que pode mudar. Particular você tem uma classe que faz alguma coisa e lá dentro tem algoritmo que ela usa, usando esse padrão estratégia a gente extrai para fora da classe esse algoritmo de forma que a gente possa plugar diferentes algoritmos diferentes momentos para que a classe se comporte de uma forma diferente. E tudo isso de uma forma bem organizada, com uma boa arquitetura. Tem muitos usos conhecidos, esse padrão é muito utilizado na indústria hoje dia. Por exemplo, verificação ortográfica multilíngue. Provavelmente no editor de textos que você usa você pode fazer a verificação ortográfica português, inglês, alemão, francês. E o algoritmo de fazer a verificação ortográfica é diferente para cada linguagem, para cada língua, para português, para inglês. E as vezes a gente quer fazer a verificação português, as vezes inglês. Então é comum o editor de texto ter uma estratégia que é a estratégia de verificação ortográfica e você pode plugar diferentes estratégias, diferentes momentos, até enquanto o programa tá rodando, o editor está rodando, você pode chavear de uma língua para outra. Mesma coisa com separação silábica. As regras de separação silábica no português e no inglês são diferentes. Você tem algoritmo lá que define onde separar as sílabas. Também você pode ter isso encapsulado numa estratégia e plugar diferentes estratégias. Tem editores, tipo EMacs que fazem o highlight, eles pintam documentos de acordo com o tipo de documento. Então o documento ponto Java vai ser pintado colorido de acordo com as palavras chaves e a sintaxe da linguagem Java. Documento LaTeX vai ser pintado de acordo com as regras da linguagem LaTeX. HTML com as regras do HTML. Então você tem diferentes algoritmos para pintar e diferentes momentos de acordo com o arquivo que você carregou você quer plugar algoritmo diferente. Então você pode usar o padrão estratégia para isso. Tem vários outros usos. Por exemplo, plugar diferentes algoritmos de ordenação de acordo com o tipo de dados, vale mais a pena usar algoritmo de ordenação ou outro. Então você pode plugar diferentes algoritmos de ordenação. Finalmente conectores a banco de dados. Se você quer gravar os dados que forma persistente no banco de dados, você pode querer uma hora plugar num banco de dados PostgreSQL, na outra hora num banco de dados Oracle, num banco de dados da Microsoft, e os comandos para persistir os dados diferentes bancos de dados são diferentes, então você pode plugar diferentes estratégias para tornar os seus dados persistentes. Pode ser que você não queira usar banco de dados, você só quer gravar num arquivo texto, por exemplo, os dados você pode plugar algoritmo diferente para fazer isso. Então o padrão strategy é muito usado para isso. Vamos ver agora qual que é a estrutura básica. Então estrutura básica é isso, você tem contexto onde o contexto é o seu programa. Pode ser editor de textos, pode ser videogame, é o seu programa. E o seu programa, ele precisa executar algoritmo e esse algoritmo nesse padrão a gente chama de strategy. Uma estratégia para fazer alguma coisa. Então o videogame pode ter diferentes modos de jogo, pode ser diferentes estratégias de jogo. Então vez de na própria classe principal do videogame a gente ter a estratégia, a gente delega isso aqui para uma outra classe que a gente chama de estratégia e essa aqui é uma classe abstrata, por isso que está itálico aqui e daí você vai ter subclasses que são diferentes estratégias concretas que implementam essa classe abstrata de diferentes formas. E daí tempo de execução você escolhe qual estratégia concreta que você vai querer usar. Vamos ver outro exemplo aqui que eu montei. Vamos supor que você tem editor de figuras esse que você desenha figuras geométricas e faz desenhos, por exemplo, e daí algum momento você quer salvar, gravar no disco essa figura que você fez. Você podia ter o código que grava no disco na própria classe principal de editor de figuras. Mas o editor de figuras é uma coisa complexa, você se fizer tudo e colocar nessa classe principal você ia acabar com centenas de métodos, numa única classe e isso seria uma coisa muito ruim. Então é legal você pegar diferentes aspectos do editor de figuras e extrair para uma classe separada. Então o ato de você salvar, de gravar a figura no disco, é algo que você pode extrair. Então a gente delegaria vez de o editor de figuras ele mesmo gravar ele teria apontador chamado Salvador, seria quem salvaria no disco e ele delegaria esse ato de salvar para uma outra classe chamada Salvadordefigura. Aqui eu representei, coloquei itálico Salvador de figura que itálico no UML representa que é uma classe abstrata. Java você poderia usar uma interface também. Tanto interface como uma classe abstrata funcionaria bem aqui na linguagem Java. E ele teria único método chamado Salve que recebe como parâmetro uma figura e ele vai salvar essa figura no disco de alguma forma. E daí nesse meu exemplo eu estou implementando diferentes classes concretas as três classes concretas que salvam diferentes formatos. Então eu posso salvar a figura arquivo PDF, num arquivo jpg, ou num arquivo png e aqui sim eu teria a classe concreta. Aliás eu errei. Coloquei itálico e não devia ser itálico, devia ser normal aqui porque seria método concreto que realmente salva essa figura que é passada como parâmetro no disco. E aqui sim então teria algumas dezenas de linhas de código para salvar no pdf e depois dezenas de linhas de código para se salvar jpg. E o interessante disso é que esses algoritmos específicos de gravar no disco diferentes formatos ficam totalmente separados do editor de figuras. A classe principal do editor de figuras não deve conter detalhes específicos de como gerar arquivo png. Isso fica isolado lá na classe, salva a png, que é uma classe específica para isso. Então fazendo isso, a nossa arquitetura fica muito melhor. Particular aqui no editor de figuras você provavelmente vai ter método chamado graveFigura, mas o que ele faz, ele delega a execução disso para objeto salvador, para o método salve. Então tempo de execução esse Salvador vai apontar para desses três classes concretas né. Aqui dentro da figura não preciso saber qual das três. Provavelmente vai ter algum no meu salvador editor de figuras vai ter menu de configurações onde eu digo qual é o tipo de arquivo de saída que eu quero. Daí eu configuro: eu quero arquivos do tipo PDF. E daí toda vez que eu gravar uma figura automaticamente já vai chamar aqui o SalvaPDF e gerar aquele PDF. Note que aqui o que a gente tá fazendo é substituindo herança por delegação, né? Vez de ter editor de figuras e ter três subclasses de editor de figuras para gravar nos três tipos diferentes e daí essa classe editor de figuras ter uma hierarquia super grande e complexa, eu delego a ação de salvar a figura para uma outra classe separada. Então eu evito de ter uma classe enorme de editor de figuras, delego parte dessa ação para outro conjunto de classes, aqui nesse caso encabeçada por essa Salvador de figura. Então esse aqui é o padrão estratégia, onde aqui eu tenho uma estratégia de salvar uma figura. Então esse é o padrão estratégia. Então tem esse livro Design Patterns que é livro que eu recomendo que vocês deem uma olhada algum dia. É livro muito bom, vale a pena ler inteiro, mas é livro de difícil leitura. Primeiro porque ele usas sinais demais e small talking, segundo porque é livro profundo. Algumas centenas de páginas escritas 95 com uma reflexão muito profunda sobre orientação a objetos. É livro excelente, mas é livro que eu diria de difícil leitura, não é fácil. O pessoal observou isso, que é livro de difícil leitura e daí anos mais tarde, eu não me lembro exatamente quando, ou quase uma década mais tarde apareceu esse outro livro, que é o Head First Design Patterns, que é livro de muito fácil leitura, é o oposto. É livro muito bom também mas é livro todo bem humorado, cheio de piadinhas e cheio de historiazinhas, sempre vem com piadas o tempo todo, monte de figuras. Então é livro bem agradável de se ler e também descreve aí todos os design patterns. Então só para vocês terem uma ideia aqui desse livro eu vou dar exemplo do livro, o do padrão estratégia de novo. Ele fala o seguinte: você trabalha numa empresa e seu chefe pediu para você fazer simulador de patos. Patos do quém quém. Simulador de patos porque os acionistas da empresa querem, é muito importante para esta empresa ter simulador de patos. Você vê que os exemplos não são muito sérios, são sempre engraçadinhos. E daí você recebe uma ligação telefônica falando: ô Joe eu tive aqui uma reunião com os acionistas e eles fizeram ali uma demonstração do simulador de patos que você fez e de repente tinha pato de borracha, aquele patinho de que a gente usa no banho e o pato saiu voando. Tá errado isso porque patinho de borracha não sai voando. Tem algum erro no seu código. Então o que aconteceu aí? O que aconteceu foi o seguinte, o Joe fez esse design aqui. Então tinha uma classe pai chamada Duck/Pato e que tem todas as coisas que pato é capaz de fazer. Então o pato pode fazer quack, ele pode nadar, ele pode desenhar o pato ali na tela, no método do display, e daí o Joe, ele tinha três tipos de pato. O pato MallardDuck, o RedheadDuck, o pato de cabeça vermelha e tinha também o RubberDuck que é o patinho de borracha. Algum momento ele quis fazer os patos voarem e ele colocou na super classe. Ele falou, olha tem dois patos que voam então eu vou colocar na super classe esse método de fly. E daí sem querer ele acabou fazendo o pato de borracha também voar porque ele colocou o método fly na superclasse. E daí que causou todo aquele problema né. Então ele falou que o que ele achou que seria excelente uso para herança porque ele ia reutilizar esse método fly, vez de ter fly para cada tipo de pato de cabeça vermelha e uma larg duck. Ele colocou na superclasse, mas aí sem querer ele acabou colocando aquele comportamento de voar também no pato de borracha que não devia voar. Então algo deu errado. Então uma possível solução para isso é usar o padrão estratégia. Como ficaria com padrão estratégia. Então com o padrão estratégia a gente teria ali de novo a classe pato com várias coisas que os patos fazem e quatro subclasses nesse caso aqui. Então tem MallardDuck, o RedheadDuck, o patinho de borracha né e ali a gente tem o DecoyDuck também. E daí essa classe Duck teria duas estratégias também. Serão dois comportamentos que ela delegaria para outras classes implementarem esse comportamento usando o padrão strategy. O primeiro seria esse Fly Behaviour o comportamento de voar usando o padrão Strategy. Seria encapsulada nessa interface aqui Fly Behaviour, que nesse exemplo teria duas implementações, o fly with wings que é voar com asas e o fly no way ou seja, quem não voa de jeito nenhum. E depois teria outro comportamento, que é o quack behaviour e daí de novo usaria o padrão estratégia para ter diferentes estratégias ali de quackar. Particular tem então essa interface Quack behaviour que define a interface para para você fazer quack, que método quack e se cria três classes implementando essa interface que seria a classe quack, que simplesmente ele faz quack, quack. A classe squick, é aquele barulhinho que o patinho de borracha faz quando você aperta ele. E finalmente tem o pato mudo ali. O pato mudo você fala para ele fazer quack ele fica quieto, ele não faz nada. Coitado né finalmente teve o pato ele fica quieto não faz nada. Então seria jeito de eu pegar dois comportamentos ali interessantes para essa minha implementação do pato e eu vou extrair para diferentes grupos de estratégias aqui eu estou usando o padrão strategy duas vezes. E daí toda vez que eu crio novo pato, eu tenho que definir qual a estratégia que eu tô usando. Então quando eu crio Rubber Duck lá no meu construtor do rubber duck eu vou criar flying no way e plugar esse flying no way no fly behavior e eu vou criar squik e vou plugar o squick no quack behavior. Já esse RedheadDuck eu vou pegar FlyWithWings e plugar no construtor dele, plugar no fly behaviour Eu vou pegar o quack e plugar no quarto behaviour. Então eu configuro os meus comportamentos no Construtor do pato que eu tô criando. Então esse é o exemplo desse livro Head First Design Pattern, você vê que são sempre exemplos bem humorados, cheio de desenhos. Então é livro bem legal de dar uma olhada também. Então espero que vocês tenham pegado a ideia do padrão strategy. Vocês vão ter que exercitar agora usando, implementando, fazendo sua primeira implementação do padrão strategy e ao longo desse cursos a gente vai ver os outros padrões do GoF. Então o GoF tem 23 padrões, tem esses cinco padrões que falam sobre criação de novos objetos, a gente já vai ver. Depois tem todos esse padrões que falam sobre como estrutura coleções de classes, como estruturar coleções de classes para organizar o nosso programa, nosso software, para resolver diferentes problemas de complexidade e torná-lo mais flexível. E finalmente padrões comportamentais, a gente ja viu deles hoje que é o padrão Strategy. A gente vai ver todos esses outros padrões comportamentais do GoF. Agora tem uma lição de casa para você. Uma atividade para vocês fazerem aí casa. Duas coisas. Primeira coisa. Busca no seu buscador web preferido Java GoF patterns. Digita lá Java GoF patterns. E dá uma olhada nas páginas, na web é diferente o que fala sobre padrões. GoF in Java dá uma olhada neles, essa é a primeira lição de casa, a segunda lição de casa. Qual a sua linguagem de programação preferida? Vai lá e buscar por agora usando implementando fazendo aí dentro do padrão strategy vocês vão ter que ver se tá agora GoF Patterns. Python. Coloca Python GoF patterns, Stela GoF patterns, C++ GoF patterns. Escolhe a sua linguagem ali. Se a sua linguagem de programação preferida for C não sei se você vai encontrar algo interessante, porque C não é uma linguagem orientada a objeto, mas você pode. arriscar e ver o que você encontra, tá bom. Então por hoje é só. Eu espero que vocês tenham gostado. Para terminar vamos recapitular o que o Christopher Alexander, aquele arquiteto de prédios, não arquiteto de software disse que é padrão. Cada padrão descreve problema que ocorre repetidamente, de novo e de novo nosso ambiente, então descreve a parte central da solução para aquele problema de uma forma que você pode usar a solução milhão de vezes sem nunca implementá-la duas vezes da mesma forma. Então no padrão strategy a gente tem problema. Eu tenho uma família de algoritmos, grupo de algoritmos e eu gostaria de plugar diferentes algoritmos diferentes momentos. Ter diferentes estratégias. Como que eu organizo isso? Daí o padrão strategy dá a solução. Você organiza isso extraindo esse grupo de algoritmos. Cria uma super classe abstrata ou uma interface para representar a interface desse grupo de algoritmos e daí implementa várias classes que implementam aquela interface usando diferentes algoritmos para fazer aquilo que tem que ser feito e daí tempo de execução você pluga algoritmo ao outro ou quando você cria seu objeto ou tempo de execução você pode até mudar a chave algoritmo se quiser. Então essa é a solução que o padrão strategy oferece para esse problema tá. Note que aqui o Christopher Alexander ele fala que você nunca quer implementar duas vezes da mesma forma. Código, software talvez a gente quer sim implementar da mesma forma porque a gente quer reutilizar o máximo possível de código, mas às vezes cada vez que a gente implementa tem que mudar pouquinho alguns casos, mas a gente sempre busca diminuir o trabalho, reutilizar o máximo possível de código então a gente evita fazer de formas diferentes se é possível. Então espero que vocês tenham gostado. Por hoje é só. Bom trabalho.
