Posted on Sep 29 Trarei um artigo resumindo os capítulos do nível intermediário do Código limpo. Focando no Capítulo 6: Objetos e Estruturas de Dados e Capítulo 10: Classes. Claro que citarei os demais capítulos, mas focarei mais tempo nesses. Se você já programou em uma linguagem tipada ou até uma linguagem que possuísse apenas a modularização de um agrupamento de valores determinados em uma Classe, você já se deparou com o primeiro caso de estudo que o nosso saudosista Tio Beto nos expõe. Precisamos definir o que é Objeto e o que é Estrutura de dados. Objetos são classes com valores agrupados e privados que possuem certa lógica relacional e os seus valores são protegidos e/ou privados para demais acessos. É recomendado possuirem uma assinatura de classe, uma interface. Por exemplo:Qual é a implementação desta classe? não importa no momento. Importou ao desenvolvedor que a desenvolveu. Entende o porquê dela existir? Esse nível de abstração é que te dá a segurança que o problema dos outros neste objeto não vão ser os meus ao utilizá-la (só acaso o método não esteja correto, o que ocorre quase sempre). Se os objetos não expõe os seus valores privados, as estruturas de dados por outro lado são uma entidade que tem a função de aglomerar dados relacionados e expor para a utilização. As funções que a estrutura tem estão relacionadas a própria estrutura.Ainda dentro de estruturas de dados, podemos criar uma interface para correlacionar estruturas que tem características semelhantes, porém alguns atributos diferentes. Essa correlação é chamada de polimofismo.Sempre que necessário, você pode fazer uma fusão entre os dois tipos, gerando um tipo híbrido. Um tipo híbrido é utilizado quando você precisa das funções relacionadas a uma classe com variáveis (ou outros objetos) privados, mas possui a injeção de de informações sendo necessárias. Olha, é uma confusão a parte, faça por sua conta e risco, eu não vou reproduzir por aqui. Só saiba que existe e não é errado... eu só não recomendo. Ou recomendo. Vai depender muito do contexto. Em geral não. Separe frei Damião de frei de caminhão. Como o tio Beto é javista, não posso deixar de ressaltar que muita coisa do capítulo é desnecessária se você nunca tocou em Java na sua vida (talvez você continue com cabelo, nem tanta coisa assim). Tentarei sintetizar o que realmente importa sobre o tratamento de erros. Faça.Ok, mas como fazer o tratamento de erro certinho? Primeiro, devemos verificar a fonte do erro. É a execução de uma função assíncrona? é uma operação que pode me retornar um valor nulo? é um acesso que foi fora da curva? Whatever. Utilizaremos a estrutura try catch para filtrar a existência daquele erro, ou seja, evitar que o erro se torne uma exception de sistema e encerre a execução do fluxo normal do seu programa. Vamos ao exemplo:No código, A estrutura try tem como escopo o método call que é um método assíncrono e que pode ser ou não executado, como todo método assíncrono corre o risco. Caso execute sem erro algum, o código prossegue sem a participação do método catch. Se houver um erro, o método catch irá receber uma exceção e decidir como comunicá-la ao resto do sistema, o que chamamos de tratamento de erro. O código ali em cima é apenas um exemplo seboso, não reproduza em produção! log não é tratamento de erro... é ferramenta de debug.Agora você me pergunta, o que podemos fazer com esta exceção além de encarar o nosso iminente fracasso e se lembrar de todo aquele bullying sofrido na escola, na universidade, no trabalho? Podemos transformar ele, com terapia? nah, com Orientação a objetos e estrutura de dados. Ainda estamos falando de código.Para o tratamento de erro ser eficaz precisamos ter o mínimo controle de onde a exceção vem, mas como podemos fazer isso se uma Exception é uma Exception? Utilizando o conceito visto anteriormente em estruturas. Polimorfismo. Vamos criar uma exception apenas para a função callMeByYourName.Agora com a nova exceção, podemos voltar ao código ruim, digo, código em construção lá de cima e consertá-lo.Como você vai modificar seus erros, como vai alertar ao usuário, se vai fazer alguma coisa com eles afinal, fica a seu critério. Porém é importante saber que é boa prática dar um fim digno as suas falhas (momento terapia). Este capítulo é voltado para pessoas desenvolvedoras que trabalham com códigos de terceiros e muitas vezes tem acesso restrito, muito pouco acesso ao seu código fonte, ou código que ainda não existe. A regra geral que o tio Beto dá é abstrações. Utilize interfaces, repositories e usecases para evitar que a presença do código do terceiro se enlace com o seu código.O repositório vai tratar com o objeto fictício de conexão, não sabemos o que é o fairyBase só que ele faz o login. Enfim, tratamos o erro e chegamos ao Usecase:Limites são apenas uma garantia de que você não precisa ter dor de cabeça se precisar arrancar o código de terceiros do seu, ser fácil e indolor. Para quê, não é mesmo? brincadeira, brincadeira. Vamos pensar que testes são "necessários" para um sistema. Não trataremos testes como um código a parte. Testes são parte do seu código, ou seja, podem seguir as dicas vistas até o presente momento. Primeiro, simplique seus testes. Se as funções devem ser simples, como vimos no Capítulo 3, os testes também. Vamos ao exemplo:Um teste curto, com apenas uma funcionalidade testada. Simples e limpo. Todos os testes vão ser assim? claro que não, mas é desejável ser unitário. Além da característica de ter todas as outras dicas do Tio Beto citadas anteriormente para código em produção, os testes para serem limpos seguem cinco regrinhas definidas pelos chatos... digo, senhores, do Agility: F.I.R.S.T.Fast (rapidez): Os testes devem ser executados rapidamente, se estão demorando, estão errados;Independent (independência): nenhum teste depende de outro teste ou de estrutura para execução;Repeatable (repetitividade): os testes devem ser repetidos em qualquer ambiente, em qualquer momento, em qualquer lugar;Self-validating (auto validação): Ou é ou não é! testes são booleanos. São feitos para dar certo ou para dar errado;Timely (pontualidade): Devem ser escritos no tempo de desenvolvimento. Pode ser antes, se o seu time utiliza TDD. Nunca depois. O assunto teste é imenso, um dia talvez eu volte a tratar disso por aqui, por enquanto, eu vou fingir que eles não existem... só por enquanto. Já falamos de Estruturas de dados, falamos de objetos, agora vamos falar da sua generalização. Classes. Você me pergunta, porque carvalhos verdes e eretos este assunto é abordado ao final de todo esse rolê? E eu te respondo: não faço a mínima ideia. Eu chuto mau gosto do Tio Beto (se você é engenheiro ou arquiteto de software e tem a resposta, por favor, deixe nos comentários. Eu realmente quero saber). O primeiro tópico abordado é a organização. O Tio Beto, como já citei é da igreja do Java do sétimo dia útil e segue recomendando a organização que os primeiros homens utilizavam.Lembrando daquela bobagem que foi citado no Capítulo 3, as funções dentro de uma classe devem seguir uma ordem de storytelling... falta task a este jovem senhor, relevem. Seguindo a máxima de quanto mais simplificado, melhor (olha que ironia) o conselho primordial é que as classes devem ser pequenas. Diferente das funções, que contávamos quantas operações cada função faria, com classes, uma classe é considerada pequena se ela tiver poucas responsabilidades, ou melhor, uma única responsabilidade. O conceito de single-responsibility ou responsabilidade única é o famoso cada macaco no seu galho. Você vai dar a sua classe apenas as atribuições que ela tem.Vamos estudar o exemplo abaixoTemos uma super classe para SoundFile, vamos simplificar em classes menores, vamos criar os famosos Usecases.Tá, tenho classes minúsculas que fazem uma única coisa, mas e como faço pra essas coisas trabalharem juntas? Daí fazemos uma classe que faz apenas uma coisa também, uma classe controladora. A classe controladora tem que ter apenas uma responsabilidade, controlar. E esse tipo de controle tem que ser restrito ao seu tema. Vamos seguir o exemplo anterior e criar uma controladora.A controller não tem uma lógica no escopo, não tem uma operação, a função dela é apenas de união e controle das demais classes citadas. Agora fazendo uma análise de todo esse passo a passo, parece verboso e muito cansativo tudo. Porém imagine o caso de compartilhamento de usecases. Se fosse possível utilizar o mesmo usecase de tratamento de som em uma classe para a adição de áudio em um filme, não teríamos que importar toda a classe de edição de audio, apenas um arquivo. E se precisar remover esse arquivo? além de um delete, 3 linhas de código somem na sua controladora. Isso nos diz que o nosso código está isolado, fácil de remover ou modificar, baixo-acoplado. E quanto mais fácil de alteração um sistema é, mais fácil é a sua manutenção. Como expliquei no textinho de abertura do projeto o Clube do Livro Dev: Código Limpo, o livro Código Limpo possui níveis de entendimento. A partir do capítulo 11, a dificuldade do livro para mim cresce. Infelizmente ainda não cheguei ao nível de desenvolvimento e expertise para falar com propriedade e até com uma pitada de ironia, de certos temas como Sistemas, Concorrência e Emergências. Outros temas abordados no livro, como temas próprios para Java não me brilham os olhos. Então deixo aqui uma promessa de que um dia voltarei a visitar o livro do Tio Beto, como uma nova experiência, outros tantos comentários sarcásticos e sem noção para fazer a este senhor que tanto fez pela comunidade e hoje nos enche de um misto de sentimentos. Nunca é um adeus Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Camilo Micheletto - Sep 25 Steven Murawski - Sep 25 Pavan Belagatti - Sep 26 Retiago Drago - Sep 17 Once suspended, loremimpsu will not be able to comment or publish posts until their suspension is removed. Once unsuspended, loremimpsu will be able to comment and publish posts again. Once unpublished, all posts by loremimpsu will become hidden and only accessible to themselves. If loremimpsu is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Lorem Impsu. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag loremimpsu: loremimpsu consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging loremimpsu will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.