A orientação a objetos especifica diversos conceitos, dentre...

A coesão de classes na programação orientada a objetos se refere ao princípio de que cada classe deve representar uma única entidade no domínio do problema. Isso significa que uma classe deve ter uma responsabilidade claramente definida e se concentrar em fornecer funcionalidades relacionadas a essa responsabilidade específica.

Uma classe coesa é mais legível, reutilizável e fácil de ser mantida. Ao manter as classes coesas, o código se torna mais organizado e modular. O objetivo é ter classes que sejam focadas e especializadas em uma única tarefa, facilitando a compreensão e a manutenção do sistema como um todo.

Alternativa correta: E - Deve representar uma única entidade em relação ao domínio de um problema.

Ao abordar o tema de coesão de classes dentro da Programação Orientada a Objetos (POO), estamos falando sobre o princípio de que uma classe deve ter uma única responsabilidade ou, em outras palavras, deve representar uma única entidade ou conceito do domínio do problema que estamos tentando resolver com nosso software. Isso significa que a classe deve encapsular apenas comportamentos e atributos que são coesos entre si e diretamente relacionados à entidade que ela pretende modelar.

A coesão é uma medida de quão bem os membros de uma classe (métodos, variáveis, etc.) se relacionam uns com os outros. Classes com alta coesão tendem a ser mais fáceis de manter, testar e reutilizar, pois elas têm um foco claro e não estão sobrecarregadas com responsabilidades que não são da sua conta. Por outro lado, classes com baixa coesão podem ser difíceis de entender e manter, pois fazem "demais" e têm muitas dependências.

A alternativa E é a correta porque encapsula exatamente essa ideia de que uma classe deve ter uma única responsabilidade. Isso está em conformidade com o Princípio da Responsabilidade Única, um dos cinco princípios SOLID de design de software orientado a objetos, que preconiza que uma classe deve ter um, e somente um, motivo para mudar.

As demais alternativas não são corretas porque:
A - A presença de métodos abstratos é um critério para definir uma classe como abstrata, mas não está relacionada ao conceito de coesão.
B - Implementar o maior número possível de dependências na verdade vai contra a coesão, pois pode levar a classes que tentam fazer "demais" e não têm um propósito claro.
C - Herança (obter atributos e métodos da superclasse) é um conceito em POO, mas não define diretamente a coesão da classe.
D - Encapsulamento, que é ter atributos privados e métodos públicos, é uma prática importante em POO para proteger os dados e manter o controle sobre como eles são acessados e modificados, mas isso por si só não garante coesão.

Compreender o conceito de coesão é essencial para escrever código limpo e manutenível, e é por isso que esse conceito é frequentemente testado em concursos públicos que abordam POO. Lembre-se sempre de aplicar o Princípio da Responsabilidade Única ao projetar suas classes!