Programação OO e Java

Prof. Fernando Anselmo

S.O.L.I.D.
São cinco princı́pios com base na Orientação a Objetos que facilitam no desenvolvimento de
softwares e o design de software, torna o projeto mais fácil de manter e estender. A metodologia
foi formulada para proporcionar o desenvolvimento de software mais compreensı́vel, flexı́vel e
manutenı́vel, especialmente em projetos que consideram como base a programação orientada a
objetos (POO).

Os princı́pios foram idealizados por Robert C. Martin, também conhecido como ”Uncle Bob”,
um renomado engenheiro de software e autor do artigo The Principles of OOD.

Já o termo foi cunhado por Michael Feathers como um acrônimo mnemônico para facilitar a
recordação dos cinco princı́pios que foram elaborados como um guia para que os desenvolvedores
evitem certas armadilhas ao projetar um software, tais como rigidez, fragilidade e imobilidade.

Ao longo dos anos, a adoção dos princı́pios SOLID tem sido amplamente recomendada na comunidade
de desenvolvimento de software como um padrão para a construção de sistemas orientados a objetos
coesos e desacoplados. Os princı́pios SOLID têm suas raı́zes no livro ”Design Patterns: Elements of
Reusable Object-Oriented Software”revolucionário de 1994, e foram explicitamente formulados por
Martin em seu trabalho seminais de 2000. Desde então, eles se tornaram parte integrante do ensino
de POO e práticas recomendadas dentro da indústria de software.

Princı́pio da Responsabilidade Única

SRP, do inglês Single Responsibility Principle é um dos cinco princı́pios básicos da programação
orientada a objetos e design de software propostos pelo SOLID. Sugere que uma classe deve ter
apenas uma razão para mudar:

ˆ Foco em uma tarefa ou responsabilidade: Cada classe ou módulo deve ser responsável
por uma parte claramente definida da funcionalidade fornecida pelo software. Isso significa
que a classe deve executar uma única tarefa ou ter uma única preocupação.
ˆ Redução de complexidade: Ao limitar uma classe a uma única responsabilidade, o design
do software é simplificado, tornando-o mais fácil de entender, manter e modificar. Isso também
facilita a identificação de componentes que podem ser reutilizados em diferentes partes do
sistema.
ˆ Facilidade de manutenção e atualização: Quando uma classe tem apenas uma responsa-
bilidade, há menos possibilidades de erros durante a manutenção ou atualizações. Alterações
em uma parte especı́fica do código afetarão apenas aquelas classes com a responsabilidade
relacionada, diminuindo o risco de efeitos colaterais indesejáveis em outras partes do código.
ˆ Testabilidade: Com o SRP, as unidades de software se tornam mais testáveis. Uma classe
com uma única responsabilidade terá menos cenários de teste necessários, facilitando a criação
de testes automatizados que são mais fáceis de escrever e entender. Isso melhora a qualidade
geral do código e a confiança de que as mudanças não introduzirão novos bugs.

Este princı́pio foca na granularidade das classes e suas responsabilidades, o objetivo final é promover
um design de sistema mais limpo, com alta coesão e baixo acoplamento.

Em 26 de fevereiro de 2024 Folha 1 de 3

 Programação OO e Java

Princı́pio Aberto/Fechado

OCP, do inglês Open/Closed Principle estabelece que as entidades de software (classes, módulos,
funções) devem estar abertas para extensão, mas fechadas para modificação:

ˆ Possibilidade de Estender o Comportamento: O princı́pio defende que devemos ser

capazes de adicionar novas funcionalidades ou comportamentos a uma classe sem alterar
o código existente. Isso tipicamente é alcançado através do uso de abstrações, herança e
composição para criar sistemas extensı́veis.
ˆ Prevenção de Modificações Diretas: O código-fonte existente não deve ser modificado
para adicionar novas funcionalidades. Isso evita que alterações diretas possam introduzir erros
em partes do sistema que já estavam funcionando corretamente.
ˆ Fomento à Reutilização de Software: Ao permitir que as classes sejam estendidas sem
alterar o código principal, encorajamos a reutilização do código. Os desenvolvedores podem
construir novas funcionalidades reutilizando e estendendo os comportamentos já existentes.
ˆ Redução de Risco em Atualizações: Quando mudanças são necessárias, adotar o princı́pio
OCP diminui o risco associado à implementação de novos requisitos ou funcionalidades. Como
os códigos existentes permanecem inalterados, há menos chance de introduzir defeitos em
partes do sistema que não estão relacionadas com a atualização.

O desenvolvedor busca criar estruturas de software mais robustas, confiáveis e manutenı́veis,

facilitando a evolução do sistema com o menor impacto possı́vel no código já existente.

Princı́pio de Substituição de Liskov

LSP, do inglês Liskov Substitution Principle formulado por Barbara Liskov em 1987, o princı́pio
aborda como os objetos devem ser substituı́veis por instâncias de seus subtipos sem afetar a exatidão
do programa:

