| Autor |
Mensagem |
|
|
marciosantri wrote:
Acho que polimorfismo não resolve algo como
E se fosse um double?
Na boa, acho que ia ajudar muito ao invés de ficar colocando um monte de ifs.
Dá pra encapsular tudo isso usando o padrão de projeto Command. (É matar formiga com granada, mas mesmo assim... só pra ressaltar que dá pra encapsular). 
|
 |
|
|
Na minha opinião tá de bom tamanho, visto que estruturas switch são, na maioria das vezes, um bad smell. Se você pode usar polimorfismo pra que switch flexível? 
|
|
|
|
Leonardo3001 wrote:Reeengenharia não implica na cópia da estrutura de objetos ou de chamadas a métodos presentes em uma linguagem para a outra, portanto a presença ou não de ferramenta que gera diagramas a partir de código é no mínimo questionável.
Ninguém falou em "cópia da estrutura de objetos ou de chamadas a métodos", niguém mencionou nada disso.
Mencionei a utilização de ferramentas para obtenção de diagramas de classes a partir do código fonte, isso é completamente diferente. Caso não tenha ciência, atividades de reengenharia envolvem atividades de engenharia reversa; se tivesse lido pelo menos uma referência confiável sobre o assunto estaria ciente disso. Atividades de engenharia reversa podem ser apoiadas por ferramentas.
Afinal de contas se você não tem uma representação de alto nível do que será alterado é bem complicado saber onde as alterações devem ser realizadas, e compreender o sistema como um todo. E quando a documentação disponível não está sincronizada com o estado atual do sistema? E os diagramas disponíveis na mesma também não refletem o que se encontra implementado? Vai continuar analisando e confiando cegamente na documentação?
Olha até posso sugerir algumas referências pra ti. Sem pedantismo nenhum, mas meu trabalho de mestrado é nessa área. Acho que sei do que estou falando. Se quiser pode começar por esse aqui: http://www.amazon.com/Oriented-Reengineering-Patterns-Engineering-Programming/dp/1558606394/ref=sr_1_1?ie=UTF8&s=books&qid=1210095211&sr=8-1
Toda a questão começou por "inferência de tipos", se você acha que é fácil fazer tal coisa em linguagens dinamicamente tipadas poderia publicar bastante. Há vários artigos na IEEE sobre tal assunto... se tiver alguma idéia revolucionária.
|
|
|
|
Vai ficar para a próxima, estou até a nuca de coisas pra fazer. 
|
|
|
|
Leonardo3001 wrote:
Não sei o que você entende por "reengenharia", por que é uma palavra, digamos, "superutilizada" para designar qualquer coisa que tem que ser feita na fase de manutenção. Para mim, reengenharia é uma transformação no software para se adequar a uma mudança de ambiente ou uma mudança no paradigma de negócio. Isso envolve outras variáveis além de simplesmente código, como por exemplo arquitetura ou análise do negócio, cujo esforço é o mesmo independente da linguagem utilizada pelo software.
Primeiro, em momento nenhum afirmei que o domínio, que envolve regras de negócio etc e tal, não tem influência em esforços de reengenharia.
Segundo, nesse caso eu classifico reengenharia como manutenção preventiva.
Para esclarecer um pouco mais:
Normalmente atividades de reengenharia envolvem engenharia reversa, que consiste em analisar a documentação, quando disponível, o código fonte, enfim vários artefatos gerados durante o desenvolvimento do software. Após essa análise o propósito de atividades de engenharia reversa é criar representações em um nível mais alto de abstração, como por exemplo: diagramas de classe, seqüência etc. Geralmente, essas atividades de engenharia reversa são mais facilmente realizadas quando o sistema encontra-se implementado em uma linguagem estaticamente tipada (por exemplo, Java). Leonardo3001 quantas ferramentas você conhece que produzem diagramas de classes, a partir de engenharia reversa, de linguagens como Smalltalk, Ruby, etc? Foi isso que eu quis dizer. E afirmo isso por experiência própria, pois, tive que realizar reengenharia de um sistema em Smalltalk para reimplementá-lo em Java, e pode apostar que se a inferência de tipos tivesse sido realizada de maneira mais simples eu necessitaria refatorar menos o código Java.
Abraços.
|
|
|
|
Zakim wrote:Use um editor melhor se quiser. O JEdit é uma boa opção
Ou Emacs!
|
|
|
|
|
Só para acrescentar, a questão de uma liguagem ser dinamicamente tipada pode até ajudar durante o desenvolvimento (o que normalmente acontece). Mas dificulta bastante esforços de reengenharia, principalmente quando a inferência de tipos é necessária.
|
|
|
|
Já tinha visto, bem interessante mesmo. 
|
|
|
|
balarini wrote:Estou no level 18.
|
|
|
|
marcushlm wrote:
parei no 16 pq tinha que trabalhar mesmo 
Não disse que seria uma terça feira produtiva, nada melhor que trabalhar depois da jogatina!
(nem estou jogando mais, vou terminar a dissertação primeiro )
|
|
|
|
Se a resposta for não confira os jogos abaixo, garanto que valem muito a pena, principalmente o segundo.
(caso tais jogos já tenham sido difundidos no GUJ....uhn... desculpa! )
http://www.eyezmaze.com/eyezblog_en/blog/2005/09/grow_cube.html#monster
http://magic.pen.fizzlebot.com/
Abraços, e boa terça-feira a todo vapor!
|
|
|
|
ai ai.. o bom e velho caps quebrado. 
Olha, já deu uma olhada no JFLAP? Acho que pode ajudar.
|
|
|
|
cv wrote:Que tal comprar um livro?
comprar_um_livro++
Dá pra ler no ônibus... voltando do trabalho, universidade, entre outros.
|
|
|
|
Bruno_Leonardo wrote:
Irmãozinho gente boa hein?
Mais gente fina impossível.
Parabéns pelo score. Agora é só aprender algumas práticas interessantes como refactoring e TDD, as nuances da linguagem você já conhece.
Abraço, boa sorte.
ps: ano que vem tiramos "a próxima". 
|
|
|
|
|
Relaxa. Você já sai do centro autorizado prometric com um comprovante em mãos. (Se passar claro! )
|
|
|
|