{"id":671,"date":"2025-12-26T19:59:39","date_gmt":"2025-12-26T22:59:39","guid":{"rendered":"https:\/\/cahfelix.tech\/blog\/?p=671"},"modified":"2025-12-26T20:30:50","modified_gmt":"2025-12-26T23:30:50","slug":"solid-sem-misterio","status":"publish","type":"post","link":"https:\/\/cahfelix.tech\/blog\/solid-sem-misterio\/","title":{"rendered":"SOLID sem mist\u00e9rio"},"content":{"rendered":"\n

Se voc\u00ea j\u00e1 escreve c\u00f3digo orientado a objetos, em algum momento vai ouvir algu\u00e9m falar de SOLID. Normalmente vem como um nome meio misterioso, que parece coisa avan\u00e7ada demais.<\/p>\n\n\n\n

Na pr\u00e1tica, SOLID \u00e9 bem mais simples do que parece.<\/p>\n\n\n\n

Ele n\u00e3o \u00e9 um framework que voc\u00ea instala, nem uma arquitetura que voc\u00ea precisa seguir \u00e0 risca. SOLID \u00e9 s\u00f3 um guia de boas ideias. S\u00e3o cinco princ\u00edpios criados para ajudar a tomar decis\u00f5es melhores ao escrever c\u00f3digo.<\/p>\n\n\n\n

A ideia \u00e9 simples. Evitar c\u00f3digo fr\u00e1gil, dif\u00edcil de entender e que quebra toda vez que algo muda. Seguindo esses princ\u00edpios, o c\u00f3digo tende a ficar mais organizado, mais f\u00e1cil de testar e muito mais f\u00e1cil de evoluir com o tempo.<\/p>\n\n\n\n

Vou usar as ilustra\u00e7oes do artigo\u00a0\u201cThe S.O.L.I.D Principles in Pictures\u201d<\/a>\u00a0de Ugonna Thelma<\/em>, de forma traduzidas, para compor esse artigo.
<\/p>\n\n\n\n

Resumo r\u00e1pido (TL;DR)<\/h3>\n\n\n\n
    \n
  • S:<\/strong> Uma classe, uma responsabilidade.<\/li>\n\n\n\n
  • O:<\/strong> Estenda o comportamento, n\u00e3o altere o c\u00f3digo original.<\/li>\n\n\n\n
  • L:<\/strong> Subclasses devem honrar o contrato da classe pai.<\/li>\n\n\n\n
  • I:<\/strong> Interfaces pequenas e focadas em vez de “interfaces monstro”.<\/li>\n\n\n\n
  • D:<\/strong> Dependa de abstra\u00e7\u00f5es (interfaces) e n\u00e3o de implementa\u00e7\u00f5es.<\/li>\n<\/ul>\n\n\n\n
    \n\n\n\n

    1. S \u2014 Single Responsibility (Responsabilidade \u00danica)<\/h2>\n\n\n\n
    \n

    “Uma classe deve ter um \u00fanico motivo para mudar.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

    \"\"<\/figure>\n\n\n\n
      \n
    • A Ideia:<\/strong> Cada unidade de c\u00f3digo deve fazer apenas uma coisa e faz\u00ea-la bem. Se uma classe valida dados, salva no banco e envia e-mails, ela tem tr\u00eas motivos distintos para ser alterada.<\/li>\n\n\n\n
    • Sinal de Alerta:<\/strong> Se voc\u00ea descreve uma classe usando v\u00e1rios “e”<\/strong> (ex: “esta classe calcula o b\u00f4nus e<\/strong> gera o log”), voc\u00ea provavelmente violou este princ\u00edpio.<\/li>\n\n\n\n
    • Benef\u00edcio:<\/strong> Mudan\u00e7as localizadas e baixo risco de efeitos colaterais.<\/li>\n<\/ul>\n\n\n\n
      \n\n\n\n

      2. O \u2014 Open-Closed (Aberto\/Fechado)<\/h2>\n\n\n\n
      \n

      “Aberto para extens\u00e3o, mas fechado para modifica\u00e7\u00e3o.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

      \"\"<\/figure>\n\n\n\n
        \n
      • A Ideia:<\/strong> Voc\u00ea deve conseguir adicionar novos comportamentos sem mexer no c\u00f3digo que j\u00e1 est\u00e1 funcionando. Isso evita causar bugs onde a Classe estiver sendo usada. Ent\u00e3o, se voc\u00ea deseja que a Classe execute mais fun\u00e7\u00f5es, a abordagem ideal \u00e9 acrescentar essas fun\u00e7\u00f5es e N\u00c3O alterar \u00e0s que j\u00e1 existem.<\/li>\n\n\n\n
      • Exemplo simples: <\/strong>Sempre que surge um novo tipo de regra e voc\u00ea precisa: abrir uma classe antiga, adicionar mais um if ou switch, O princ\u00edpio est\u00e1 sendo violado.<\/li>\n\n\n\n
      • A Pr\u00e1tica:<\/strong> Em vez de encher uma classe de if<\/code> ou switch<\/code> sempre que surge uma nova regra, utilize abstra\u00e7\u00f5es<\/strong>. Crie novas classes que estendam o comportamento base.<\/li>\n\n\n\n
      • Benef\u00edcio:<\/strong> C\u00f3digo est\u00e1vel e evolu\u00e7\u00e3o previs\u00edvel (voc\u00ea n\u00e3o quebra o que j\u00e1 est\u00e1 em produ\u00e7\u00e3o).<\/li>\n<\/ul>\n\n\n\n
        \n\n\n\n

        3. L \u2014 Liskov Substitution (Substitui\u00e7\u00e3o de Liskov)<\/h2>\n\n\n\n
        \n

        “Subclasses devem ser substitu\u00edveis por suas classes base.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

        \"\"<\/figure>\n\n\n\n
          \n
        • A Ideia:<\/strong> Esse princ\u00edpio busca impor consist\u00eancia para que a Classe pai ou sua Classe filha possam ser usadas da mesma maneira sem erros. Se um c\u00f3digo funciona com a classe pai, ele deve funcionar com qualquer filha, sem precisar de tratamentos especiais. Nesse caso, a\u00a0Classe\u00a0filha\u00a0<\/strong>deve conseguir fazer tudo o que a\u00a0Classe\u00a0pai\u00a0<\/strong>pode fazer. (esse processo \u00e9 chamado\u00a0de Heran\u00e7a<\/strong>)<\/li>\n\n\n\n
        • Exemplo simples: <\/strong>A imagem mostra que a\u00a0classe\u00a0pai\u00a0<\/strong>entrega caf\u00e9 (pode ser qualquer tipo de caf\u00e9). Portanto, \u00e9 aceit\u00e1vel que a\u00a0Classe\u00a0filha\u00a0<\/strong>entregue Cappucino, porque \u00e9 um tipo espec\u00edfico de Caf\u00e9. Mas, por exemplo, N\u00c3O seria aceit\u00e1vel entregar \u00c1gua!<\/li>\n\n\n\n
        • Sinal de Alerta:<\/strong> Subclasses que lan\u00e7am exce\u00e7\u00f5es do tipo “N\u00e3o implementado” ou que alteram drasticamente a regra de neg\u00f3cio da classe pai. Provavelmente a heran\u00e7a est\u00e1 errada.<\/li>\n\n\n\n
        • Benef\u00edcio:<\/strong> Contratos claros, polimorfismo confi\u00e1vel e menos bugs silenciosos.<\/li>\n<\/ul>\n\n\n\n
          \n\n\n\n

          4. I \u2014 Interface Segregation (Segrega\u00e7\u00e3o de Interface)<\/h2>\n\n\n\n
          \n

          “Interfaces espec\u00edficas s\u00e3o melhores que interfaces gen\u00e9ricas.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

          \"\"<\/figure>\n\n\n\n
            \n
          • A Ideia:<\/strong> Esse princ\u00edpio busca dividir um conjunto de a\u00e7\u00f5es em conjuntos menores para a Classe executar SOMENTE as a\u00e7\u00f5es que precisa. \u00c9 um desperd\u00edcio quando uma Classe \u00e9 obrigada a executar a\u00e7\u00f5es in\u00fateis. Al\u00e9m disso, pode produzir bugs inesperados se essa Classe n\u00e3o tiver a capacidade de executar essas a\u00e7\u00f5es. \u00c9 melhor ter v\u00e1rias interfaces pequenas e focadas do que uma “interface monstro”. <\/li>\n\n\n\n
          • A Pr\u00e1tica:<\/strong> Uma Classe deve realizar apenas as a\u00e7\u00f5es necess\u00e1rias para cumprir seu papel. Qualquer outra a\u00e7\u00e3o deve ser removida completamente ou movida para outro lugar (caso possa ser usada por outra Classe no futuro).<\/li>\n\n\n\n
          • Benef\u00edcio:<\/strong> C\u00f3digo mais expressivo, menor acoplamento e implementa\u00e7\u00f5es muito mais simples.<\/li>\n<\/ul>\n\n\n\n
            \n\n\n\n

            5. D \u2014 Dependency Inversion (Invers\u00e3o de Depend\u00eancia)<\/h2>\n\n\n\n
            \n

            “Dependa de abstra\u00e7\u00f5es, n\u00e3o de implementa\u00e7\u00f5es.”<\/em><\/p>\n<\/blockquote>\n\n\n\n

            \"\"<\/figure>\n\n\n\n
              \n
            • A Ideia:<\/strong> C\u00f3digo de alto n\u00edvel (regras de neg\u00f3cio) n\u00e3o deve conhecer detalhes de baixo n\u00edvel. (bancos de dados, APIs externas). Ambos devem depender de interfaces.<\/li>\n\n\n\n
            • A Pr\u00e1tica:<\/strong> Sua regra de neg\u00f3cio n\u00e3o deve criar o objeto do banco de dados. Ela deve receber<\/strong> um objeto que respeite uma interface (Inje\u00e7\u00e3o de Depend\u00eancia). N\u00e3o importa se o banco \u00e9 MySQL ou MongoDB, a regra de neg\u00f3cio permanece a mesma.<\/li>\n\n\n\n
            • Benef\u00edcio:<\/strong> Facilidade extrema para trocar tecnologias e realizar testes unit\u00e1rios (facilita o uso de Mocks<\/em>), menor acoplamento.<\/li>\n<\/ul>\n\n\n\n
              \n\n\n\n

              Como os princ\u00edpios se conectam<\/h2>\n\n\n\n

              Os princ\u00edpios SOLID n\u00e3o funcionam isoladamente.<\/p>\n\n\n\n

                \n
              • S e I<\/strong> mant\u00eam o c\u00f3digo pequeno e com prop\u00f3sito claro.<\/li>\n\n\n\n
              • O e D<\/strong> permitem que o sistema cres\u00e7a sem precisar de “cirurgias” no c\u00f3digo antigo.<\/li>\n\n\n\n
              • L<\/strong> garante que as abstra\u00e7\u00f5es sejam seguras.<\/li>\n<\/ul>\n\n\n\n

                Juntos, eles combatem o crescimento desordenado do sistema.<\/p>\n\n\n\n

                \n\n\n\n

                Um erro comum ao aprender SOLID<\/h2>\n\n\n\n

                Tentar aplicar todos os princ\u00edpios desde o primeiro dia. SOLID n\u00e3o \u00e9 sobre perfei\u00e7\u00e3o. \u00c9 sobre dire\u00e7\u00e3o. <\/p>\n\n\n\n

                O SOLID serve para combater a complexidade<\/strong>, n\u00e3o para cri\u00e1-la. Comece simples (S), entenda as interfaces (I) e, conforme o sistema crescer, aplique os demais para organizar a estrutura.<\/p>\n\n\n\n

                Aplicar um pouco melhor hoje j\u00e1 reduz a d\u00edvida de amanh\u00e3.<\/p>\n\n\n\n

                \n\n\n\n

                Ordem sugerida para ensino ou aprendizado<\/h2>\n\n\n\n
                  \n
                1. Comece pelo S<\/li>\n\n\n\n
                2. Avance para o I<\/li>\n\n\n\n
                3. Introduza O e D com exemplos reais<\/li>\n\n\n\n
                4. Apresente L depois que heran\u00e7a fizer sentido<\/li>\n<\/ol>\n\n\n\n

                  Essa progress\u00e3o costuma ser mais natural e menos abstrata.<\/p>\n\n\n\n

                  \n\n\n\n

                  Conclus\u00e3o<\/h2>\n\n\n\n

                  SOLID n\u00e3o \u00e9 sobre escrever mais<\/em> c\u00f3digo, \u00e9 sobre escrever c\u00f3digo que resiste ao tempo<\/strong>. Quando bem aplicado, o ato de alterar um sistema deixa de ser um evento perigoso e passa a ser uma tarefa rotineira e segura.<\/p>\n\n\n\n

                  \n

                  “E tu? Qual destes princ\u00edpios achas mais dif\u00edcil de aplicar no dia a dia? Partilha a tua experi\u00eancia nos coment\u00e1rios!”<\/em><\/p>\n<\/blockquote>\n","protected":false},"excerpt":{"rendered":"

                  Se voc\u00ea j\u00e1 escreve c\u00f3digo orientado a objetos, em algum momento vai ouvir algu\u00e9m falar de SOLID. Normalmente vem como um nome meio misterioso, que parece coisa avan\u00e7ada demais. Na…<\/p>\n","protected":false},"author":1,"featured_media":708,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[18,94],"class_list":["post-671","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engenharia-de-software","tag-boas-praticas-de-engenharia","tag-solid"],"aioseo_notices":[],"featured":false,"read_time":6,"_links":{"self":[{"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/posts\/671","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/comments?post=671"}],"version-history":[{"count":19,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/posts\/671\/revisions"}],"predecessor-version":[{"id":705,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/posts\/671\/revisions\/705"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/media\/708"}],"wp:attachment":[{"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/media?parent=671"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/categories?post=671"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cahfelix.tech\/blog\/wp-json\/wp\/v2\/tags?post=671"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}