SOLID
Single Responsibility Principle (SRP), ou, Princípio da Responsabilidade Única. Esse princípio diz que as classes devem ser coesas, ou seja, terem uma única responsabilidade. Classes assim tendem a ser mais reutilizáveis, mais simples, e propagam menos mudanças para o resto do sistema.
Open Closed Principle (OCP), ou Princípio do Aberto Fechado. Diz que as classes devem poder ter seu comportamento facilmente estendidas quando necessário, por meio de herança, interface e composição. Ao mesmo tempo, não deve ser necessário abrir a própria classe para realizar pequenas mudanças. No fim, o princípio diz que devemos ter boas abstrações espalhadas pelo sistema.
Liskov Substitution Principle (LSP), ou Príncipio da Substituição de Liskov. Esse princípio diz que precisamos ter cuidado para usar herança. Herança é um mecanismo poderoso, mas deve ser usado com parcimônia, evitando os casos de Gato-estende-Cachorro, apenas por possuírem algo em comum.
Interface Segregation Principle (ISP), ou Princípio da Segregação de Interfaces. Esse princípio diz que nossos módulos devem ser enxutos, ou seja, devem ter poucos comportamentos. Interfaces que tem muitos comportamentos geralmente acabam se espalhando por todo o sistema, dificultando manutenção.
Dependency Inversion Principle (DIP), ou Princípio da Inversão de Dependências. Esse princípio diz que devemos sempre depender de abstrações, afinal abstrações mudam menos e facilitam a mudança de comportamento e as futuras evoluções do código.
a) (ERRADA) O SRP visa baixar o acoplamento entre classes e separar responsabilidades como forma de melhorar o código da aplicação OO sendo desenvolvida.
b) (ERRADA) A classe UrnaEleitoral tem acoplamento alto, ou seja, tem um número pequeno de dependências e, portanto, fica mais sujeita a mudanças em decorrência de alterações em outras classes.
c) (ERRADA) Uma classe com um motivo para mudar possui mais de uma responsabilidade e apresentando dificuldade de manutenção, mas, por outro lado, tem maior facilidade de reúso e de coesão. (com o SRP só há um motivo para mudar a classe UrnaEleitoral: aumentar a coesão e responsabilidade única da classe)
d) (CORRETA) A classe UrnaEleitoral não apresenta uma quebra do SRP, uma vez que possui responsabilidades que deveriam ser de componentes distintos do software.
e) (ERRADA) Em um projeto com várias classes seguindo o padrão da classe UrnaEleitoral fica mais difícil manter a coesão em um nível mais baixo ou em nível de componentes, pois o software fica com uma divisão obscura de camadas.