Olá. Eu sou Leonardo Leite e esse é o segundo vídeo de exemplos de aplicação de padrões de projetos de programação orientada a objetos sistemas de software reais desenvolvidos pelo Serpro, que é a empresa estatal que faz sistemas de software para o governo federal. Então, nesse segundo vídeo, o principal exemplo será o padrão 'State'; e, também, com uma pequena ajuda do padrão auxiliar 'Factory Method'. E aqui a gente vai usar o sistema CSV. CSV que quer dizer Sistema de Segurança Veicular. Quando você faz alguma alteração no seu veículo, que pode afetar a segurança, como blindar, que deixam o veículo mais pesado ou trocar o combustível do veículo, você é obrigado por lei a fazer uma inspeção de segurança do veículo. E você vai numa empresa privada onde o engenheiro faz a inspeção e essa empresa comunica os dados da inspeção para o sistema do governo federal, que é o CSV. E o CSV emite o certificado de segurança veicular. E esse documento, esse certificado, tem ciclo de vida. Esse ciclo de vida é representado nesse diagrama, que é diagrama UML, de Estados. Então, aqui a gente vai ver que a gente tem operações que vão mudando o estado do documento. Primeiro o documento é registrado e ele nasce num estado não emitido. Enquanto ele está não emitido, o engenheiro pode alterar esse documento. Aí o engenheiro assinou, uma vez que ele assinou, agora esse documento passa a valer oficialmente, tem valor público, ele está emitido. Uma vez emitido pode ser utilizado, pode ser consumido. E depois de consumido não pode mais ser cancelado. Cancelado, ele só pode ser enquanto não está emitido. E esse diagrama de estados mostra as transições válidas no ciclo de vida do documento. E, mais ainda, com esse diagrama, a gente também entende quais são as transições inválidas, as transições proibidas. Vou elencar aqui as principais. Se você já emitiu o documento, já era, não pode mais alterar. Se você já utilizou o documento, já era, você não pode mais cancelar. A questão do padrão State é como você faz para garantir que essas transições inválidas não serão realizadas. Vamos por partes. O primeiro passo é definir uma interface que é a interface do estado, que são as coisas que são possíveis de se tentar fazer num estado qualquer. Seja qual for o estado que o documento esteja, o usuário pode tentar alterar o documento, pode tentar assinar, cancelar e assim por diante. E aqui a gente tem as sessões, porque a idéia é que uma sessão representa é que a ação não vai ser permitida. Como ficará mais claro agora. Porque é o seguinte. A idéia é que para cada estado a gente vai ter uma implementação daquela interface que é a interface CSV State. Por exemplo, para o estado emitido, a gente tem aqui o 'emitido state' que implementa aquela interface. Implementar a interface significa que tem que implementar todos aqueles métodos, método para cada operação. Ou seja, esta classe, o que ela está definindo? Ela está definindo quais são as transições válidas e as transições inválidas no estado emitido. Se alguém tentar assinar e já está no estado emitido. Olha, no estado emitido já assinou, não pode mais assinar! Aqui, nessa classe joga uma exceção, ou seja, falando, é proibido assinar no estado emitido. Se a gente for tentar alterar o documento, não pode mais alterar depois de assinado, quando já está emitido. Então também joga uma exceção. Não pode. E se você tentar cancelar no estado emitido? Cancelar pode. Então, o emitido state chama o cancelador e que vai de fato cancelar. Mas é o seguinte, além de ter como essas classes vão ser utilizadas nessa classe, que é uma classe para estado, implementando CSV state, a gente tem também no sistema uma classe para cada operação. Essas classes por operação já existiriam independentemente do uso do CSV state. Então como exemplo, a gente tem a operação 'cancelar csv' que é a classe que representa uma operação de cancelamento. E o ponto é que essa classe não vai chamar o cancelador que sabe cancelar diretamente. Aqui é que vem a parte interessante. Dependendo do estado do CSV, o CSV vai ser cancelado. E como funciona esse "dependendo do estado dele"? Esse 'dependendo do estado' dele é método que está definido nessa classe aqui abstrata, "operação com estado" que é herdado pelas classes de operação. E esse método é bem simples. Ele recebe CSV e com base nesse CSV devolve CSV state. Qual CSV State? Qual complementação? O CSV state é uma interface. Ele vai descobrir se esse CSV está, mas está emitido, vai voltar 'emitido state'. E para conseguir fazer esse mapeamento, ele vai usar essa classe que é a State Factory. E é aqui que a gente vai estar usando o padrão de método de fábrica, o 'Factory method', que é esse método 'getstatefor'. E o funcionamento dele, a idéia é bem simples. Ele pega o número do CSV, faz uma pesquisa do banco de dados para descobrir o estado. Esse estado é nome. E ele faz o mapeamento. Se ele vê que esse CSV está no estado de emitido, devolve 'emitido state'. Se ele estiver no estado, por exemplo, cancelado, vai devolver 'cancelado state'. E voltando aqui no nosso 'emitido state'. Lembra que, por exemplo, se ele for, se alguém tentar cancelar e ele estiver no estado de emitido, então, pode cancelar que então ele vai chamar o cancelador. Então, para fechar aqui eu vou chamar o cancelador. Então, o cancelador não tem monte de hífen, monte de validação, monte de lógica, para decidir se pode cancelar ou não. Ele simplesmente vai e cancela. E é isso que torna o código mais coeso e as classes mais desacopladas que é dos grandes objetivos da orientação ao objeto e que o padrão CSV state nos ajuda aqui. Ele também ajuda, principalmente, a evitar esquecer coisas. Quando o desenvolvedor tem que implementar novo estado, ele vai ter que... Se surgir novo estado, pode ser que surja, ele vai ter que implementar todos esses métodos e definir completamente essa matriz para cada estado o que pode, ou não pode, quando alguém tentar fazer determinada operação. E assim evitam-se casos omissos e gerar todos esses comportamentos inesperados. Então, para fechar, resumindo. A gente tem diversas classes de operação. Todas essas classes de operação herdam de 'operação com estado' que vão dar método de conveniência para chamar o 'StateFactory'. Esse 'StateFactory' tem método de fábrica que vai, com base no estado do CSV, devolver objeto implementando o 'CSV State', por objeto de operação utilizado. Ou seja, dinamicamente, tempo de execução, o objeto da operação vai estar chamando métodos algumas dessas implementações concretas do CSV state. Mas a parte boa é que o código da operação depende somente do código da interface CSV State. O código da operação não conhece essas classes concretas específicas. E esse é bom princípio de programação orientada a objetos, porque melhora a interface. Depende de algo mais abstrato e estável e não de coisas concretas. Se surgir novo estado, a classe operacional nem vai precisar ficar sabendo. E então, se está no 'estado emitido', ele vai, tempo de execução, usar o 'emitidostate'. Se ele tentar chamar o método de alterar, e for uma operação de alteração, não vai conseguir alterar. Se for uma operação de cancelamento, vai chamar o método cancelar e vai conseguir cancelar. E é isso. Espero que tenham gostado do 'Padrão State'. Tchau pessoal! Obrigado.