Um dos principios ageis e a resposta rapida a mudanca, porem muitas vezes o sistema encontra-se tao acoplado que nao conseguimos dar uma resposta rapida a mudanca solicitada e em consequencia a isso ferimos um dos quatro valores do XP, "Coragem", pois nao vamos querer mexer no que esta funcionando, para garantir o que esta funcionando vamos copiar, colar e dar uma alterada no que precisamos, muito bem voce conseguiu atender rapido a solicitacao do teu cliente, porem acaba de criar um debito tecnico no projeto, e como tal em algum momento ele sera cobrado e os juros cobrados serao bastante altos pode ter certeza.Pois bem, o que fazer entao? Utilizar boas praticas de desenvolvimento de software (sei que na moiraria das vezes a pressao pela entrega e tanta, que as boas praticas que se %$%$@%$**(@#, mas garanto a voces elas podem nos salvar de problemas muitas vezes impossiveis de resolver), o beneficios de um codigo limpo e organizado, com baixas dependencias fara com que voce abrace a mudanca, e com certeza nao vai te faltar coragem quando a proxima solicitacao do cliente chegar (aquelas mudancas que mudam tudo que se tinha pensado). Os principios SOLID de desenvolvimento foram introduzidos por Robert C. Martin, sao cinco principios que podem nos auxiliar a desenvolver um projeto orientado a objetos bastante robusto e faram com que possamos alcancar os beneficios sitados anteriormente. Principios SOLIDS - Silge Responsability Principle (Responsabilidade Unica)O - Open Close PrincipleL - Liskov Substitution PrincipleI - Interface Segregation PrincipleD - Dependency Inversion PrincipleVou fazer um breve resumo de Silge Responsability Principle e Open Close Principle, e depois apresentar um exemplo onde possamos ver na pratica um pouco de cada um.1. Silge Responsability Principle (Responsabilidade Unica)Todas as classes do nosso sistema devem ter um unica responsabilidade, pois elas nao podem ter mais de uma razao para existir. Porque cada responsabilidade a mais que a classe venha a ter pode se tornar um eixo de mudanca, tornando essas responsabilidades acopladas. Muitas vezes alteracoes em uma das responsabilidades pode impactar ou inutilizar a outra, tornando assim nosso projeto fragil e dificil de dar manutencao. O principio da responsabilidade unica e extremamente simples, porem na pratica e um dos mais dificeis de implementar, definir o principio como fiz anteriormente e algo natural e simples de fazer, porem implementa-lo vai alem de um simples projeto de software orientado a objetos, temos que entender os conceitos do dominio para podermos criar os nossos objetos com uma unica responsabilidade.2. Open Close Principle(Aberto e Fechado)Quando uma mudanca em um sistema resulta em uma cascata de mudancas em modulos dependentes, o projeto do sistema possui caracteristicas indesejaveis. A cascata de alteracoes torna o sistema mais fragil e torna suas partes mais dificeis de reutilizar O principio open-closed sugere que se construam classes quenunca mudem. Quando os requisitos mudarem, o comportamento das classes deve ser estendido pela adicao de codigo novo, nao pela alteracao do codigo existente.Estudo de Caso:(Esse exemplo foi pego de um teste que um amigo meu recebeu para entrar em um empresa)Em um sistema de ingressos de um