Isenção de responsabilidade: Todos podem, mas o que sou pior ?!
O SOLID é um conjunto de princípios para organizar o código. De fato, eles declaram certas regras que ajudarão você a economizar os nervos e o tempo dos outros. Ou eles podem não ajudar.
Vamos tentar entender esses princípios nos dedos, sem exemplos de código e SMS.
S - Princípio da Responsabilidade Única (SRP)
Deve haver um e apenas um motivo para mudar de classe (“Uma classe deve ter apenas um motivo para mudar.” Robert C. Martin.)
Imagine que você tem cinco músicas favoritas, alguns filmes e fotos de gatos no seu computador. Você traz tudo isso para "Meus documentos" e, em geral, aproveita a vida.
Então você baixa mais filmes, um novo álbum da sua banda favorita e uma dúzia de novos gatos. Em "Meus Documentos", de alguma forma, não é confortável e você expõe tudo pelo papai.
Música
Filmes
Selos
Em seguida, conecte uma velocidade ilimitada, desça das bobinas e baixe todas as séries dos Simpsons cheias de discografias de seus grupos favoritos, e as fotos de uma viagem de pesca com os amigos são adicionadas às fotos dos gatos. Os pais começam a se ramificar.
Música
As portas
Esperando o sol
Olá, eu te amo.mp3
...
...
Rhcp
Agutin
Vídeo
Programas de TV
Filmes
Estúdio Privado
Foto
Selos
Pesca
Preferência no país
cortesãs
E o que temos aqui?
- Música - é responsável SOMENTE pela música.
- The Doors - SOMENTE responsável pela música tocada por The Doors
- Waiting for the Sun - responsável SOMENTE pelo álbum Waiting for the Sun
- Olá, eu te amo.mp3 - SOMENTE responsável pela música Olá, eu te amo
Qual poderia ser o motivo da mudança no The Doors? Apenas uma - (qualitativa ou quantitativa) mudança nas músicas de The Doors. Mas a remoção de uma série chata de "/ Video / TV Series /" não pode ser um motivo, assim como renomear "Music" para "Music".
Que conclusões podem ser tiradas?
- O SRP é sobre decomposição (classificada em subpastas) e conexão ("Olá, eu te amo.mp3" está associado apenas a "Aguardando o sol" e ela não se importa com as alterações em "../Series". Por outro lado, todas as músicas “As portas” estão dentro e não devem estar na pasta “Gatos”).
- O nível de abstração do motivo da mudança não deve ser superior ao nível de abstração da entidade que está sendo alterada. Adicionar a subpasta “Alla Pugacheva” a “Music” não pode ser, de forma alguma, o motivo da mudança de “Waiting for the Sun”.
- Não há necessidade de levar ao ponto do absurdo. Se você tiver três músicas, uma vidos e cinco fotos de gatos, elas ficarão ótimas em uma pilha - colocá-las em pastas apenas confundirá tudo. Como a coleção “The best of The Doors”, você não deve dividi-la em subpastas por ano, cada uma com uma música.
O - Princípio aberto-fechado ou OCP
As entidades de software (classes, módulos, funções etc.) devem estar abertas para extensão, mas fechadas para modificação. " Bertrand Meyer)
Vamos voltar ao passo da nossa história quando você conectou velocidade ilimitada. Digamos que, em primeiro lugar, você produziu todos os tipos de filmes sobre encanadores da produtora de filmes Private e, como eram todos sobre encanadores, criou a pasta "/ Video / About Plumbers /".
Depois de algum tempo, você baixou mais filmes deste estúdio, mas já sobre entrega de pizza. Além disso, sua nova garota escreveu para você um SMS “Eu baixei o filme“ Afonya ”e salvei na pasta / Vídeo / Sobre Encanadores /, ok?”. E tudo parece estar certo - sobre o encanamento, mas há uma nuance.
E aqui fica claro para você que alterar a funcionalidade é impossível sem modificar a estrutura existente de pastas (classes), e isso é uma clara violação do princípio do OCP.
Como nesse caso tinha que ser feito? É muito simples projetar o sistema inicialmente para que a nova funcionalidade não exija a alteração do código antigo. I.e. não codifique a pasta "../Pro encanadores /", esperando que, no futuro, exista apenas sobre eles, mas aumente o nível de abstração para "../Studio Private /" e alimente com calma os encanadores e entregadores de pizza, etc. -outro ...
E para Afoni, crie uma nova classe, por exemplo, "../Mosfilm/", expandindo a classe "/ Video /"
Conclusões:
- Pense no que você fará se outros filmes sobre encanador aparecerem. Talvez você deva fazê-lo imediatamente em sua mente para não refazê-lo mais tarde?
- Este princípio é principalmente sobre classes abstratas ("../Studio Private /").
L - Princípio de substituição de Barbara Liskov ou LSP
Os objetos no programa devem ser substituíveis por instâncias de seus subtipos sem alterar a execução correta do programa.
Bem, é bem simples.
Para uma explicação, vejamos doçura e nanniness, e especificamente para a pasta "/ Photo / Seals /".
Adoramos gatos e colecionamos muitas fotos.
Foto
Selos
Ruivas
Listrado
Molhado
Preto
Manula Acontece que lançamos uma apresentação de slides diretamente em toda a pasta raiz e a admiramos. E assim, em um belo momento, quando você quase alcançou o nirvana, a tela exibe:
Não foi possível exibir o arquivo "/ Photo / Seals / Books / Puss in Boots.fb2"
Como se viu mais tarde, seu amigo decidiu aumentar o grau de fofura e herdou os “Selos” com uma nova subpasta do “Livro”, por ter violado gravemente o LSP, já que a subclasse “Livros” não pode ser usada no lugar da classe base “Foto”.
Conclusões:
- O nome é assustador, a definição é complexa, mas o princípio em si é simples e intuitivo.
- Se seu método espera que "Photo" entre, não importa qual herdeiro de "Photo" você o escorregou: "Manuli", "Redheads" ou "Wet", mas se "Books" aparecer, então esperava-se que ele engasgasse com o chá.
I - Princípio de Segregação de Interface ou ISP
Os clientes não devem depender de métodos que eles não usam.
Aqui será difícil explicar com pastas e arquivos, mas vou tentar - não julgue estritamente por alguma tensão.
Você está cansado do music player padrão e decidiu fazer o download de um novo, moderno e hype. Ele até sabe como exibir a capa de um álbum de música e exibir legendas de uma música executada. Mas o problema é que, se os arquivos “cover.jpg” e “subtitles.txt” não estiverem na pasta do álbum, o player trava com um erro. E agora, amaldiçoando tudo no mundo, você começa a criar esses arquivos stub em todas as subpastas com álbuns.
Ou seja, desenhando analogias incorretas, obrigamos a classe Music e todos os seus herdeiros a implementar a interface AudioCoverSubtitles. Ao mesmo tempo, essa interface implementa completamente apenas o álbum "Waiting for the Sun", o álbum "The best of The Doors" implementa apenas a parte "Audio + Cover" e o restante apenas "Audio".
Isso nos leva à idéia de que faz sentido dividir a interface grossa do AudioCoverSubtitles em três pequenos áudio, capa e legendas e usá-los somente onde realmente são necessários.
Conclusões:
- De repente, o ISP trata da separação de interfaces.
- Se sua interface obriga a criar métodos de stub, essa é uma interface ruim e você deve revisá-la com uma tesoura.
D - princípio de inversão de dependência ou DIP
Os módulos de nível superior não devem depender dos módulos de nível inferior. Ambos os tipos de módulos devem depender de abstrações.
As abstrações não devem depender dos detalhes. Os detalhes devem depender de abstrações.
O módulo “Doors” não deve depender do tipo de arquivo de áudio que ele contém, .mp3, .flac ou .wav.
O módulo Doors, seu submódulo Waiting for the Sun (e todos os outros), depende da abstração de nível superior do Music, que determina sua implementação (o fato de que eles têm música dentro).
Suponha que decidimos separar o armazenamento da música de acordo com o princípio da compactação - "com perdas" e "sem perdas". Esses são os detalhes que a dependência da abstração "Música" combina - neles, em última análise, ainda deve haver música. Além disso, a abstração "Música" em si não depende desses detalhes. Ela não se importa se a música está perdida lá ou sem eles - como era música, continua assim.
Conclusões:
- DIP - é sobre isso, o particular deve depender do geral, e não vice-versa.
- DIP é "Mais abstrações para o deus das abstrações!"
- O DIP também trata de causas e efeitos, da resposta correta à pergunta: "Os galhos oscilam pelo fato de o vento soprar ou o vento sopra pelo fato de os galhos balançarem"
Obrigado e tenha um bom final de semana!