COMO SABER OS MODULOS NECESSARIOS
Algo que facilitaria um pouco é saber quais módulos um Form (ou outro Módulo) precisa. Existe alguma forma de tornar isso explÃcito no código? Quem sabe um comando Load, Link, Uses (esse é do Delphi) ou algo parecido.
Alguém sabe se existe isso no VB6?
Obrigado.
Caso não seja possÃvel Reorganizar os módulos, para serem independentes, a única saÃda seria a documentação, outra coisa fundamental e que quase ninguém faz.
Documenta os vÃnculos, assim saberá.
Citação::
JALEXM é um problema sério de planejamento, não sei se o projeto é seu, mas o certo mesmo seria cada módulo ser independente, e lógico você poderia ter um módulo global para as variáveis que são usadas em todos outros.
Não acho que exista um problema de planejamento. Pelo contrário.
Para fazer o que você e o amigo Luis Herrera sugerem, eu teria que remover para módulos separados todas as funções de um módulo que fizessem referências a outros módulos.
Isso é totalmente contra as boas técnicas de programação. Funções relacionadas (por exemplo, as que trabalham com strings) ficariam em módulos diferentes.
Sem falar que o número de módulos aumentaria absurdamente. Já imaginaram como isso ficaria?
O problema, meus amigos, chama-se VB6.
No teu caso, acho que o ideal seria anular a função que não está sendo usada pra desfazer a dependência.
Citação:Isso é totalmente contra as boas técnicas de programação. Funções relacionadas (por exemplo, as que trabalham com strings) ficariam em módulos diferentes.
Amigo, ter QUARENTA E OITO módulos em um projeto, já é por si só totalmente contra as boas práticas. O que seu sistema faz que precisa de tantos módulos assim?
Citação::
Isso é totalmente contra as boas técnicas de programação. Funções relacionadas (por exemplo, as que trabalham com strings) ficariam em módulos diferentes.
Amigo, ter QUARENTA E OITO módulos em um projeto, já é por si só totalmente contra as boas práticas. O que seu sistema faz que precisa de tantos módulos assim?
Sim, infelizmente precisa.
Também incluà nessa conta os módulos de classe, que caem no mesmo problema.
Embora eu não seja o autor, este programa está muito bem estruturado e só não está melhor porque o Sr. VB6 não permite.
Na verdade, não sou o autor do projeto e junto aos módulos básicos (tratamento de strings, etc.) há também os módulos especÃficos do programa (cálculos, dados, etc.).
Não, essa quantidade de módulos não é contra as boas práticas de programação.
Contra as boas práticas de programação está o não-uso de módulos, com aqules códigos [Ô]linguiça[Ô] ou [Ô]espagueti[Ô] em que o autor coloca todo o programa no evento click de um botão.
Além disso, as funções contidas nesses módulos devem ser usadas por outros programadores em outros projetos.
Também age contra as boas práticas os [Ô]incentivos[Ô] que o Sr. VB6 nos oferece: esse caso que aqui explico e também o fato de constantes públicas serem proibidas em classes, o que nos obriga a criar novos módulos só para poder compartilhar as constantes, e por aà vai.
Como pode ver, o Sr. VB6 não ajuda muito.
O segredo todo está na organização e nada será impossÃvel para o bom e velho VB6.
Citação::
Geralmente quando alguem está acostumado com outra linguagem de programação e por algum motivo é obrigado a dar manutenção em um projeto que não foi escrito na sua linguagem favorita, coloca todos os defeitos possÃveis nesta linguagem.
Sim, verdade, especialmente quando essa outra linguagem TEM MESMO defeitos BÃSICOS que poderiam há muito tempo terem sido resolvidos. A comparação é inevitável.
Para mim fica bem nÃtido que o VB6 foi criado por equipes/pessoas com mentalidades bem distintas. Às vezes me surpreende positivamente o nÃvel de abstração de certas partes do VB6, enquanto outras partes estão na idade da pedra da programação. Isso é comum em equipes de trabalho muito heterogêneas, mas demonstra também uma falta de sintonia.
Citação:O segredo todo está na organização e nada será impossÃvel para o bom e velho VB6.
Sim, nada é impossÃvel até mesmo para COBOL, Fortran, ALGOL, BASIC, Assembler, etc.
O problema é quando a linguagem [Ô]empurra[Ô] você a fazer coisas de um modo que você sabe que está errado.
Citação:Também age contra as boas práticas os [Ô]incentivos[Ô] que o Sr. VB6 nos oferece: esse caso que aqui explico e também o fato de constantes públicas serem proibidas em classes, o que nos obriga a criar novos módulos só para poder compartilhar as constantes, e por aà vai.
Poxa cara, agora acho que vc exagerou. Uma classe define um objeto que possui estado e comportamento e blá blá blá que vc já sabe.
Não é pra ficar declarando constante ali. O que acaba acontecendo em outras linguagens como C# e Java no uso de métodos e atributos static vai contra os princÃpios da POO, paradigma em que a linguagem foi designada.No VB6 vc pode emular o uso da classe pra isso que vc descreveu usando propriedades e carregando os valores no construtor da classe.