Aqui vai um exemplo de mixin, usando o módulo Comparable:
[code]#
Essa é a declaração da nossa classe
class Clube
aqui estamos criando uma propriedade read-only chamada pontos
attr_reader :pontos
initialize é o construtor da classe
def initialize @pontos = 0
end
temos 3 métodos para alterar a quantidade de pontos: ganhou, perdeu, e empatou
def ganhou @pontos += 3
end
def empatou @pontos += 1
end
def perdeu
end
aqui a gente adiciona o mixin Comparable, que tem os métodos >, <, ==, !=, e por aí vai
include Comparable
para Comparable funcionar, precisamos definir só esse método (o “barco”)
def <=>(other)
self.pontos <=> other.pontos
end
end
flamengo = Clube.new
fluminense = Clube.new
flamengo.ganhou
fluminense.empatou
dá para inserir expressões na string usando #{}
puts “Flamengo tem #{flamengo.pontos} ponto(s)”
puts “Fluminense tem #{fluminense.pontos} ponto(s)”
puts “Flamengo e Fluminense estão empatados: #{flamengo == fluminense}”
puts “Flamengo está na frente: #{flamengo > fluminense}”
[/code]
Experimente fazer o download do Ruby e rodar o programinha acima. Se você quiser mais detalhes sobre mixins pode checar esse tutorial em português.
Li seu post ali atrás e você aparentemente coloca C e C++ no mesmo balaio.
As duas são linguagens radicalmente diferentes, tanto no que se propõe, quanto na forma de programar, quanto nos paradigmas que implementam e no tipo de aplicações que cobrem.[/quote]
É que eu participei de maratona de prog, na verdade eu considero que C está todo contido em C++ e por isso coloco o C dentro do balaio do C++,
mas vc está completamente certo, elas são bem diferentes.
uma é OO e a outra não, já diz tudo
[quote=rubinelli]Aqui vai um exemplo de mixin, usando o módulo Comparable:
[/quote]
Valeu pelo exemplo
Fui ver o link, a falta de identação torna um pouco mais hard a compreensão do artigo.
Então quando vc importa o módulo tudo que for definido nele fica visível na classe que importa/herda,
e o módulo é como se fosse uma classe abstrata, que pelo que li vc não pode instanciar.
O C++ tem o paradigma estruturado (como vc mesmo falou, o C está contido nele);
Tem o paradigma OO e
Tem o paradigma de programação genérica (templates);
Além disso, ele também tem a biblioteca padrão, a STL, que inclui a classe string, classes com listas, algoritmos prontos e até um smart pointer (há planos para terem mais smartpointers no futuro, eles já estão inclusive na TR1).
Eu falei das mixin classes pq em várias implementações ela é feita através de herança múltipla, embora do ponto de vista semântico, não seja mesmo herança. Como venho do C++, sempre associei mixin a herança múltipla, embora conceitualmente você esteja certo, são coisas diferentes. Por lá, usamos programação genérica e o conceito de Policy como alternativa a mixins.
Agora que vi que tem linguagens que já tem um suporte melhor ao conceito de mixin. Bom saber. Sempre pareceu um conceito interessante.
O C++ tem o paradigma estruturado (como vc mesmo falou, o C está contido nele);
Tem o paradigma OO e
Tem o paradigma de programação genérica (templates);
Além disso, ele também tem a biblioteca padrão, a STL, que inclui a classe string, classes com listas, algoritmos prontos e até um smart pointer (há planos para terem mais smartpointers no futuro, eles já estão inclusive na TR1).
Eu falei das mixin classes pq em várias implementações ela é feita através de herança múltipla, embora do ponto de vista semântico, não seja mesmo herança. Como venho do C++, sempre associei mixin a herança múltipla, embora conceitualmente você esteja certo, são coisas diferentes. Por lá, usamos programação genérica e o conceito de Policy como alternativa a mixins.
Agora que vi que tem linguagens que já tem um suporte melhor ao conceito de mixin. Bom saber. Sempre pareceu um conceito interessante.[/quote]
Pois é, tem até generics!
O barato é sobreescrever operadores, li que em Ruby também dá.
Não usei o Blender. Como artista sou um ótimo programador. hehehehehe
A programação genérica é muito mais poderosa que os generics. Por lá você pode fazer classes herdarem de T, criar instâncias de T, ou mesmo fazer código que executa em tempo de compilação!
Os generics são uma tentativa de reforçar o sistema de tipos. A programação genérica é justamente o contrário.
C++ não possui generics, possui templates que é um recurso muito diferentes. Generics é o nome bonitinho de parametric types. Templates no C++ são 2 coisas, primeiro macros estruturadas, pois todo código de um template é instantiation time lazily expanded*; o outro é dependent types**
C e C++ são linguagens diferentes, código legal escrito em C não necessáriamente compila como C++. Os estilos de desenvolvimento com C e C++ são tão distintos que tratá-las como a mesma linguagem é por demais superficial.
Generics apenas no caso do Java é uma, fracassada, tentativa de melhorar o sistema de tipos. Outras linguagens permitem operar sobre os parâmetros, definir variância e são usadas por muitos outros motivos.
*Isso implica que qualquer raciocínio sobre o tipo final só pode ser feito depois da sua expansão. Isso não é necessário com generics.
Para quem criou o tópico: sinto te informar, mas você trabalhar com informática é viver num “será?” em loops infinitos…Nunca se sabe se determinada lgg vinga ou “morre”…Enfim, vc sempré tera que se atualizar ou se adaptar às mudanças…Informática é coisa relativamente nova, meu pai trabalhava com Cobol há 15 anos atráse hj em dia o paradigma mudou completamente, de estruturado para orientado a objetos…Eu prevejo que o futuro será uma colcha de retalhos: vários sistemas diferentes integrados por SOA, o que torna a lgg o de menos…
E pare de se preocupar com o Mercado, moço…
Não somos nós que temos que depender dele, e sim ele da gente
C++ não possui generics, possui templates que é um recurso muito diferentes. Generics é o nome bonitinho de parametric types. Templates no C++ são 2 coisas, primeiro macros estruturadas, pois todo código de um template é instantiation time lazily expanded*; o outro é dependent types**
[/quote]
E não foi o que eu disse? Só não entrei em tanto detalhe técnico pq ficar falando os nomes bonitos não ajuda a ninguém.
Eu falei no paradigma de programação genérica, não em generics. Até num post posterior eu expliquei que são coisas diferentes.
Eu não concordo que seja fracassada. Aliás, está dentro do que foi proposto. É mesmo menos poderoso que templates, e muito mais limitado do que outras linguagens fazem. Mas ele nunca se propos a ser mais do que isso.
O problema é a integração dos generics com a reflexão. Mas como programação reflexiva é um problema à parte, era de se esperar que as coisas não casassem bem mesmo.
Galera que manja de Ruby e Java,
o que não dá pra fazer com Ruby que dá pra fazer com Java?
E
o que dá pra fazer com Ruby que não dá pra fazer com Java?
Pergunto isso pq a escolha da linguagem é realmente para resolver o seu problema.
Talvez fosse melhor perguntar:
Quais problemas é melhor atacar com Ruby e quais o melhor é Java?
[quote=fabioissamu][quote=rubinelli]Aqui vai um exemplo de mixin, usando o módulo Comparable:
[/quote]
Valeu pelo exemplo
Fui ver o link, a falta de identação torna um pouco mais hard a compreensão do artigo.
Então quando vc importa o módulo tudo que for definido nele fica visível na classe que importa/herda,
e o módulo é como se fosse uma classe abstrata, que pelo que li vc não pode instanciar.
[/quote]
É, os módulos funcionam de uma maneira parecida com classes abstratas do Java, mas o legal é como você consegue “plugar” os módulos usando duck typing. Existem vários outros exemplos. Pra criar uma enumeration, por exemplo, você cria um método each e faz um include Enumerable; pra criar um singleton, include Singleton e pronto.
Então cara… vou falar meu ponto de vista. Pra mim, o Java não vai acabar (pode até ser que acabe, mas eu realmente não acredito que isso aconteça).
É só pensar no Cobol. Porque até hoje ele não acabou ? Porque tem sistemas realmente extremamente grandes que custaram milhares de dólares pra fazer e que, como funcionam bem e atendes às necessidades, não há motivos nem tempo e nem dinheiro para substituir, ou seja, seria inviável. Imagina o Banco do Brasil chegar e falar que vai tirar o Cobol dos mainframes e trocar por java… rsrs… todo aquele sistema legado que funcionou a não sei quantos anos e todas as aplicações que foram feitas baseadas nele e que custaram milhões virarem lixo de uma hora pra outra.
A partir do momento que se tem um sistema grande e funcional rodando em Java, por mais que outras tecnologias crescam mais que o Java, esse sistema não será aposentado “tão cedo”. Pode sim diminuir o numero de empresas que utilizam, mas nunca vai “sumir” de vez.
Quanto a certificação, as empresas valorizam muito a certificação não só por “ser um expert em Java”. Ter uma certificação significa que você é capaz de realizar metas, horários, ter disciplina, ser organizado… não se tira uma certificação de uma hora pra outra, é preciso muito estudo e disciplina, e as empresas valorizam isso.
Pode tirar sua certificação rapaz… garanto que será um bom diferencial, com Java ou sem Java… rsrs