| Autor |
Mensagem |
|
|
nel wrote:Essas são questão que me afligem, na verdade.
Eu trabalho com JEE, pois meu foco são sistemas WEB. Isso envolve EJB e bla bla bla. Ok. Me expressei mal e acabei gerando discussão com o saoj sendo que percebo que ambos estavam discutindo pontos de vista um pouco diferentes. O meu problema nisso, é que grande parte das listas que crio são enviadas para a página, ou seja, existe uma tabela de objetos em que o usuário final pode simplesmente "brincar" nela. Pode remover a posição, 10, 10, 1000 ou qualquer uma. Por conhecer que o LinkedList é mais lento para remoções por índice (get(i)) procuro usar o ArrayList, todavia, em listas que não há a participação direta do usuário final, uso o LinkedList.
Este mecanismo é um pouco estranho. Vc usa o numero da linha da tabela para corresponder com a lista do lado do servidor. Normalmente se requer que os objetos tenham alguma identidade que os distingua uns dos outros, como um id de banco. E é o id e não o indice que é passado ao servidor.
Veja que para a remoção de um único objeto não é certo qual é melhor. O linkedlist é O(i) e o arraylist é O(n-i) já que o primeiro tem que iterar i vezes , mas a remoção é O(1) e o segundo encontrar o item é O(1) , mas tem que fazer o shift que é O(n-i) (não tenho a certeza deste aqui por não sei exactamente qual é a performance do System.arraycopy)
sergiotaborda wrote:Mas em sistemas reais a velocidade de indexação é práticamente irrelevante porque se usa muito pouco for com get(i) porque é um anti-pattern.
Se é um anti-pattern, qual seria a solução ideal? Ou a mais correta para uma situação como citei?
É dificil dizer sem saber o que vc está fazendo, mas eu nunca tinha visto essa forma de trabalhar antes.
Normalmente se usa um mecanismo de filtro ( como o que vai ser incorporado no java 8 para todas as classes de coleção). A ideia é ter uma interface Filter com um método que retorna booleano.
Ai iteramos a lista, se o filtro acusa false, removemos o item com iterator.remove
Como o Filter é uma classe podemos implementar como quisermos. Normalmente se comparar o código ou se usa o equals. Mas nunca o index porque esta é uma tecnica genérica aplicável a qualquer Iterable cujo iterador permita remoção.
Se vc tem esse caso de uso que usa o index e realmente vc vê isso como a forma certa, então realmente usar remove(i) é a melhor opção , no seu caso.
(...), o meu costume é foreach e não iterator, em tudo, incluindo remove (menos quando tenho de remover um objeto da própria lista, obviamente). Estou fazendo bobagem? Ou o iterator só terá uma diferença significativa em relação ao remove?
Atualmente (java 5 em diante) foreach é a forma certa de iterar. Nada de while nem for com iterator. A única exceção, vc está certo, é quando vc quer usar o iterator.remove.
Respondendo ao saoj , eu não costumo usar remove nunca nos meus projetos. É muito raro. mas quando preciso normalmente está envolvido algum processo iterativo ( como copiar ou filtrar uma lista). E nesse caso sempre uso iterator.remove. Não tenho que implementar nenhum objeto novo.
Quando quero trabalhar como algoritmos mais complexo normalmente uso Map. Em que a chave do mapa é o objeto que irá servir para encontra o outro. E ai usar remove(key) é rápido no HashMap. Se o objeto é a sua ppr chave , uso Set. O set usa um map por detrás dos panos, então dá no mesmo. Por outro lado, se vc está interessado em remover algo, normalmente não trabalha com repetidos e o Set é mais eficiente.
Remove diretamente de listas, realmente não posso opinar muito porque não uso. E não vejo necessidade.
|
 |
