O que é coesão lógica e por que é ruim ou indesejável?

Na página da c2wiki sobre acoplamento e coesão :

Nomes de força / nível de coesão (interdependência dentro do módulo): (de pior para melhor, alta coesão é boa)

• Coesão Coincidental: (Pior) Os elementos do módulo não estão relacionados
• Coesão lógica: os elementos realizam atividades semelhantes às selecionadas no módulo externo, ou seja, por um sinalizador que seleciona a operação a ser executada (consulte também CommandObject). ou seja, o corpo da função é um sinalizador if-else / importante na operação
• Coesão Temporal: operações relacionadas apenas pelo tempo geral executado (ou seja, inicialização () ou FatalErrorShutdown? ())
• Coesão processual: elementos envolvidos em atividades diferentes, mas seqüenciais, cada um com dados diferentes (geralmente podem ser divididos trivialmente em vários módulos ao longo dos limites lineares da sequência)
• Coesão comunicacional: operações não relacionadas, exceto que precisam dos mesmos dados ou entrada
• Coesão sequencial: operações nos mesmos dados em ordem significativa; a saída de uma função é inserida na próxima (pipeline)
• Coesão Informacional: um módulo executa várias ações, cada uma com seu próprio ponto de entrada, com código independente para cada ação, todas executadas na mesma estrutura de dados. Essencialmente, uma implementação de um tipo de dados abstrato. ou seja, defina a estrutura da tabela de vendas_region e seus operadores: init_table (), update_table (), print_table ()
• Coesão funcional: todos os elementos contribuem para uma única tarefa bem definida, ou seja, uma função que executa exatamente uma operação get_engine_temperature (), add_sales_tax ()

(ênfase minha).

Não compreendo completamente a definição de coesão lógica. Minhas perguntas são:

• o que é coesão lógica?
• Por que o rap é tão ruim (o segundo pior tipo de coesão)?

A coesão lógica pode ser ruim porque você acaba agrupando a funcionalidade por características técnicas e não por características funcionais. Por exemplo, considere um aplicativo que consiste em vários módulos. Cada módulo representa algum domínio comercial e possui código de acesso a dados correspondente. Se você agrupar todos os códigos de acesso a dados em todos os módulos, terá coesão lógica. Afinal, é tudo acesso a dados e, em alguns casos, é benéfico poder avaliar os padrões de acesso a dados de um aplicativo. No entanto, isso é problemático porque o domínio comercial fornece os limites do módulo, não o domínio técnico. Ao atingir a coesão lógica, você acaba perdendo a coesão funcional. Normalmente, o domínio de negócios define uma unidade bem definida de implantação e os aspectos técnicos existem para dar suporte ao domínio de negócios.

Do modo como é descrito, eu diria que é sobre o código de acoplamento que tem alguma coesão, mas quebra a orientação do objeto.

Exemplo: cálculo da área de um polígono. Quando você coloca o cálculo do quadrado junto com o cálculo do triângulo e escolhe apenas pelo parâmetro de entrada, agrupa duas coisas logicamente pelo resultado, sem levar em conta a natureza real.

Minha opinião pessoal é que o logicaltermo foi mal escolhido e leva à confusão. Nós tendemos a pensar que isso logicalé bom. Em muitos cenários, functionalpode ser trocado logical.

Eu substituiria logicalpelo technical termo porque seu foco na parte técnica e não no (e eu quero usar a palavra logicalaqui, mas será enganoso no contexto desta discussão) o que esse componente faz para todo o sistema.

Um exemplo típico pode ser o agrupamento de classes que fornecem pontos de extremidade para alguma API.
Se você agrupá-los em alguma pasta porque eles fornecem pontos finais, é a technical cohesion. Se você os agrupar porque eles oferecem alguma funcionalidade (como a lista de usuários de gerenciamento, por exemplo), é umafunctional cohesion

Além disso, eu também desafiaria o functionaltermo aqui porque é muito amplo. Ele pode se referir à função como construção de sintaxe, bem como à funcionalidade de uma coisa. No exemplo acima, uma classe de terminal tem 2 funcionalidades: terminal e lógica de negócios.

Eu substituiria functionalpara logical. Refere business logic-se ao logical viewmodelo de visualização de software 4 + 1 e, geralmente, temos a tendência de chamar as coisas de "lógicas" quando estão certas.