É comum usar classes parciais para obter 'modularidade'?

Recentemente, encontrei uma situação em nossa base de código em que uma equipe diferente criou uma 'classe divina' contendo cerca de 800 métodos, divididos em 135 arquivos como uma classe parcial.

Eu perguntei à outra equipe sobre isso. Embora minha reação instintiva tenha sido retirá-lo da órbita, eles insistem que é um bom design, uma prática comum e que promove 'modularidade' e 'facilidade de implementação', porque os novos desenvolvedores podem usar a funcionalidade quase sem conhecer o resto. do sistema.

Isso é realmente uma prática comum ou de alguma forma uma boa idéia? Estou inclinado a tomar medidas imediatas para derrubar esta fera (ou pelo menos impedir que ela cresça ainda mais), mas estou disposto a acreditar que estou errado.

Isso não é de forma alguma uma boa idéia.

Existem classes parciais para ajudar o designer de formulários. Usá-los por qualquer outro motivo (e sem dúvida para o objetivo pretendido, mas isso é um assunto diferente) é uma má ideia, porque leva a classes inchadas que são difíceis de ler e entender.

Veja da seguinte maneira: se uma classe de deus com 800 métodos em um arquivo, onde você sabe onde está tudo, é uma coisa ruim - e eu acho que todos concordariam que é - então como uma classe de deus com 800 métodos espalhados por 135 arquivos, onde você não sabe onde tudo pode ser uma coisa boa?

Então a pergunta era:

Isso é realmente uma prática comum ou de alguma forma uma boa idéia?

Entre as respostas atualmente disponíveis, há um retumbante não . Portanto, existem poucas outras coisas em que eu poderia falar disso; até mesmo o código processual pode ser modificado e incluir tudo, menos a pia da cozinha . O que uma classe gigante dividida em parciais faz, tudo se transforma em uma grande bagunça.

No entanto, essa pergunta é um arenque vermelho para a parte crítica real do que foi esquecido; como o OP também tem o seguinte a dizer sobre a situação:

(...) Enquanto minha reação intestinal foi tirá-lo da órbita, eles insistem ...

(...) Estou inclinado a tomar medidas imediatas para derrubar esta fera (ou pelo menos impedir que ela cresça ainda mais), mas estou disposto a acreditar que estou errado.

SEGURE SEUS CAVALOS!

Isso aqui é algo que faria meu monóculo figurativamente falando cair em minha xícara figurativa de chá.

Já estive em situações semelhantes e deixe-me dizer: não caia no desejo de fazê-lo. Claro, você pode soltar o Nuke Hammer of Justice na equipe, mas antes de fazê-lo, tenha humor com o seguinte trecho de enigma:

O que acontecerá se você disser à equipe que o código deles é péssimo e não funciona ?

(... ou algo parecido, mas menos ofensivo, isso realmente não importa, porque eles ficarão ofendidos, independentemente do que você faça, se decidir aplicar força total neles)

Qual é a situação atual com a base de código? Está funcionando? Então você terá grandes problemas para explicar aos clientes que o código deles é péssimo . Quaisquer que sejam os motivos, desde que funcionem, a maioria dos clientes não se preocupa com a organização do código.

Também se coloque no lugar deles, o que eles fariam? Deixe-me diverti-lo com o seguinte resultado muito possível:

Membro da equipe nº 1: "Então esse cara está nos dizendo que estamos fazendo errado nos últimos anos."

Membro da equipe nº 2 e nº 3: "Que idiota."

Membro influente da equipe nº 4: "Não se preocupe, vou apenas para a gerência e relatar isso como um assédio".

Veja o que o membro da equipe influente nº 4 fez lá? Ele foi para a gerência e reduziu seu carma na empresa. Ele pode ser americano-italiano, dizendo a todos para não se preocuparem com isso, mas então eu seria racista sobre isso.

Pintar a equipe infratora em um canto e deixá-los admitir que fizeram errado por tanto tempo também é uma má idéia e leva à mesma coisa. Você perderá o respeito e algum carma político do escritório.

Mesmo que você tenha conseguido que várias pessoas concordassem com isso, a fim de "ensinar uma lição à equipe", lembre-se de que você está fazendo isso com pessoas razoavelmente inteligentes que aparentemente fazem algumas coisas. Uma vez que o código seja reescrito / refatorado / tratado / seja o que for e surgirem problemas, você será responsabilizado como se fosse o bombeiro-bombeiro .

Ser adversário em situações como essa é principalmente um jogo de perder / perder , pois corre o risco de se tornar um círculo vicioso de jogos de culpa. Este é um resultado subótimo para esta situação. Mesmo se você vencer, de repente você é entregue a bagunça que outra pessoa fez.

Existem outras maneiras (muito maduras)

Eu estava em uma situação semelhante uma vez, mas depois peguei uma flecha no joelho. Então, depois de um tempo com aquela repentina carreira na minha mente, consegui um livro Driving Technical Change de Terrence Ryan . Ele lista vários padrões de céticos, o tipo de pessoa que não age com base em boas idéias. É provável que todos sejam aplicáveis ​​no caso do OP:

• Os desinformados - Eles realmente não sabiam que existem outras maneiras ou simplesmente não entendiam. Os desenvolvedores juniores geralmente se enquadram nessa categoria, mas não necessariamente. (Para ser sincero: conheci desenvolvedores juniores que seriam mais brilhantes que isso.)
• The Herd - Eles conheciam técnicas melhores do que usar classes parciais, mas não sabiam que eram permitidos.
• The Cynic - Eles apenas gostam de argumentar que ter aulas parciais é melhor do que a sua ideia apenas por uma questão de argumentar. É fácil fazer isso na multidão, em vez de ficar na frente da multidão.
• The Burned - Por alguma estranha razão, eles não gostam de criar novas classes, provavelmente percebem isso muito difícil.
• The Time Crunched - Eles estão tão ocupados que não conseguem se preocupar em corrigir seu código.
• O Chefe - Eles pensam: "Bem, funciona; então, por que se preocupar?"
• The Irrational - Ok, eles são completamente loucos.