|
|
saoj wrote:
saoj wrote:
Detalhe, linked é mais rápido para inserção e remoção nas extremidades da lista ( por isso tem métodos como removeFirst() e removeLast() ) , mas é mais lento para remoção de um elemento no interior.
Acredito que essa afirmacão está errada. Quando vc remove um elemento do interior de uma lista, ArrayList vai requerer um SHIFT bastante custoso. Já no LinkedList essa operacao é bem rápida. É o oposto do que vc afirmou aí em cima.
Acho que eu entendi agora a confusão. O problema não é a REMOCÃO em si. O problema é a LOCALIZACÃO do elemento no meio da linked list. Obviamente vc não vai poder usar indexacão. Mas quando se diz que REMOCAO numa LinkedList é mais rápida que uma REMOCAO num ArrayList, é claro que se está assumindo que o elemento a ser removido já está em mãos, daí basta fazer a atualizacao na sua double linked list.
Acho que se vc está falando de uma java.util.LinkedList, vc terá que sempre pagar o preco de encontrar o elemento a ser removido, então isso será um problema, não pela remocao em si, mas por ter que achar o elemento na lista.
Note que se estiver removendo elementos próximos do início, o custo de achá-los será baixo enquanto a remocao será bem rápida. Sendo a lista longa, teríamos um custo bastante alto de shift caso estivéssemos utilizando um ArrayList. O que vai acontecer é que o LinkedList vai ser mais rápido se o objeto a ser removido estiver no início da lista e o ArrayList vai ser mais rápido se o objeto a ser removido estiver no final da lista. (Assumindo uma lista relativamente grande)
O ideal é vc ter a sua própria implementacão de LinkedList onde o objeto que vc coloca na sua lista extende ou implementa um Entry dessa lista. Daí de posse do objeto vc pode rapidamente remove-lo sem qualquer custo de encontrá-lo. Mas como vc encontrou o objeto primeiro de tudo? Provavelmente veio de um map, estava cacheado em algum lugar, não-interessa... De posse desse objeto eu não deveria ter que encontrá-lo novamente na lista para remove-lo, sendo essa lista uma (double) linked list.
Sendo a java.util.LinkedList uma lista de objetos genéricos, vc sempre cai no problema de ter que encontrá-los na lista. Por essa lado o errado aqui sou eu.
A solução para esse dilema não é criar uma entry e sim usar iterator.remove. Ao iterar já temos o objeto em mãos e por consequência a remoção em si é rápida. A iteração também é rápida.
Comparemos com usar remove(i). O remove(i) itera até i e remove. É a mesma coisa. Ambos são O(i)
Se estamos interessados em remover apenas um item remove(i) é melhor, não porque é mais rápido, mas porque é mais simples de usar.
Agora, se estamos interessados em remover vários elementos, ai sim ha uma diferença entre for de remove(i) e for com iterator.remove são diferentes
No primeiro a cada i temos que percorrer a lista novamente o que faz com que o algoritmo seja um for de for e seja O(ni) no segundo vamos iterando e removendo o algoritmo é apenas O(n) já que não é um for de for.
Com arrayList remove(i) ou iterator.remove sempre é um for de for, porque embora pegar e remove o item seja O(1) fazer o shift requer O(k) onde k = n - i
Acho que agora ficou claro.
|
|
|
|
nel wrote:Dá uma lida aqui, faz o favor: http://www.guj.com.br/java/71065-qual-a-diferenca-entre-linkedlist-arraylist-e-vector
Não sou eu quem precisa rever os conceitos nesse caso. O LinkedList só é muito bom para remover o primeiro e último item da lista, não os seus "interiores", porque tem métodos como o removeLast()
Dá uma lida no link que lhe passei e por favor, pesquisa na net e veja a opinião da maioria se eles usam LinkedList quando querem remover objetos do array.
Edit: não só remover mas como manipular um objeto do interior da lista.
Quando você fala que o LinkedList é mais lento em insersão e remoção porque tem que iterar todos os itens vc está falando de remoção e inserção por índice. É preciso que vc diga isto, porque nesse caso sim é mais lento, mas essa utilização não existe na prática.
É extremamente raro que alguém faça remove(i) em listas. Agora,se vc considerar o caso mais comum que é remover durante a iteração com iterator.remove() o linkedlist é mais rápido. Pq ? porque não tem que redimencional o array subjacente à lista porque não ha nenhum.
No mundo das listas ha duas formas de uso, por indice e por iterator. Fazer um for com i e percorrer de X a Y ok. Mas isso é muiiiiittttoooo raro. Normalmente vc quer iterar todos os elementos da lista. Então vc usa iterator ou for extendido.
Ora, usando com índice qualquer classe que implemente RandomAcess será melhor. Logo, ArrayList é melhor quando se usa get(i). Mas no caso padrão em que se usa iterator ambas têm o mesmo resultado. Isto se vc apenas iterar.
Se vc iterar e remover itens enquanto iterar usar ge(i) remove(i) é extremamente falho e usar iterator.remove é muito simples. Logo, vc usa iterator.remove. iterator.remove é mais rápido no linkedlist. E quando digo rápido me refiro a que é O(1) e não O(n).
Quando estamos falando de inserção linkedlist tb é melhor. Isto pq o arraylist tem um custo exponencial quando se incluem itens além do tamanho reservado.
Quando usar um ArrayList ? Apenas quando o tamanho é pre-conhecido , fixo e a iteração não irá invocar iterator.remove.
Quando usar LinkedList ? Quando o tamanho não é conhecido, não é fixo ou a iteração irá invocar iterator.remove.
Quando vc cria um ArrayList sempre passe no construtor o tamanho. Se vc não consegue saber qual o tamanho, então isso significa que 1) vc não leu o codigo com atenção ou 2) deveria usar um linkedlist.
Pense agora na situação em que vc tem uma lista A e quer produzir uma lista B só que alguns elementos de A não estarão em B. Vc cria um for em cima de A e copia para B apenas os elementos que passam no if do filtro.
Ok, mas que tipo de lista será B ?
Podemos dizer que sabemos o tamanho de B ? Não. Mas sabemos que será igual ou menor que o de A. Se criarmos um ArrayLsit nos arriscamos a ficar com um array de varias posições vazias. Então a solução é usar um linkedlist.
O linkedList é em geral mais lento que o arraylist quando se usa get(i), excepto quando i= 0 ou i= ultimo elemento.É que o linkedlist é na realidade duplamente linkado. Por causa disto, os metodos get/removeFist e get/removeLast existe no linkedList.
E com eles é possivel criar queues (filas). Arualmente LinkedList tb implement Queue e DeQueue. É a coleção mais versátil que existe.
Em programas reais é incomum que as pessoas usem LinkedList. isto porque elas não sabem usar. Então ArrayList é pau para toda a obra. Ora, de fato, a interface list não deveria ser usada em sistemas reais porque usar get(i) é horrivel.
Contudo em java List tem um significado semântico : elementos repetidos e em ordem. Por causa da semantica sofre o design.
O mais correto é sempre usar Collection (seguindo a regra de : use a interface mais abstrata possivel). Assim vc força todos a usar iterator que é o certo. A coleção pode ter repetidos e estar em uma ordem. Se não estiver use Set.
Desta forma vc elimina o uso de List e por consequência impede que se use get(i). Neste cenário é mais simples escolher as listas, mas ArrayList é normalmente usado porque normalmente a lista tem tamanho fixo e conhecido. Mas , por exemplo, quando vc lê de um ResultSet JDBC quando usar ? LinkedList ( porque mesmo o tamanho sendo fixo, vc não sabe qual é).
Para resolve o dilema várias bibliotecas de collections com o Apache Collections ou o Guava adotam o conceito de Bag. Bag é como uma lista, ou seja permite repetidos e uma certa ordem, mas não permite indexação. Se vc não gostar de usar apenas Collection e Set existe sempre a opção de criar a interface Bag e usá-la nos seus sistemas.
Outro problema que leva ao uso indevido de List são as tags core do jsp que só aceita list. Isto é muito limitativo e acaba forçando que seus business/services/daos retornam List.
A solução aqui é construir sua biblioteca de tags de forma a usar iterator e não get(i) como as tags jsp padrão.
Espero ter ajudado a esclarecer. A discussão toda foi porque uns estavam falando de velocidade de indexação e outros de velocidade em iteração. São coisas diferentes. Mas em sistemas reais a velocidade de indexação é práticamente irrelevante porque se usa muito pouco for com get(i) porque é um anti-pattern.
|
|
|
|
Grinvon wrote:Opa Senna.
Estou o utilizando para gerar código Java e depois também JSP. Para facilitar a criação de códigos repetidos, na verdade, será um gerador de CRUD para os nossos projetos. Já está fazendo a entidade. A fonte é carregada de um XML modelo usado para descrever os campos e tabela, daí ele gera a classe entidade, e depois irei implementar a geração de classes modelos e JSP.
SE a fonte é xml, XSLT seria uma boa opção. Melhor e mais padronizada que freemarker ou velocity. Entre estes dois eu escolheria o freemarker.
|
|
|
|
amhfilho wrote:Pessoal,
Tenho que converter um sistema de contabilidade feito em Clipper!!! (é isso mesmo e por incrível que pareça a empresa que o fez ainda o vende) para Java. O sistema será desktop mesmo com Swing e de banco de dados Firebird. Alguém tem alguma sugestão de arquitetura e framework (MVC , Java App Framework)? O último sistema Swing que trabalhei tudo era feito na mão, inclusive as telas.
A princípio pensei em desenhar as telas no Netbeans e desenvolver uma arquitetura tipo domain model com jpa, service e um controller que faria o tratamento de eventos, mas tenho um pouco de receio de ficar muito complexo para um sisteminha desktop. Se usar o blueprint da Sun começa entrar beans binding com Observer.
Básicamente essas são as opções. Não ha nada muito especial no mundo do swing.
Você pode partir para outras tecnologias desktop como JavaFX e Thinlet, mas nã acho que seja grande vantagem.
Alguém tem alguma sugestão? O cliente não liga muito se o sistema tá pouco acoplado e se tem arquitetura n camadas. Mas também não queria fazer nada tosco.
Os clientes nunca lingam para isso. Mas vc deve ligar, porque é num sistema bem construido que está o seu lucro.
|
|
|
|
ingridfarabulini wrote:Olá.. continuando meus estudos fiquei com uma dúvida: 'Camada de Aplicação' e 'Camada de API' são ambos a mesma coisa, só muda a palavra? Podemos definir ambas como 'Camadas de Código' que vão estar presentes dentro dos andares?
Não. Quando se usa a nomenclatura de andar / nodo / plataforma a palavra "camada" significa apenas "conjunto de classes que colaboram para um fim único" , mas "conjunto de classes que colaboram para um fim único" é uma API, portanto "Camada de API" é um pleonasmo para deixar claro que estamos referindo a um conjunto de classes e não ao "nivel" que elas ocupam no sistema.
Editado: Só para completar a pergunta acima, uma API também é um framework? Digo, Swing é uma camada API java e também é um framework?
Todo o framework é uma API, mas nem toda a API é um framework. O Swing é ambos.
Um framework é uma API "imcompleta" ou seja, que para funcionar , quem a for usar tem que implementa algumas coisas.
|
|
|
|
matheusssilva wrote:
Virão como cada item tem um calculo diferente.
Embutir esses calculos dentro do sistema fica complicado pois cada item tem uma formula diferente e são muitos. E o sistema deve faze-los automáticamente.
eu não entendi o seu problema. Qual é o problema de incluir calculos no sistema ? ( não é para isso que ele serve ?)
Ou o problema está em serem calculos diferente ? ( quanto a isso, tb não entendo porque seria um problema)
Existem soluções para ambos os problemas, mas - primeiro - é preciso ficar claro qual é o seu problema...
|
|
|
|
derlon wrote:
.. ou camada de Negócios(Business Object)?
Estou ficando extremamente contra esse negócio de Camada de Negócio, seu codenome BO, etc.!  Pq ela certamente provoca mal-entendidos: ela sempre leva todo mundo a pensar q é nela q devemos implementar ("centralizar" ) as Regras de Negócio, quando certo é encapsular Lógica e Regra de Negócio no própria Classe Entidade, enfim dentro dos Objetos DamainModel, né?!; afinal, não foi para isto q o Paradigma de Orientação a Objeto foi inventado (encapsular Dados (em Atributos) e Operações (comportamento em métodos)?!! Esses tais BO's e VO's estão começando a me dar calafrios!
BO (BusinessObject => Objeto de Negocios) é um padrão antigo que nada tem que ver com camada de negócios. É simples ver porque : uma camada nunca será um só objeto e vice-versa.
O BO era um padrão usado ha muito tempo atrás mas completamente descabido. Nunca foi um design pattern real, era apenas uma classe onde as pessoas misturavam responsabilidades de DAO e Serviço e seja lá mais o que for numa coisa só.
Camada de Negocios é um conjunto de serviços orquestrados a trabalharem juntos. (É o que deu origem ao SOA)
sergiotaborda wrote:Contráriamente ao que muita gente pensa a prática corrente é seguir o modelo do Fowler como indicado na figura enviada pelo Rodrigo e não o DDD.
Bem, como eu disse em outro tópico: "Claro q não podemos tomar como lei universal (e irrevogável) tudo o q os autores falam: devemos ter senso crítico."
As coisas q não me agradaram muito na imagem (modelo do Fowler) 'Service Layer' é: q ela não apresenta um separação clara entre Serviços de Domínio (DomainService's) e Serviços de Infra (camada conceitual InfraEstrutura).
Não cabe naquele deseja essa divisão. O desenho teria que ser 3D para vermos a diferença. Se imagina que aqui são cilindros concentricos, então a diferença entre serviço de aplicação e de negocio está na profundidade, não está na distancia ao centro do cilindro do meio.
Uhm * ela é muito curiosa: um gráfico meio tipo cebola; ah, a outra coisa q eu não achei muito legal é q ele "dá a entender" (pelo menos para os iniciantes) o q o 'Domain Model' deve usar a abordagem 'Active Record'! 
Não sei de onde tira essa conclusão. Não tem nem remota lembrança...
[off-topic - ***]
Meu kamarada, realmente é muito mística a tradução da palavra "design" do inglês para o português. E, por vezes ficamos injuriados quando vemos, na tradução de um livro técnico, ela traduzida para "desenhar"; então nós pensamos: q tradutor estúpido, pq ele não traduziu para Projeto|Projetar?! Afinal, p/ o pessoal da Engenharia de Software, Projeto é algo q fica entre a Análise e a Implementação.
É comum ver pessoas hoje dia defendendo o que vc está dizendo.. mas quanto a mim isso é falta de vivencia e de entender ingles. Design se traduz para desenho, quer goster, quer não.
Desenho sim é algo abstrato e muito mais criativo que arquitetura. Projeto não tem nada a ver com design, nem com software. É por isso que existem projetos de muitos tipos. Projeto é apenas conduzir atos para obedecer intensões. A tradução "padrões de projeto" é que está errada. A tradução certa é "padrões de desenho" ( em outras linguas é feita essa tradução, como em espanhol, por exemplo).
O problema de muitas equipas ( eu diria quase todas) é a falta de entender que um software nasce do design. Um bom design leva a um bom software e um mau design leva a um grande problema.
Analise e Design são opostos no sentido que Analise (dividir) significa entender o problema. Parti-lo em partes até entender o todo. Depois vem a sintese. Essa sintese é o design. É a organização das peças de software para chegar num objeto que realiza o mesmo que a ideia que analizámos. Imagine construir uma casa com peças de lego. A casa é o objetivo e o conceito. Aanlisamos como ela é formada (paredes, portas, janelas, etc..) identificamos essas peças de lego que correspondem a essa "funcionalidades" e verificamos que não existe nenhuma pessa "parede" então temos que a construir de outra peças... esta identificação e as desições que tomamos ( por exemplo, usar peças todas da mesma cor, ou usar fileiras de cor sim, cor não) são desições de design. O conceito imaginado, analisado é construir por um processo de identifiação e construção guiado pelo design. Um bom desenhista é aquele que tem conhecimento das peças que existem e de como criar novas peças com essas que tem ou, dado um conjunto limitado de peças, construir peças novas. Em software isto é ainda mais simples e desafiante porque todas as peças (objetos/classeS) podem ser construidos a partir de uma materia básica (que são os objetos principais do java ) Tudo o resto deriva dai, e a API java, por exemplo, é apenas um conjutno de peças já prontas que são tão uteis que constui-las do zero toda a vez é monotono e chato.
Design é alma do desenvolvimento, por isso muita gente traduz "design patterns" para "padrões de desenvolvimento". "Desenvolvimento" é o mais perto que temos da palavra "desenhar" sem usar a palavra "desenhar" que sempre associamos com imagem e por consequencia com GUI. (em ingles não existe essa associação já que desenhar (nom lápis) é draw)
Projetar não é o mesmo que desenhar. Projetar é limitar os recursos e mesmo assim chegar num objetivo. Desenhar é criar recuros novos com base nos que temos.
"DDD não é sobre design patterns" -> Por um lado, eu até ampliei esta idéia (transcrito de 1 msg pvt minha):
 "Francamente, certamente q desenvolver DDD se encaixa perfeitamente em Java. Antes de qq coisa, temos q ter em mente q DDD NÃO tem nada a ver c/ tecnologia; é sobre o código-fonte (de nosso Software) refletir a realidade do (domínio) do negócio dos Stakeholders.
Isso, essa tecnica, que agora tem nome, é muito velha. É o proprio conceito de orientação a objetos como entidades abtratas do mundo real. Isso é OO 101 ( a primeira aula de Orientação a Objetos).
O problema é que as pessoas esquecem-se disso. DDD não trouxe nada de novo. Apenas publicitou o que já tinhamos com novos nomes. Mas , fazer o quê ? é uma moda que pegou e todo o mundo quer fazer DDD. Fazer OO bem feito é muito melhor que DDD.
IMHO, não devemos sempre ter tanta rigidez conceitual, até pq nem todos o Sistemas precisam de tantas camadas lógicas, com tanta complexidade (ainda q a DDD não seja bala-de-prata, Ok). Porem, um Design simples o bastante (barely good enough), mas q isole o Domain (do resto da Aplicação) já propicia uma Arquitetura de Software Evolucionária|Emergente.
Na prática não é possivel fazer isso sem usar o conceito de camada ( a comparação com a cebola não é deprositada). E historicamente identificámos 5 camadas. Repare que elas podem ser finas ou gordas o quanto vc quizer, mas elas estarão lá. É uma necessidade do conceito de dominio que não sendo um conceito abstraivel com objetos, precisa ser abstraido como um conjunto de objetos, e isso automaticamente singifica ter uma camada. Mas como só temos objetos ( tudo são objetos) é inevitável que os objetos de dominio comuniquem com outros objetos. Se isso não acontecer o dominio é inutil. E se isso acontecer, automaticamente temos que ter pelo menos uma camada mais. Este raciocinio é recursivo, portanto, se pode demonstrar um conjunto infinito de camadas. É ai que entra a prática, mas nos dizer que 5 bastam. E isso é concluido empiricamente dos dados levantados de vários softwares feitos com o mesmo proposito na mesma tecnologia.
O que eu quero dizer com tudo isto é que o conceito de camada é matemáticamente demonstrável advir do conceito de objeto + o conceito de responsabilidade e , portanto, não é algo que se possa chamar de "rigidez conceptual". As coisas são como são, e estas coisas, são assim. Quanto mais depressa entender e aceitar, mais depressa vc pode se preocupar com o que interesssa: o design.
|
|
|
|
Vini Fernandes wrote:Gostaria que postassem o codigo que utilize Calendar para determinar o diferenca entre dois meses apenas utilizando a API da Calendar, pois em determinado momento qualquer um tera que fazer um Calendar.getTimeInMIlli(); entao voltaremos a situacao anterior! Procurei alguns posts aqui mesmo no GUJ e nao encontrei nada que nao envolvesse uma algebra simples.
T+
A lógica é sempre a mesma e é muito simples. Comece na data inicial e adicione uma unidade até chegar na data final. o numero de unidades adicionadas é o numero que existe entre elas dessa unidade.
Não ha nenhum codigo de subtração aqui e não ha redução a milisegundos.
|
|
|
|
ViniGodoy wrote:
sergiotaborda wrote:Porque o java é desenhado para hierarquia de pacotes e a herança pode ser cross-package. O pacote é um membro importante do java porque é usado para várias coisas na jvm. Segurança, entre elas. O Package é um conjunto de Class.
Não faltam modificadores no java, o que falta é o conceito de pacote filho. normalmente criamos o pacote X e depois o pacote X.Y onde Y serve para alguma coisa particular de X, por exemplo, X é interfaces e Y é implementações. Este vicio é levou a considerar que o java é imcompleto, quando na realidade é esta prática que está errada. Apenas classes da API que podem ser usadas fora do pacote devem ser publicas. O resto deve ser tudo package. É por isso que o package é o default, porque é assim que deveria ser feito.
Claro, siga essa recomendação e você acabará com pacotes enormes, cheios de classes, o que vai contra qualquer prática sensata de modelagem.
Não vejo onde está o problema disso. Nem vejo que isso seja um problema de modelagem. Organização de pacotes está longe de ser um problema de modelagem a menos que vc siga o padrão proposto pelo Java ( eu disse java, não sun).
Ao construir uma API grande como a do java é necessário tem em consideração que existem classes escondidas que vc não vê. A API publica é publica exatamente porque é que vc precisa usar, mas exste a API privada que tem apenas detalhes de implementação. Esta deve ser "secreta".
Eu nunca vi muita utilidade na visibilidade padrão, até que comecei a criar API grandes como o MiddleHeaven. Existem coisas que vc precisa fazer mas que vc não quer publicar (até porque vc quer minimiar a superficie da API). Então o nivel default é realmente util na prática.
Em pacotes de negocio obviamente terá pouca utilidade já que os pacotes de dominio são os mais publicos que ha (afinal eles representam conceitos que existem na realidade e não detalhes de implementação).
Ter muitas classes num pacote não significa desordem. É esse conceito errado que leva as pessoas a criarem muitos subpacotes idiotas. Eu odeio especialmente o pacote impl. Um verdadeiro cancer. Não ha razão logica para segregar as implementações para outro pacote.
A regra base é muito simples ( tudo é private, apenas é aumentada a visibilidade quando necessário) mas - quase - ninguém a usa. e depois culpam o java ...
|
|
|
|
Não usem calculos matemáticos como o de cima e alguns exemplos nos links passados. Usem Calendar.
Sempre use Calendar para calculos de datas (a menos que use outra API melhor) e nunca faça os calculos matemáticamente como se aprende na escola não é assim que funciona na realidade.
|
|
|
|
ViniGodoy wrote:Acho os modificadores do Java extremamente permissivos.
Por que o protected abre tanto para as classes do mesmo pacote?
De privado mesmo você praticamente só tem o private.
Porque o java é desenhado para hierarquia de pacotes e a herança pode ser cross-package. O pacote é um membro importante do java porque é usado para várias coisas na jvm. Segurança, entre elas. O Package é um conjunto de Class.
Não faltam modificadores no java, o que falta é o conceito de pacote filho. normalmente criamos o pacote X e depois o pacote X.Y onde Y serve para alguma coisa particular de X, por exemplo, X é interfaces e Y é implementações. Este vicio é levou a considerar que o java é imcompleto, quando na realidade é esta prática que está errada. Apenas classes da API que podem ser usadas fora do pacote devem ser publicas. O resto deve ser tudo package. É por isso que o package é o default, porque é assim que deveria ser feito.
Protected é para herança entre pacotes. Ele é mais permissivo que o package e menos que o public. Só que as pessoas não o sabem usar. O problema é esse e não a especificação do java. Por exemplo, métodos auxiliares declarados em classes abstratas devem ser protected e não public, como é costume ver por ai.
As anotações do projeto jigsaw não são para aumentar ou substituir os modificadores de visibilidade, são feitas para criar um novo conceito de bundle (que eles chama modulo) que é um conjunto de pacotes. (Bundle -> pacote -> class ). Na realidade está havendo uma evolução e não um remendo. O conceito é definir permissões de visibilidade entre modulos e pacotes e não entre classes como fazem os modificadores de visibilidade.
Com modulos é possivel fazer mais coisas interessantes em segurança e gerenciamento de dependencia como o OSGI já mostrou.
|
|
|
|
Pergunto: Por que eu iria querer usar o Bridge!?
O padrão responde a isso. Se vc não sabe a resposta isto vc não entendeu o padrão.
A primeira linha do padrão explica porque usar : desacoplar contrato de implementação tal que ambos possam evoluir em separado.
|
|
|
|
derlon wrote:
sergiotaborda wrote:O senhor Evans não é a melhor referencia para nomenclatura. É dele a autoria da asneira de confundir Repositorio e DAO porque não teve o mesmo cuidado que o Fowler teve quando redefiniu o termo "value object". O repositorio-DDD pode ser um DAO, uma lista, um qualquer coisa que se assemelhe a uma coleção.
Não consta, pelo no resumo do InfoQ, nada sobre o "Repository ser um DAO". Mas, volto a citar: "A Repository may contain detailed information used to access the infrastructure, but its interface should be simple." e "... the implementation of a repository can be closely liked to the infrastructure, but that the repository interface will be pure domain model." Então vemos que foram usando os verbos "may" e "can" (ou seja, "pode") e não foi usado 'must' ('deve'/deveria). Ou seja, ficou claro ele q denota 'Repository's como um tipo de Arquivo Lógico.
"repository can be closely liked to the infrastructure"
O erro é o "can". It can not.
O repositorio não pode ter detalhes de infraestrutura.
Se tiver é uma implementação gambiarra. O padrão Repository sempre delega esses detalhes a um outro objeto.
Vejo a coisa da seguinte forma (e até o pessoal do princípio KISS e/ou agilistas vão concordar): os Repository's podem ter um atributo 'EntityManager' (do JPA, o qual inclusive alega abstrair/encapsular a DAO) injetado por um @PersistenceContex; caso sejam percebidos "gargalos" em alguns Objetos DomainModel, seu Repository poderia então usar uma DAO, c/ abordagem JDBC puro p/ex., sendo esta DAO implementada num Pacote (totalmente) fora do Domain.
Isso é o que deve ser. Mas não é isso que o Evans diz. Quando ele diz que "pode" significa que o repositorio pode ser o proprio dao ou o proprio entitymanager. Significa que o repositorio pode ser uma interface implementada pelo DAO. etc... o numero de aberrações possivel é imenso.
O ponto é que tudo isso são implementações erradas do padrão Repository.
O problema é que as pessoas confundem "Repository" o padrão com "repository" do DDD. Enquanto todos as implementações do padrão repository são repositorios-DDD nem todos os repositorios-DDD são implementações do padrão Repository ( por exemplo, List )
sergiotaborda wrote: O Repositorio ( padrão Repository) inventado pelo fowler não pode ser um DAO, nem Lista, etc.. e isso é explicito no padrão. O ponto é : não confie muito na nomenclatura definida pelo Evans e muito menos a generalize.
Bem, isto já um questão intrerpretativa sua.
Não. É uma conclusão que vc mesmo pode chegar estudando o trabalho de ambos. Mas leia o livro do evans não o exceto num site.
|
|
|
|
xdraculax wrote:Então, se eu uso o for, e dentro do for eu acesso o elemento de uma LinkedList pelo índice, significa que na execução do get, a iteração vai percorrer todos os elementos da LinkedList até o índice da iteração atual do MEU loop, correto?
Estou perguntando porque já vi isso em uns códigos aqui, e não reparei nisso.
Quando vou fazer iteração com loop (se for um ArrayList) eu uso o:
for( Tipo t: coleção){...}
Nesse caso, ele use o iterator para percorrer os elementos da lista?
Sim. Mas veja que na realidade o for extendido é uma operação especial do compilador.
Ele compila codigo diferente conforme o objeto iterado é um array ou um Iterable. qualquer Iterable pode ser usado, não apenas Collection e Map e suas filhas. Vc pode criar objetos que são naturalmente compostos e iterálos facilmente, exemplo
no caso aqu teriamos a classe Pedido que implementa Iterable<ItemPedido>
|
|
|
|
|
|