APS - Arquitetura-Software - SOLID

Prévia do material em texto

Universidade Salvador - UNIFACS
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ELISEU REUEL DOS SANTOS SENA
205182020
Salvador
2020
APS - Arquitetura de Software
Prof. Galdir Reges
 O SOLID são 5 princípios de boas práticas de programação e design de software 
orientada a objetos que não são exclusivas de nenhuma linguagem de programação. Foi 
apresentado pela primeira vez pelo Engenheiro de Software muito conhecido por ser o 
fundador do Manifesto Ágil Robert Cecil Martin coloquialmente chamado de ‘‘Uncle Bob’’, em 
2000 no livro cujo título em tradução livre é, ‘‘Postulados de Projeto e Padrões de Projeto’’. 
Tempo depois do livro de Uncle Bob ter sido publicado, Michael Feathers observou que os 5 
princípios criados por Martin, poderiam virar o SOLID. 
 Dentre os 5 princípios começaremos abordando o primeiro, representado pela letra ’’S’’ 
que significa a sigla ‘‘SPR’’ ou ‘‘Single Responsibility Principle’’ traduzido para o português, 
‘’Princípio de única responsabilidade’’. Esse primeiro princípio nos diz que a classe só deve ter 
um único motivo para mudar e que deve ser especialista em um único assunto possuindo 
somente uma responsabilidade dentro do software. Normalmente ao desenvolvermos 
softwares caímos no erro de desenvolver classes que têm muitas tarefas, chamadas no 
mundo do desenvolvimento de ‘’God Class’’ ou em português ‘‘Classe Deus’’. A princípio pode 
se mostrar como um software eficiente e organizado por não ser subdividido em diversas 
classes, mas a longo prazo em caso de necessidade de alteração de alguma tarefa dentro 
dessa classe teremos dificuldade em modificar sem comprometer as outras tarefas. Sendo 
assim, seguindo o ‘‘Princípio de única responsabilidade’’ evitaremos a dificuldade na 
manutenção de classes no desenvolvimento de softwares.
 O segundo princípio representado pela letra ‘‘O’’ que significa a sigla ‘‘OCP’’ ou 
‘‘Open/Closed Principle’’ traduzido para o português, ‘‘Princípio de aberto e fechado’’. Esse 
princípio nos informa que os objetos de uma entidade devem estar abertos para extensões e 
fechados para modificações, ou seja, quando criamos um novo recurso no nosso software 
devemos extende-lo e não modificar o código fonte original para evitar ‘‘bugs’’ em um software 
que já funcionava perfeitamente.
 O terceiro princípio é representado pela letra ‘’L’’ que significa ‘‘LSP’’ ou ‘‘Liskov 
Substitution Principle’’ traduzido para o português, ‘‘Princípio da Substituição de Liskov’’. Foi 
um princípio que foi introduzido em 1987 por ‘‘Bárbara Liskov’’ que diz que uma classe 
derivada deve ser substituível por sua base.
 O quarto princípio é representado pela letra ‘‘I’’ que significa ‘‘ISP’’ ou ‘‘Interface 
Segregation Principle’’ traduzido para o português, ‘‘Princípio da segregação de Interface’’. 
Ela nos diz que uma classe não deve ser forçada a implementar interfaces e métodos que não 
iremos utilizar, ou seja, sendo melhor criar interfaces mais específicas para que não tenhamos 
classes muito genéricas.
 O quinto e último princípio é reprensentado pela letra ‘‘D’’ que significa sigla ‘‘DIP’’ ou 
’’Dependency Inversion Principle’’ no português ‘‘Princípio da Inversão de Dependência’’. Ela 
nos diz que devemos depender de abstrações e não de implementações. Como uma das boas 
práticas de desenvolvimento de softwares é o baixo acoplamento o quinto nos mostra que 
módulos de alto nível não devem depender de módulos de baixo nível e sim ambos devem 
depender de abstrações.
 
 
APS - Arquitetura de Software
	Página 1
	Página 2