Questão 770086

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2012
• Provas: CESPE - 2012 - Banco da Amazônia - Técnico Científico - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Acoplamento e Coesão

Acerca de coesão e acoplamento, elementos críticos para o
desenvolvimento e manutenção de sistemas, julgue os itens que se
seguem.

De acordo com o princípio da coesão de classes, cada classe deve representar uma única entidade bem definida no domínio do problema. O grau de coesão diminui com o aumento contínuo de código de manutenção nas classes.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Essa questão está errada.
  Quando se fala em domínio do problema, está se falando da análise do problema, que, quando for feito projeto da solução, uma entidade poderá virar mais de uma classe. Portanto, uma entidade pode ser representada por mais de uma classe.
  
  Outro problema é que o grau de coesão não dimiuirá com o aumento contínuo de código de manutenção nas classes. Já pensou, a cada refactoring na classe a sua coesão diminuirá. CESPE pirou nesta questão.
• CERTO
  coesão pode se dizer de forma bruta quase o oposto de acoplamento.
• Pelo que pesquisei sobre coesão de classes, a definição mais sucinta que encontrei foi:
   
  Coesão é o quanto as tarefas que uma classe deve realizar estão relacionadas com um mesmo conceito. Por exemplo, uma classe ContaCorrente deve ser apenas atributos como Saldo e métodos Sacar e Depositar. 
  Baixa coesão é uma classe que realiza mais de conceito. Por exemplo, a classe Cliente tem os atributos cadastrais (nome, endereco, sexo) e inclui nela rotinas como fazerEmprestimo, realizarSaque.
   
  Explicito na questão e esclarecendo o comentário do colega: Acoplamento é quanto um elemento (classe, método, atributo) depende e conhece do outro. Elementos muito acoplados geralmente são muito dependentes, mudou um e você com certeza vai ter que mudar o outro.
• Concordo com o BACEN, se tiver que criar mais código para aumentar a coesão, criaríamos programas imensos sem nexos. Isso vai de encontro às definições de Refactoring, como o olcega Bacen já falou.
• Questão confusa e subjetiva.
  
  Mas a palavra manutenção mata a questão, pois o principal objetivo da coesão é facilitar ou reduzir a manutenção, então se estamos escrevendo um código que exigirá uma maior manutenção, é MUITO provável que estejamos diminuindo sua coesão.
  O chato é que não dá pra afirmar 100% que o problema do aumento de manutenção seja falta de coesão, mas não invalida a questão.

• Ao meu entender, a definição de coesão esta correta: cada classe deve ter atributos e métodos de seu próprio domínio (classe Cliente não tem domínio da ContaCorrente, conforme comentário anterior). Domínio aqui significa o contexto em que essa aplicação esta inserida, não apenas como uma fase de análise na ES.

  Embora uma entidade possa ser representada por mais de uma classe, isso não é recomendável. Você terá código duplicado em classes diferentes (caso não use de herança/polimorfismo), o que aumenta o acoplamento entre esses objetos. Mantendo o exemplo anterior, uma entidade "Cliente" pode ser representada pelas classes Cliente e ClienteResidencial. Ambos representam o domínio de informações de um cliente e caso um atributo existente nessa entidade mude seu tipo de boolean para int, por exemplo, você terá que alterar duas classes ao invés de uma!

  Refatorar não é aumentar linhas de código, mas sim simplificar e melhorar código, o que muitas vezes traz a redução dessas linhas. Quanto mais o código de uma classe for coerente com o nome que carrega, mais coesa ela é.