JavaFree.org | RubyOnBr.org

Sobrecarga

Acompanhar Sobrecarga 14 posts, 6 participantes

Avatar Rodrigo Mendonça 98 posts

Uma das coisas que admiro MUITO no Java e no C++ é sobrecarga e sobrescrita.

Porém no ruby não tem sobrecarga, php também não.

Isso é uma características de linguagens de tipagem dinâmica?

Existe algum plugin que faz sobrecarga?

Abraço

 
Avatar nofxx 1960 posts

Serve pra q?

 
Avatar Rodrigo Mendonça 98 posts

sobrecarga é assim

no mesmo model eu tenho dois métodos
class pessoa
def comprimentar()
puts “olá”
end
def comprimentar(outra_pessoa)
puts “olá #{outra_pessoa}”
end

Assim eu posso usar qualquer um dos métodos (mesmo tendo o mesmo nome)
Eu sei que eu posso converter esses dois métodos em apenas um, usando parametros não obrigatórios.
Mas não é tão poderoso quanto a sobrecarga como fiz acima, acreditem. Posso ter muitos métodos com o mesmo nome mudando somente os tipos e quantidades de parametros. Polimorfismo BRUTO!!

 
Avatar rrsilva 181 posts

Eu costumo ver em Java o seguinte:

Nunca vi outro uso para sobrecarga (talvez eu nunca tenha visto bons programadores em java)

Em ruby, isso se traduz a:

Em que outro caso a sobrecarga poderia ser usada? (No mundo real)

 
Avatar nofxx 1960 posts

Hm… igual Erlang.
É, eu ainda prefiro param nao obrigatorios. Vc conhece o splat neh? Vc pode fazer:

Passar um hash e ser feliz.

Tu tá mto encanado com as firoulas de java kra, escopo em cima do muro, overload, interface… haha esquece man. Eu gosto daquela frase “Leva mta gente inteligente p/ fazer algo complexo, e genios pra faze-lo simples”.

 
Avatar rrsilva 181 posts

Concordo com o nofxx, eu sou desenvolvedor Java tb, meus códigos em Ruby, só começaram a “funcionar bonito” quando eu dexei de lado os conceitos de Java, não que os conceitos sejam ruins, é bom, mas para Java, em Ruby tem que ser em Ruby-way de fazer as coisas.

Respondendo a pergunta, não que seja uma caracteristica das linguagens dinâmicas, mas com um linguagem dinâmica, você realmente precisa de sobrecarga? (com o perdão do trocadilho)

 
Maironbrasil#pic-0 Mairon Brasil 823 posts

boa frase nofxx

heeheh

abraco

 
Avatar nofxx 1960 posts

Out of curiosity, pq “sobrecarga” ? Eh o termo usado no Java?
Pra mim isso sao “metodos com diferentes paridades”

 
Avatar reu 16 posts

E melhor ainda, se vc ta usando rails, o active support tem esse método lindo pra ser usado com o splat: http://api.rubyonrails.org/classes/ActiveSupport/CoreExtensions/Array/ExtractOptions.html

 
Avatar Rodrigo Mendonça 98 posts

HUMMMM entendi!!!

vou seguir a dica do rrsilva e pensar mais na maneira ruby de resolver as coisas.

Já que perguntou em qual outro caso a sobrecarga poderia ser utilizada

Vamos supor que eu vou fazer uma autenticação, portanto tenho a classe login

No java eu faria assim

CLASSE LOGIN
public void autenticar(Cliente cliente, String senha){
//aqui tem um monte de regras
}
public void autenticar(Comprador comprador, String senha){
//aqui tem outras regras de autenticação
}
fim classe LOGIN

aí no meu programa principal eu chama

autenticar(comprador,“123456”);//comprador é um objeto do tipo COMPRADOR
autenticar(cliente,“09876”);//cliente é um objeto do tipo CLIENTE

o java vê a tipagem do objeto e sabe escolher qual método é o correto

Eu acho isso um polimorfismo muito bonito, pois deixa o código mais claro e evita de eu ter que ficar lembrando nomes de métodos já que posso ter muitos métodos com o mesmo nome. Também evita de eu ficar lembrando quais parâmetros são obrigatórios ou não. Sobrecarga é uma característica do Java e do C++ que eu adimiro mto.

 
Avatar rrsilva 181 posts

Entendi, para regras de negócios em Java é uma mão na roda mesmo, mas justamente por causa da tipagem. Em ruby, em tais casos você deve seguir o conceito de duck-typing.

@nofxx Sim sobrecarga é o termo utilizado em Java, java permite ter métodos com os mesmos nomes desde que as assinaturas dos mesmos sejam diferentes.

 
Avatar reu 16 posts

@Rodrigo Mendes tudo isso poderia ser resolvido implementando um design diferente. Imagine algo do tipo:

public interface Autenticador {
  public boolean autenticar(String login, String senha);
}

public class ClienteAutenticador implements Autenticador {
  public boolean autenticar(String login, String senha){
    //... implementação das regras de autenticação do cliente
  }
}

public class CompradorAutenticador implements Autenticador {
  public boolean autenticar(String login, String senha){
    //... implementação das regras de autenticação do comprador
  }
}

public interface Autenticavel {
  public boolean autenticar(String password);
}

public class Cliente implements Autenticavel {
  private String login;
  private Autenticador autenticador = new ClienteAutenticador();
  
  public boolean autenticar(String password){
    return autenticador.autenticar(this.login, password);
  }
}

public class Comprador implements Autenticavel {
  private String login;
  private Autenticador autenticador = new CompradorAutenticador();
  
  public boolean autenticar(String password){
    return autenticador.autenticar(this.login, password);
  }
}

Autenticavel cliente = new Cliente();
Autenticavel comprador = new Comprador();

cliente.autenticar("123910239";
comprador.autenticar("a0sd023");

Algo assim você conseguiria “traduzir” para o ruby bem mais facilmente, e ainda manteria tão flexivel quanto guardar todas as regras de autenticação numa mesma classe, já que continuariamos usando polimorfismo =]

 
Avatar Shairon Toledo 1428 posts

BTW e complicado fazer enviar mensagens com overloading, optional parameters e varargs no mesmo método, o interpretador/compilador não saberá qual método vc realmente quer, exemplo:

Com optional acontece a mesma coisa

 
Avatar nofxx 1960 posts

Hm… q tal pensarmos OO?

autentica(user,
autentica(comprador

#imperative_fail…

user.authorized?
buyer.authorize(“ff04”)

E mesmo se preferir imperativo, da pra ficar melhor:

auth_user(“ff04”)
auth_buyer(“ff04”)

Mto mais intelegivel a meu ver… nego entrar num code cheio dessas paridade credo em cruz, ficar mais perdido q filho de puta segundo domingo de agosto.
;)