ˆ Compatibilidade de Comportamento: Instâncias de uma classe base podem ser subs-

tituı́das por instâncias de suas subclasses sem afetar o funcionamento correto do programa.
Isso significa que as subclasses devem aderir à promessa contida no comportamento esperado
da classe base.
ˆ Preservação das Propriedades da Classe Base: Subclasses não devem violar as invariantes
e garantias estabelecidas pela classe base. Isso inclui comportamentos tais como cumprir
pré-condições e pós-condições do contrato da classe base.
ˆ Substituição sem Surpresas: A substituição de objetos de uma classe base por objetos de
subclasse deve ser feita sem surpresas negativas ou comportamentos inesperados. As subclasses
não devem exigir condições extras, enfraquecer pré-condições ou fortalecer pós-condições.
ˆ Hierarquia de Herança Saudável: O princı́pio ambienta a maneira correta de construir
uma hierarquia de herança, onde as classes derivadas estendem as classes base sem alterar a
semântica original. Isso implica que métodos de subclasses que sobrescrevem os da classe base
devem obedecer ao contrato definido pela classe base.

O design do software torna-se mais consistente e previsı́vel, permitindo que sistemas complexos
sejam mais facilmente compreendidos e mantidos. Ajuda a garantir que o código seja mais modular
e facilita a reutilização de componentes.

Em 26 de fevereiro de 2024 Folha 2 de 3

 Programação OO e Java

Princı́pio da Segregação de Interface

ISP, do inglês Interface Segregation Principle enfatiza a importância de interfaces granulares na

construção de um software modular e coeso:

ˆ Interfaces Especı́ficas em Vez de Genéricas: O princı́pio preconiza a criação de interfaces

especı́ficas para tarefas ou atores especı́ficos, em vez de uma única interface genérica que
atenda a múltiplas necessidades. Isso evita que classes cliente implementem métodos dos quais
não precisam ou não utilizam, mantendo o design limpo e coeso.
ˆ Redução de Acoplamento Indesejado: Com interfaces segregadas, os clientes não são
forçados a depender de métodos que eles não usam. Isso reduz o acoplamento desnecessário
entre diferentes partes do sistema e facilita a manutenção e a evolução do código.
ˆ Facilidade de Entendimento e Manutenção: As interfaces tornam-se mais compreensı́veis
quando estão focadas em uma tarefa clara ou em um grupo de tarefas relacionadas. Isso
confere clareza no design e torna a base de código mais fácil de trabalhar e manter.
ˆ Flexibilidade e Reusabilidade: Ao se definir interfaces múltiplas e especializadas, é possı́vel
que as classes têm maior flexibilidade e reutilizabilidade. Diferentes clientes podem aproveitar
apenas as partes da abstração que são relevantes para eles sem a sobrecarga de ter que lidar
com outras funcionalidades desnecessárias.

Criação de sistemas mais escaláveis e robustos, onde as alterações em uma parte especı́fica do código
têm menos probabilidade de afetar componentes que não são diretamente relacionados, melhorando
a manutenibilidade do sistema como um todo.

Princı́pio da Inversão de Dependência

DIP, do inglês Dependency Inversion Principle visa reduzir o acoplamento entre módulos de alto
nı́vel e de baixo nı́vel, criando um software mais flexı́vel e sustentável:

ˆ Depender de Abstrações: Módulos de alto nı́vel, que geralmente contêm a lógica de

negócio e as funcionalidades centrais do sistema, devem depender de abstrações em vez de
implementações concretas de módulos de baixo nı́vel, que tendem a ser mais detalhados e
lidam com operações especı́ficas.
ˆ Inversão do Fluxo de Controle: Tradicionalmente, o fluxo de controle de software parte
dos módulos de alto nı́vel para os de baixo nı́vel. O DIP inverte essa dinâmica, fazendo com
que os detalhes dependam das abstrações, não o contrário. Isso é frequentemente alcançado
por meio de injeção de dependências ou o uso de padrões de projeto como Factory ou Strategy.
ˆ Facilita o Teste de Software: Ao depender de abstrações, o código se torna mais fácil
de testar, visto que as dependências concretas podem ser substituı́das por mocks ou stubs
durante os testes. Isso ajuda a isolar partes do código para testá-las individualmente.
ˆ Flexibilidade e Reutilização de Código: Com o DIP, é mais fácil mudar o comportamento
das implementações sem alterar a lógica de negócios de alto nı́vel. Isso aumenta a flexibilidade
do software, permitindo que novas funcionalidades sejam adicionadas ou que as existentes
sejam alteradas com um impacto mı́nimo no restante do sistema.

Ao aplicar o Princı́pio da Inversão de Dependência, os desenvolvedores produzem sistemas mais

adaptáveis às mudanças e extensões, garantindo que o núcleo do software não seja comprometido
por dependências rı́gidas e de difı́cil manutenção.

Em 26 de fevereiro de 2024 Folha 3 de 3