Fala pessoal,Update rapido so para a galera saber que ainda estou vivo hehe.Estou com a agenda super atribulada e (obviamente) sem tempo para postar como eu gostaria por aqui. Tenho que dividir o tempo entre o trabalho na CETIP, as aulas no INFNET, os estudos e ainda (e logico) dar a devida atencao para amigos e familia. Nao e facil nao...Fiquem de olho no que esta por vir:- De 13 a 17 de Dezembro ocorre a Semana de Engenharia de Software no Infnet. Vou palestrar 2 dias sobre metodos ageis e suas implicacoes para o futuro do desenvolvimento de software. Entrem no link do evento e chequem as datas.- Tem artigo meu sendo publicado na proxima edicao da Java Magazine (Ed 86). Faco uma comparacao bem interessante entre dois patterns que uso bastante no dia a dia: SPECIFICATION [EVANS] e STRATEGY [GOF]. Vale dar uma conferida...- Estou preparando um material bem legal sobre Agile e CMMI, fruto das minhas pesquisas na pos e embriao para os trabalhos de mestrado. Quem se interessar pelo assunto e so entrar em contato comigo por email ou aqui diretamente.Grande abraco a todos e ate breve. Mesmo uma linguagem orientada a objetos, como Java ou C#, pode ser utilizada, de forma consciente ou nao, para criacao de programas com base no paradigma estruturado. Nesse paradigma e grande a quantidade de estruturas de controle (como IF, IF-ELSE e SWITCH) e repeticao (FOR, DO/WHILE). A pergunta que fica e: programas escritos utilizando orientacao a objetos nao precisam de tais estruturas? Como ficariam essas situacoes no codigo? Vejamos...POO e sobre design. E o design da aplicacao que determina se ela esta aderente a metodologia estruturada ou a metodologia de objetos.E claro que mesmo nas aplicacoes OO sempre havera a necessidade de selecoes e decisoes. A diferenca esta na forma e na quantidade que tais elementos aparecem. Utilizando polimorfismo, um metodo que receba um parametro do super-tipo, por exemplo, nao precisara de teste condicional, pois a implementacao concreta sera decidida somente no momento da passagem do objeto.Observe (em C#): //uma Classe qualquer public void CalcularSalarioFuncionario(Funcionario funcionario) { //Gerente ou Vendedor? So na hora sera decidido. decimal valor = funcionario.CalcularSalario(); //continuacao do metodo } Um bom design OO diminui a necessidade de estruturas condicionais e de controle, porem nao a elimina por completo. O fato e que isso (a eliminacao) nao e necessario para se obter um bom design, que seja robusto, de facil manutencao e flexivel.Ex: Repositorio (em Java) //Classe RepositorioDePedidos public List buscarPedidosPorClienteID(int clienteID) { List pedidosDoCliente = new ArrayList(); if (pedidos !=null) { for (Pedido pedido : pedidos) { Cliente cliente = pedido.getCliente(); //aqui seria melhor usar o metodo equals() sobrescrito if (cliente.getClienteID == clienteID) { pedidosDoCliente.add(pedido); } } } return pedidosDoCliente; } Repare que o metodo buscarPedidosPorClienteID tem elementos de decisao, selecao e controle. Tal situacao ocorre a todo momento dentro dos repositorios. E como poderia ser um cliente desse repositorio? //uma Classe de controle qualquer public void gerarListaDePedidos(int clienteID) { RepositorioDePedidos repositorio = new RepositorioDePedidos(); List pedidos = repositorio.buscarPedidosPorClienteID(clienteID); //renderizo uma tela, gero um relatorio, etc }