Os Princípios SOLID

Published in

Contexto Delimitado

8 min readAug 14, 2019

A importância dos princípios

É comum ouvir os desenvolvedores “modernos” afirmarem que “o uso de princípios atrapalha o desenvolvimento e diminui a agilidade na entrega de software”, ou ainda, que “princípios e regras são coisas do passado”. Esse tipo de pensamento é perigoso e reflete a decadência na qualidade de entrega das empresas de software na atualidade.

É preciso desconstruir esse equívoco, abrindo-se para uma posição mais assertiva. A verdade é que os princípios de design de software são o resultado de vasta pesquisa e experimentação científica, consolidados através de anos de trabalho na área da computação.

Para embasar a necessidade de princípios de cunho científico, quero citar o ponto de vista de um importante pesquisador e criador do acrônimo SOC (Separation of Concerns). Segundo DIJKSTRA (1974), “os sistemas de processamento de dados de negócios são suficientemente complicados para exigir uma separação de preocupações (SOC). A sugestão de que na área da computação ‘o pensamento científico é um luxo não aplicável’ coloca a carroça na frente dos cavalos: a bagunça em que eles estão foi causada por muito pensamento não científico.”.

Essa necessidade de um olhar científico na computação teve sua origem em 1969, nas dissertações de Christopher Strachey, o primeiro professor do departamento de Ciência da Computação da Universidade de Oxford. Segundo Strachey, citado por DIJKSTRA (1974), “a computação se tornará uma ciência muito importante. Mas, no momento, estamos em um estado de desenvolvimento muito primitivo; ainda não conhecemos os princípios básicos e precisamos aprendê-los primeiro. Se as universidades gastarem seu tempo ensinando o estado da arte, elas não descobrirão esses princípios e é certamente o que os acadêmicos devem fazer”.

É um paradoxo desconcertante: enquanto em 1969 clamava-se por princípios de desenvolvimento, hoje tenta-se ignorá-los. Mas não se engane, pois é evidente que um desenvolvimento sem princípios, na verdade, é um grande retrocesso.

Se na sua empresa o ambiente da programação parece bagunçado, seria a hora de buscar “na fonte” as soluções para uma melhor abordagem. Isso começa com a mudança comportamental de cada membro da equipe (começando por você mesmo), focando os esforços em práticas consolidadas e de origem científica, que aliás, são amplamente utilizadas pelas grandes empresas no ramo de software como Google, IBM, Microsoft entre outras.

A origem do SOLID

Este é o primeiro artigo de uma sequência, onde serão abordados os princípios de arquitetura de Robert C. Martin. O SOLID é um famoso acrônimo, formado pelas letras iniciais de cinco importantes conceitos de design de software.

A história de sua origem começa ao final da década de 1980 enquanto Robert C. Martin (conhecido como Ancle Bob, ou Tio Bob) discutia princípios de design de software com outros usuários da USENET (uma espécie de Facebook da época) com o objetivo de catalogar os mais importantes. Essa catalogação estabilizou-se somente 20 anos depois, em 2000.

No livro Clean Architecture, Martin explica que em 2004 seu amigo Michael Feathers “enviou-lhe um e-mail dizendo que, se reorganizasse os princípios de seu catálogo, as primeiras letras soletrariam a palavra SOLID (sólido em português)”. Foi neste ponto que nasceu o acrônimo.

A composição do acrônimo

Para a formulação do acrônimo foi usado um mnemônico fácil de lembrar, composto de cinco outros acrônimos. Abaixo, um brevíssimo resumo de cada um deles. Não se preocupe em entendê-los agora, pois cada um terá um artigo exclusivo na sequência de publicações.

SRP: Single Responsibility Principle

Baseado no trabalho de DIJKSTRA (1974), DEMARCO (1979), CONSTANTINE (1974), PAGE-JONES (1988) e PARNAS (1971), o Princípio da Responsabilidade Única afirma que cada módulo de software deve ter um, e apenas um, motivo para mudar.

“Se uma classe tem mais de uma responsabilidade, as responsabilidades se tornam acopladas. Mudanças em uma responsabilidade podem prejudicar ou inibir a capacidade da classe de cumprir as outras. Esse tipo de acoplamento leva a projetos frágeis que estragam de maneiras inesperadas quando alterados.” (MARTIN 2011)

OCP: Open Closed Principle

Baseado no trabalho de JACOBSON(1992) e MEYER (1988), o Princípio Aberto Fechado nos ajuda a ter classes coesas e que evoluam mais fácil. Trata-se de um conceito que objetiva a escrita de classes “abertas para extensão”, mas “fechadas para modificação”. Em outras palavras, deve ser fácil estender o comportamento de uma classe, ao mesmo tempo que ela deve ser fechada para alteração, impedindo sua modificação sempre que a regra de negócio mudar.

“Para que os sistemas de software sejam fáceis de mudar, eles devem ser projetados de modo a permitirem que o comportamento desses sistemas mude pela adição de um novo código em vez da alteração do código existente..” (MARTIN 2019)

LSP: Liskov Substitution Principle

Baseado no trabalho de LISKOV e WING (1994), o Princípio da Substituição de Liskov originou-se da famosa definição de subtipos de Barbara Liskov. Ao trabalhar com herança é preciso sempre lembrar do contrato estabelecido pela classe pai. Apesar de parecer simples, na prática não é tão fácil e exige um certo talento para organização.

Este princípio afirma que “para construir sistemas de software com partes intercambiáveis, essas partes devem aderir a um contrato que permita que essas partes sejam substituídas umas pelas outras”. (MARTIN 2019)

ISP: Interface Segregation Principle

Baseado no padrão de projeto Template Method, de GAMMA (1995), o Princípio da Segregação de Interfaces defende que quando mais coesos e especializados forem os contratos (interfaces) melhor e mais seguras serão as implementações.

