Ola pessoal,
to com uma classe aqui, ela ta com ~3000 linhas (nao sei se isso pode ser considerado grande)… enfim, gostaria que vcs me dessem links de onde posso arrumar material de leitura sobre como identificar qdo minha classes esta fazendo “coisas demais”, e técnicas pra dividir essas responsabilidades…
vlw 
Eu recomendaria a leitura do livro Refatoração, do Martin Fowler e de algum material sobre Design Patterns.
Pelo menos, com essas coisas, você pode avaliar o grau de coesão de sua classe e ver se ela não está fazendo coisas demais.
Se sua classe for um mediator, entretanto, isso pode estar certo. É comum que classes que implementam esse padrão fiquem grandes, como o próprio livro do grupo dos quatro ressalta.
Uhm… na verdade as técnicas destes livros aumentam as me´tricas mas não ensinam exatamente como evitar estes problemas. Dois Livros:
Mas como dica rápida sua classe provavelmente está fazendo coisas a mais do que deveria. Uma classe deve modelar um conceito e colaborar com outras que modelam outros conceitos. Não exist eum número de linhas ideal nem um bom ou ruim mas quando sua classe atinge um número tão grande provavelmente é um erro de projeto.
Um professor meu me dizia que se um método tem mais de 30 linhas é pra olhar com desconfiança pra ele… veja se não existe muito código repetido e se ele faz exatamente a função a qual da o nome.
Se você tiver uma classe Carro e tiver algo relacionado com avião por exemplo… alguma coisa deve estar errada
Ricardo Cabral
Esse projeto foi feito em camadas?
Segue processo de desenvolvimento ou mta gente colocou a mao nele?
Tem que ver se tem codigo replicado, se tem mto bloco condicional desnecessario, se foi feito tudo em uma unica classe qnd poderia ter sido feito em camadas… conceitos de heranca… tem tanta coisa que vc mesmo pode estar analisando e limpando…
Se for so essa classe, e’ mais tranquilo… se isso acontecer em boa parte do projeto e’ q vai ser mais trabalhoso…
O ideal e’ planejar tudo antes de iniciar o projeto, mta gente ignora os processos, eng. de sw, uml… e acaba esquecendo de reusabilidade, manutencao…
Umm… mas é como o pcalçado disse provavelmente deve ser erro de projeto…
É o seguinte… essa classe faz a “sincronização” entre uma base de dados local e o servidor… essa parafernalha toda é pelo motivo de que, nao sei porque raios, o cliente precisa que ela trabalhe offline e online…
Antes quem me digam que existem APIS de sincronização… O servidor é Oracle e os clientes sao Firebird… se mesmo assim tiver API pra isso aí seria bom mesmo =)
Ela faz o seguinte: fica olhando a tabela pra ver se tem alguma requisicao pra fazer (consulta, inclusao, alteração) … se tiver, e houver conexão disponivel (segundo o argumetno deles as delegacias vao estar em areas bem remotas, onde nem velox xega, onde entraria um Mini-Modem GSM da Oi) conecta no servidor, faz o q deve fazer (usando SP’s), e dependendo do tipo da mensagem vai fazer algo aqui ainda (ex: consulta)…
Ou seja ta osso dividir essas responsabilidades… eu só sei que nao estou gostando do que to vendo ta muito grande e noa to conseguindo dividir e melhorar isso… daí pedi a galera pra me ajudar com livros e links, pra eu abrir minha cabeça 
respondendo ao agogear - Sim, o sistema e feito em camadas… Alumas estao boas, mas tem camada aqui que da vontade de eliminar, pq nao tem regra nenhuma so pega o objeto e passa pra DAO. Ao meu ponto de vista nem deveria existir isso…
O ‘x’ da questao esta na Orientacão a objetos.
Se voce fizer uma boa OO sua classe vai ficar mais enxuta.
[quote=pcalcado]Uhm… na verdade as técnicas destes livros aumentam as me´tricas mas não ensinam exatamente como evitar estes problemas. Dois Livros:
[/quote]
Não concordo totalmente. Considero não tanto o catálogo, mas os primeiros capítulos do livro Retoração como os mais importantes.
Ali o autor deixa claro a preocupação e a filosofia por traz de refatorar, dividir e separar o código, de modo a deixa-lo mais modular, limpo e menos acoplado.
Na verdade, o livro propõe a troca (ou o complemento) da abordagem “up-down” para a “bottom-up” para o projeto. Ou seja, ele propõe que também é possível, de maneira um tanto kaizen, sair de um código rebuscado e chegar num código e projeto de qualidade.
Também concordo que isso não é 100% verdade. Cedo ou tarde, você deve quebrar a premissa de que “refatoração não afeta as interfaces” e partir para uma modelagem. Aliás, algumas refatorações em si quebram essa premissa, tão bem explicada no início do livro.
Mas no caso do colega, que já tem um código pronto, muitas vezes é muito interessante começar limpando a casa, refatorando, para depois partir para um projeto de classes e mais elegante.
A questão é difícil. Em termos do que é melhor? Talvez seja conhecer as duas abordagens. São métodos complementares e não excludentes e, portanto, ambos devem ser respeitados.
Eu considero complementares porque, você pode até saber projetar bem, mas nem sempre terá o conhecimento suficiente para fazer isso no início. Nesse caso, é melhor partir logo para um projeto menos eficiente e aprimora-lo através de refatorações, padrões e afins. Por outro lado, mais você também deve saber qual refatoração usar e quando, por exemplo, deve começar a dividir uma classe ou utilizar um padrão. E isso, só o conhecimento sistemico é capaz de te fornecer.