[quote=fredferrao]E como fica o encapsulamento em Scala? Estes atributos sao privados ou publicos? Ou nao há encapsulamento em Scala.
Tava dando uma pesquisada e achei esta apresendação: Uma introdução à linguagem Scala: mais uma linguagem JVM ou o futuro de JAVA?
La o cara sita assim:
Mas e se eu nao quiser que a classe faça tudo pra mim? e se eu nao quiser que ela tenha tal contrutor que o "Scala faz por voce", tem como?
[/quote]
O seu conceito de encapsulamento é confuso.
Vamos lá, encapsulamento deve ser visto mais como uma convenção adotada pelos programadores do que uma característica da linguagem. Por que? Porque é muito fácil quebrar as convenções de encapsulamento de uma linguagem OO, inclusive Java!. Um exemplo são os famosos getters e setters criados para todos os atributos privados. Isso quebra o encapsulamento, porque quando acontece uma alteração em uma propriedade privada, ocorre na sequencia a alteração de seu getter e setter.
Scala tem private, protected e public e mais um monte de permissões finas que só ela tem. A diferença é que, se você não colocar o modificador, o default é public. Mas isso deveria ser até irrelevante, porque um programador mané quebra os modificadores facilmente; enquanto que um programador bom mantém o encapsulamento mesmo em linguagens que não a oferecem, como Python.
[quote=fredferrao]E outra esse negocio de tudo em uma linha é muito subjetivo de ser melhor ou nao, é como ja citaram acima, onde vai parar a legibilidade do codigo, imagina uma classe com 20, 30 ou 40 atritutos, ja imaginou que nojeira que nao fica, parecendo aquelas procedure/function do Delphi que aceita 3 milhoes de parametros.
Eu poderia fazer os atributos em uma linha no java.
public class MyClass{
private int id; String nome;
}
Voce diz nada de chaves, nada de ponto e virgula, porem voce nao tem chave mas tem parentese, nao tem ponto e virgula mas tem virgula eae?? Fica apenas a questao do contrutor que eu nao precisaria fazer, se é que eu realmente quero tal contrutor.
[/quote]
É possível sim ter construtores vazios e ter propriedades que não inicializam na construção. Mas qual a vantagem disso numa linguagem que é também funcional e que suporta concorrência via atores? Porque, nesses paradigmas, objetos imutáveis são essenciais e toda a inicialização precisa ser feita via construtor.
Não existe encapsulamento quando uma classe tem 20 ou 40 propriedades. Uma classe bem coesa tem no máximo, sei lá, uns sete atributos, ou nove estourando. 20 ou 40 atributos é “cheiro” de design ruim, pra qualquer linguagem utilizada. Então, não vejo problema ter as propriedades todas numa linha só. Se ficar muito comprida, faça a identação, ué.
Uma coisa que não foi falada é que, quando é colocado os atributos no construtor, é gerado, automaticamente, o “setter” e o “getter” pra ele. Por isso, o seu código Java em uma linha só não faz o que o código Scala faz.
[quote=fredferrao]E por fim eu concordo com o post do Celso Martins, esse negocio de replace e bala de prata como ele diz.
Fico doido quando chega um e fala: "Java morreu negocio agora é Ruby, e parece que era :lol: porque agora java morreu e o negocio não é Ruby, é Scala. Pra mim por enquanto ta igual Ruby só Fogo de Palha.
E antes que venha algum falar, sim sempre é bom aprender novas linguagens pra nao ficar bitolado, ter outras maneiras de resolver a mesma coisa e tals, eu mesmo tava querendo comprar um livro de Ruby, mas pelo visto é melhor eu comprar um de Scala que ta na moda agora(alguem indica um?).
Resumindo, eu nao vou vender minha cama por causa disso, nao pelos proximos hummm 5~10 :? anos?? Se nao eu ja tinha vendido quando a dois anos atraz um amigo chegou dos EUA e disse, java morreu negocio agora é Ruby.
[/quote]
Aí cada um faz o que achar melhor. Mas é por sua conta e risco.
