[MÚSICA] [MÚSICA] Olá a todos. Meu nome é Eduardo Guerra. Esse é o Curso de Desenvolvimento Ágil com Padrões de Projeto. A gente está falando sobre os padrões que usam composição e vou falar de padrão muito legal, que é o State. Ele resolve uma questão que todo o mundo acho que já deve ter passado algum sistema, é quando você precisa, você tem objeto que tem estados e ele tem de se comportar diferente de acordo com esse estado que ele está. Então vamos ver o padrão State. Imagina que a gente tem uma ordem e, tem determinados Status para essa ordem. Ela está pendente, se ela já foi paga, ela já foi enviada, se ela já foi entregue. Então, que acontece? Às vezes, por exemplo, pegar quantos dias estão faltando. Não vou olhar o código com detalhe mas eu, por exemplo, calcular quantos dias faltam, a ordem vai depender de estimativa de entrega, estimativa de envio, se eu tenho produto stock, se eu não tenho. Então, dependendo do Status, da ordem, o cálculo vai ser diferente. Só que infelizmente, esse comportamento que depende do Status, ele acaba não sendo exclusivo, por exemplo, dessa parte do sistema. Eu vou ver ali, tenho que ver se está paga, se está reservada no stock, a quantidade que está reservada no stock. Então, isso tudo aí vai depender do Status. E muitos outros comportamentos da ordem, de como ela vai funcionar, o que é que ela vai retornar. Às vezes vai depender pouquinho do Status dela. Olha aí, que conflito. Espera aí, vou voltar. Olha que coisa feia. Código cheio de lixo. Como que eu posso resolver isso daí? O problema é que parece que uma coisa que poderia estar escrita no quadro, a giz, que a gente pode apagar e mudar, que é o Status, parece que ela está escrita na pedra. Parece que o cara foi ali e talhou aquela solução e aí, fica muito difícil, por exemplo, de acrescentar novo estado, novo Status para a ordem, imagina o pesadelo que ia ser. Então, nesse caso, a herança não funciona por motivo muito simples. Eu preciso que a minha ordem possa mudar o comportamento. As técnicas que eu tenho para fazer adaptação de comportamento através da herança, no momento que eu instancio o objeto, eu não posso mais mudar. O Status ele já tem essa característica de ser uma coisa dinâmica, afinal ele é estado. Ele não é uma coisa fixa. E aí, por exemplo, se eu tenho uma subclasse 'ordem pendente', se eu quero, se o cara vai lá e paga a ordem, eu vou ter de criar outro objeto de ordem paga e passar todas as informações. Não é isso que eu quero. Então, só por esse motivo, a herança, a gente vê que já não funciona. Aí, o nosso amigo, o Capitão Gancho, pirata, ele fala assim, "Opa, a gente pode ter uma 'hook class' representando esse Status." E aí, quê que acontece? Toda essa parte que depende do Status eu posso estar delegando meu comportamento para essa 'hook class'. Olha que bacana. Vez de eu ter uma string, por exemplo 'pago', eu teria uma classe 'pago'. E aí, toda essa parte que dependesse do Status eu chamaria nessa 'hook class'. Vamos ver como é que seria isso. Eu vou sair para vocês poderem ver o diagrama direitinho. Então, por exemplo, eu teria ali a classe ordem, com todos os seus métodos e eu teria ali uma interface que definiria o estado da ordem. Por exemplo, pegaria ali quantos dias estão faltando, pegaria ali se está pago. Via quanto que está reservado no stock. Eu teria ali uma subclasse para cada estado possível, pendente, pago, enviado, entregue. Todas as vezes que a minha classe ordem precisasse de alguma funcionalidade que é dependente do estado, ela estaria delegando esse comportamento para essa interface. Note que, no caso, a gente está vendo, obviamente, exemplo didático simples que os métodos são todos praticamente todos, eu vou estar delegando eles inteiros. Mas poderia, por exemplo, ser 'if', uma série de 'ifs' dentro de método maior. Nesse caso, eu extraí esse método para dentro da ordem e estaria delegando só aquele pedacinho ali para essa hook class no meu Estado. Cada implementação ali baixo: pendente, paga, enviada, etc, define como a entidade vai se comportar quando estiver naquele estado. Ou seja, quando eu chamar na ordem 'getDiasFaltando' e ele estiver composto por pendente, esse pendente vai chamar o 'getDiasFaltando' e ele vai tacar o fulano isso daí. Então, vamos ver pouquinho como é que fica o código. Então, eu tenho por exemplo, ali a ordem. Dentro dela vai ter uma variável que vai ser o estado. E, por exemplo, no 'getDiasFaltando' eu vou delegar isso para o estado. Se está pago eu vou delegar isso para o estado. Como eu falei, aqui iii a gente está fazendo exemplo simples que o método inteiro está sendo delegado. Eu poderia ter só pedacinho de método maior, que tem uma parte grande comum, mas às vezes, uma decisão, uma coisa que depende do estado e que efetivamente caía sendo delegado para essa classe, não precisou ser sempre o método inteiro. Então, nessa aula a gente viu o padrão State, padrão muito interessante para problema que eu, pessoalmente, já enfrentei nos mais diversos tipos de sistema. Com uma certa frequência, a gente precisa fazer esse tipo de adaptação de comportamento de acordo com o estado, que às vezes muda, aparece estado novo e você colocar isso num monte de 'if', realmente, acaba ficando uma grande bagunça. E você separando assim, você ganha flexibilidade, organização do código. Acho que vocês já devem ter passado por isso, eu não preciso nem estar falando as vantagens para vocês. Continue assistindo que na próxima aula tem mais padrãozinho que utiliza composição. Até lá. [MÚSICA] [MÚSICA]