Assim sendo, deve-se extinguir a implementação de métodos somente para cumprir a exigência de uma interface inchada (que geralmente estão requerendo mais implementações do que deveriam), ao contrário, deve-se criar interfaces magras, contendo apenas as assinaturas de suas especialidades. “O ISP aconselha os projetistas de software a não dependerem de coisas que não usam”. (MARTIN 2019)

DIP: Dependency Inversion Principle

Baseado no trabalho de BOOCH (1996) e PAGE-JONES (1988), o Princípio da Inversão de Dependência afirma que se uma classe for depender de outra, esta deve ser mais estável. Ou seja, se a classe A depender da classe B, B deve ser mais estável que A, de forma que as dependências entre as classes sempre sigam em direção à estabilidade, dependendo de módulos mais estáveis que ela própria.

“o código que implementa a diretiva de alto nível não deve depender do código que implementa detalhes de baixo nível” (MARTIN 2019).

Vantagens ao usar os princípios SOLID

O SOLID existe para ajudar os desenvolvedores a corrigir uma série de problemas que podem acontecer dentro da Orientação a Objetos. No artigo de Martin (Design Principles and Design Patterns), é falado muito sobre mudanças e refatoração, uma característica importantíssima para qualquer software passível de evolução.

Sistemas muito rígidos (resistentes à mudanças) dão muito trabalho na hora de evoluir. O contrário também é preocupante, em sistemas muito frágeis a simples alteração de uma parte pode quebrar outras dez em todo o sistema.

Os princípios SOLID objetivam tornar o software mais manutenível e fácil de entender. Em outras palavras, o SOLID tornará o software:

Mais organizado;
Aberto para receber melhorias;
Evolutivo: ao ser atualizado não terá efeitos colaterais indesejados;
Fácil de ser testado;
Menos propenso a repetição de código;
Fácil de ter seus módulos reaproveitados.

O contrário também deve ser considerado, ou seja, sistemas onde os princípios SOLID não são observados tendem a:

Possuir código sem padrão, desorganizado e macarrônico;
Possuir classes inchadas, com explosão de métodos e difíceis de entender;
Ser muito rígidos em algumas partes, dificultando as mudanças;
Ser muito frágeis, quebrando outras partes do sistema com facilidade;
Ter muito código repetido ao longo do sistema;
Ser muito difíceis de testar.

Conclusão

É muito fácil construir código ruim, principalmente ao usar o paradigma de Orientação a Objetos sem conhecimento suficiente.

Por esse motivo, pessoas como Robert C. Martin, Michael Feathers, Bárbara Liskov e tantos outros (que tiveram desafios nesta área) elaboraram soluções para seus próprios problemas e compartilharam suas experiências para ajudar outras pessoas e tornarem o desenvolvimento de software menos penoso.

Não são regras absolutas, mas grandes receitas de sucesso, técnicas que deram certo e continuam dando para aqueles que compreendem de verdade essas preciosas informações.

No campo do desenvolvimento de software, é imprescindível que o profissional busque conhecer cada vez mais sobre as maneiras de fazer um software cada vez melhor e mais profissional, pensando não apenas em si mesmo, mas nos outros programadores que poderão entrar em contato com seu código e trabalhar na próxima evolução do programa.

Nos próximos artigos vou escrever sobre todos os princípios SOLID de forma mais abrangente e tentar desmistificar o que cada um deles significa de fato. Espero que o conteúdo tenha sido útil até agora. Um grande abraço e até a próxima!

O DNA do Software Sólido

O primeiro passo em direção a solução é ter consciência do problema. Por isso é muito importante identificá-los o…

medium.com

Leia todos os artigos desta série:

Referências para Aprofundamento

ANICHE, Maurício. Orientação a Objetos e SOLID para ninjas. São Paulo, SP, Brasil. Casa do Código, 1998.

CONSTANTINE, Larry L. Structured design. IBM Systems Journal, VOL13, NO 2, 1974.

DEMARCO, Tom. Structured Analysis and System Specification, Press Computing Series, Yourdon, 1979.

DIJKSTRA, Edsger W. On the role of scientific thought. Burroughs Research Fellow, Netherlands, 1974.

GAMMA et all. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995.

BOOCH, Grady. Object Solutions, Addison Wesley, 1996;

JACOBSON, Ivar. Object Oriented Software Engineering a Use Case Driven Approach, Addison Wesley, 1992.

LISKOV, Barbara; WING, Jeannette. A behavior notion of subtyping. Laboratory for Computer Science, Massachusetts Institute of Technology MIT, Cambridge, MA, 1994. Disponível em <https://www.cs.cmu.edu/~wing/publications/LiskovWing94.pdf>. Acesso em 03/08/2019.

MARTIN, Robert. Design Principles and Design Patterns. Disponível em <https://fi.ort.edu.uy/innovaportal/file/2032/1/design_principles.pdf>. Acesso em 03/08/2019.

MARTIN, Robert C. Princípios, Padrões e Práticas Ágeis em C#. Bookman, Porto Alegre, RS, 2011.

MARTIN, Robert C. Arquitetura Limpa: O guia do artesão para estrutura e design de software. Alta Books Editora, 2019.

MEYER, Bertrand. Object-Oriented Software Construction. Prentice Hall, 1988.

PAGE-JONES, Meilir. The Practical Guide to Structured Systems Design, 2d. ed., Yourdon Press Computing Series, 1988.

PARNAS, David L. On the Criteria To Be Used in Decomposing Systems into Modules. Carnegie-Mellon University, 1971

Principles Wiki. Disponível em <http://www.principles-wiki.net/collections:robert_c._martin_s_principle_collection>. Acesso em 02/08/2019.