O livro continua com uma lista de estratégias e assim por diante, mas no caso do OP é uma questão de persuasão. Ir de cabeça erguida com fatos sobre o antipadrão não é suficiente.

Se for do seu interesse aumentar a qualidade do código, pelo menos ofereça à equipe infratora chances de reiterar e corrigir sua própria bagunça . Pessoalmente, eu tentava influenciá-los ouvindo e fazendo perguntas importantes, deixando-os contar sua história:

• O que exatamente a classe de Deus está fazendo?
• Eles tiveram algum problema? Eles têm algum erro? Sugira correções sãs sem pedir que elas o façam.
• Se você é um usuário dessa classe god como uma API: existem maneiras mais simples de usar o código do que usar a coisa toda? Sugira exemplos mais simples, veja como eles reagem.
• Você pode trocar alguma funcionalidade por outra, sem precisar escrever a função?
• Eles precisam de algum treinamento? Você pode convencer a gerência a fazê-lo ou almoçar sobre padrões e práticas?

... e assim por diante. Dê-lhes pequenas sugestões para que possam avançar. Leva tempo e vai precisar de alguma graxa de cotovelo no nível político do escritório, mas paciência e trabalho duro são uma virtude, certo?

A página Classes e métodos parciais do MSDN sugere duas situações para o uso de classes parciais:
1. Para dividir uma classe gigante em vários arquivos separados.
2. Ter um local para colocar o código fonte gerado automaticamente.

2 é muito usado pelo Visual studio (por exemplo, para arquivos aspx e winforms). Este é um uso razoável de classes parciais.

1 é o que sua equipe está fazendo. Eu diria que o uso de classes parciais é uma maneira perfeitamente razoável de obter modularidade quando você tem classes gigantes, mas ter classes gigantes não é razoável. Em outras palavras, ter uma classe gigante é uma má idéia, mas se você tiver uma classe gigante, classes parciais são uma boa ideia.

Embora se você puder dividir inteligentemente uma classe em arquivos separados para diferentes usuários, você não pode simplesmente dividi-la em classes separadas?

Então, no final, eles estão desenvolvendo o processo normalmente, sem nenhuma parte do POO. Eles têm um espaço para nome global com todos os métodos, variáveis ​​e outros enfeites.

Ou convencê-los de que estão fazendo errado ou dar o fora dali.

Uma classe de utilitário contém métodos que não podem ser sensivelmente combinados com outros métodos para criar uma classe. Se você tiver mais de 800 métodos, divididos em 135 arquivos, é provável que alguém tenha encontrado alguns métodos comuns ...

Só porque você tem uma classe de utilitário, não significa que você não pode ter outra classe de utilitário.

Mesmo se você tiver 800 métodos não relacionados, a solução não é uma classe grande e muitos arquivos. A solução é um espaço para nome, alguns sub-espaços para nome e muitas pequenas classes. Isso é um pouco mais trabalhoso (você precisa criar um nome para a classe e também para o método). Mas facilitará sua vida quando chegar a hora de limpar essa bagunça e, enquanto isso, facilitará o uso do intellisense (isto é, será mais fácil descobrir onde um método deve ser usado).

E não, isso não é comum (mais o número de arquivos do que o número de funções gratuitas).

Eu não gosto disso. No entanto, talvez as classes parciais fizessem sentido para os desenvolvedores durante o desenvolvimento, pois permitiam o desenvolvimento simultâneo desse grande número de métodos, especialmente se não houver muita dependência entre eles.

Outra possibilidade é que essas classes parciais tenham sido construídas para alterar uma classe principal gerada automaticamente. Se for esse o caso, não se deve tocá-los; caso contrário, o código personalizado será acionado ao gerar novamente.

Não tenho certeza de que alguém possa manter isso com facilidade sem algum estudo. Agora, se você o matar, o número de métodos não diminuirá. O número de métodos e complexidade, para mim, é o verdadeiro problema. Se os métodos realmente pertencerem à classe, ter um arquivo grande não facilitará sua vida, especialmente na manutenção. Na verdade, pode ser mais propenso a erros expor todo esse código a erros tolos, como a busca por caracteres curinga e substitua.

Portanto, tenha cuidado e justifique a decisão de matar. Além disso, considere que teste será necessário.

É perfeitamente bem do ponto de vista prático do projeto, assumindo que os 135 arquivos realmente agrupam métodos semelhantes ao que as classes tradicionais fariam. É apenas uma média de 6 métodos por arquivo. Definitivamente, não é a maneira mais popular ou tradicional de criar um projeto. Tentar mudar isso apenas criará um monte de problemas e má vontade sem nenhum benefício real. A conformidade do projeto com os padrões OO criará tantos problemas quanto ele resolver. É uma questão completamente diferente se os vários arquivos não fornecerem realmente separações significativas.

Além das respostas já apontadas, as classes parciais podem ser úteis em um design em camadas, no qual você deseja organizar a funcionalidade que corta sua hierarquia de classes em arquivos separados por camada. Isso permite que você use o Solution Explorer para navegar pela funcionalidade por camada (por organização de arquivos) e a visualização da classe para navegar pela funcionalidade por classe. Eu preferiria usar uma linguagem que suporte mixins e / ou características, mas classes parciais são uma alternativa razoável se usadas com moderação e não devem substituir o bom design da hierarquia de classes.