Vamos agora aumentar o nÃvel da nossa discussão e falar pouco num nÃvel mais filosófico. A gente vai ver o que são os princÃpios SOLID, mas antes disso vamos ver uma motivação para eles, porque que a gente deve desenvolver software dessa forma se a gente quer chegar num software de altÃssimo nÃvel. A palavra SOLID é termo cunhado a partir dos princÃpios de projeto orientado a objetos de Robert Martin, que é desenvolvedor de software, engenheiro de software, cujo apelido é o uncle Bob, é o tio Bob. 2000 ele escreveu artigo que falava desses cinco princÃpios, depois eles perceberam que as iniciais desses princÃpios davam essa palavra SOLID, SÓLIDO. Os princÃpios são o PrincÃpio da responsabilidade única das classes, das Classes abertas e fechadas, o PrincÃpio da substituição de Liskov, PrincÃpio da segregação de interfaces e o PrincÃpio da inversão de dependências. Antes de explicar o que é cada desses vamos ver a motivação. O Robert Martin identificou grande problema ali com software, com o mundo do software. Ele conta uma historinha, não é exatamente a causa do problema mas é uma historinha interessante. Ele diz que o número de programadores tem dobrado a cada cinco anos. Na década de 50 talvez existiam 10 ou da ordem de dezenas de programadores no mundo. Já na década de 60 existiam centenas, na década de 70 milhares, hoje dia estimativas dizem que existem mais de 100 milhões de programadores no mundo. Então média a cada 5 anos tem dobrado o número de programadores do mundo. Corolário disso aqui, metade dos programadores tem menos de 5 anos de experiência, produzem código com muito pouca experiência. Então boa parte do código que tá escrito aà no mundo é escrito por pessoas com pouca experiência. Isso leva ao fato de que muito código ruim é escrito. Eu acho que não é só isso, porque na verdade existem programadores experientes que também escrevem código ruim, porque não tem muita preocupação com qualidade de código e por outro lado existem jovens programadores que tem 3, 4 anos de experiência e já tem essa preocupação de escrever software de alta qualidade. Então o que eu espero de vocês é isso. Vocês são jovens programadores, estão aprendendo, mas essa preocupação com a alta qualidade do software e bom design do software tem que estar desde o começo. Então ser jovem programador não é desculpa para não ser excelente programador. Por isso que vocês estão aqui. Mas o que é esse código ruim que é escrito? Ele fala que é código que é muito rÃgido, frágil e que têm problemas de mobilidade. Vamos ver quais são esses problemas que aparecem no código. Então primeiro rigidez. A ideia é que código muito rÃgido é aquele código onde mudanças lugar afetam vários outros lugares. As vezes você está programando num sistema lá relativamente grande, você vê aqui probleminha, você conserta o erro. Daà para consertar o erro aqui você fala "ih, mas esse código chama aquele, eu preciso consertar ali também". Daà você vai consertar ali, fala "mas esse pedaço aqui é chamado para essa outra classe, eu vou precisar mudar naquela outra classe". Você vai indo, você vai seguindo essas linhas, o código é uma coisa complicada. Às vezes pequenas mudanças que você faz num pedaço do código gera inconsistências outros lugares, que eu vou ter que acertar aquelas outras inconsistências. Isso gera o que a gente chama de código espaguete. Esse código onde essas linhas de dependências vão indo para lado e o outro, gera todo aquele espaguete emaranhando. O Joe Yoder tem artigo que chama Big ball of mud, que fala desses pedaços de software que na verdade é uma grande bola de lama, tudo misturado ali dentro e que você não consegue entender quais são as componentes e como elas se relacionam de tão emaranhado que está essa coisa. Então esse é o tipo de coisa que a gente não quer ter porque essa rigidez atrapalha o desenvolvimento do software. Então à s vezes o programador por preguiça vai escrevendo esse código feio, todo emaranhado porque ele quer ser rápido, mas na verdade isso torna ele muito mais lento, porque trabalhar nesse tipo de código a médio prazo e nem falando longo prazo, médio prazo, já vai tornar a sua produtividade muito melhor. Então não vale a pena você ser preguiçoso e escrever qualquer coisa. Vale a pena você pensar muito bem o que escrever, daà você escreve pouco, daà você melhora aquilo que você escreveu, daà você continua escrevendo outros pedaços, daà você refatora aquilo para melhorar. Sempre ter aquela melhor arquitetura possÃvel, melhor código possÃvel. Outro problema é essa fragilidade. Às vezes você muda uma coisa aqui no pedaço do código e outras coisas ali que você nem imaginou qual a relação quebra. Então você muda código que calcula o salário de funcionário, depois ali no relatório mensal da empresa quebra, dá null pointer exceptions ali, seu sistema morre, você nem entende o por quê. Esse é código frágil. Outro problema é imobilidade, que é a ideia de que é difÃcil eu usar o código de lugar para outro. As vezes você faz uma função que calcula alguma coisa que seria útil, uma função que calcula a aceleração da gravidade, como os objetos se movimentam, você faz isso para simulador de fÃsica, depois você quer usar num videogame. Você gostaria só de colocar aquele código lá, mas não funciona direito, é difÃcil porque o código não foi feito para isso. Ou as vezes você precisa de alguma coisa, seu amigo fez código, faz exatamente aquilo que você precisa. Daà você vai pegar o código do amigo, daà você olha, mas aquele código do amigo depende de tanta coisa. Ele fala "para você usar esse meu código você precisa instalar esse framework, essa biblioteca, essa linguagem, esse interpretador", é tão complicado de usar aquele código que você desiste de usar, é mais fácil escrever de novo do zero. Então esse é código que é imóvel; não é o que você gostaria de código. Tem acoplamentodepois você pensa nesses três vamos ver vamos pular para os princÃpios sólidos tá excessivo, boa parte do que a gente falou é código com acoplamento excessivo. E é isso que a gente quer evitar. A orientação objetos ela nasceu inclusive para ajudar a resolver esses problemas. Então tem três palavras mágicas da orientação objetos: o encapsulamento, essa ideia de que cada módulo, no caso de orientação objetos, cada classe, cada objeto teria ali os dados e o código que manipula só aqueles dados independente do resto, com o mÃnimo de acoplamento com o resto. Essa ideia de herança, que é uma forma de você organizar o reuso de código incrementando aos poucos a funcionalidade que você vai usar. E polimorfismo, que é a grande chave, que é você poder usar código, fazer uma chamada, escrever uma linha de código que na verdade vai fazer coisas diferentes de acordo com o jeito que você estrutura. E o polimorfismo, na verdade, é o mais poderoso que a gente tem para lidar com esses problemas de rigidez no código. Vamos pensar termos genéricos. Vamos supor que tem módulo M1 que chama o módulo M2. Se orientação objetos vai ser objeto M1, que chama objeto M2, uma classe M1 chama a classe M2, mas nem precisa ser orientação objetos. Pode ser algo genérico. Então módulo chamando outro módulo. Antes de usar orientação objetos isso criava uma dependência forte de M1 para M2, porque no código do M1, o código-fonte do M1 ia conter o texto lá M2 para fazer a chamada dessa função, desse método ali no M2. Então gerava uma dependência muito forte, acoplamento muito forte. Com o polimorfismo que a orientação objetos trouxe a gente pode escrever M1 usando o M2 mas sem fazer referência nenhuma ao M2. Não aparece o string M2 no código-fonte do M1. Eliminando essas dependências, esses acoplamentos fortes, a gente pode evitar a rigidez, a fragilidade mobilidade. Como que a orientação objetos faz isso? Nas linguagens fortemente tipadas a gente vai usar classes abstratas de alto nÃvel, ou interfaces de alto nÃvel e o M1 vai fazer referência à uma interface, à uma classe abstrata, sem a referência à s classes concretas. Se é uma linguagem dinâmica, tipo Python, Smalltalk, Ruby você nem precisa disso. Você não precisa nem da interface, você simplesmente chama o método sem dizer qual é o tipo do objeto que você está chamando. Esse tipo de polimorfismo ajuda, se bem programado, se bem usado, ajuda a resolver esses três problemas. Então tem uma tarefa para vocês agora. Vocês vão parar o vÃdeo, vai acabar o vÃdeo. Quero que você pense pouco e tente lembrar de código que você viu nas últimas semanas, últimos meses, últimos anos, que possuÃa essas propriedades indesejadas. Então pense num exemplo de código que era rÃgido, que era difÃcil mudar. Pense num exemplo de código frágil, que você mexia lugar quebrava outro. E pensa exemplo de código com pouca mobilidade, que você queria reutilizar aquele código lugar e outro e viu que ia ser complicado. Pense nesse três exemplos. Agora, só depois você pensa nesses três. Vamos ver, vamos pular para os princÃpios SOLID.
