As secoes dentro de “topicos de orientacao a objetos” não vão ser muita novidade para quem já leu o Effective Java (com excecão do DDD e modelo anemico). E isso deve ser frequente com desenvolvedores mais experientes e mais familiarizados com a plataforma Java: algumas seções serão muito proveitosas, outras já serão de seu conhecimento, pois o livro é baseado muito na nossa experiencia com o GUJ, blog da caelum, consultoria, etc, e pessoas como voce tambem participaram disso :)!
abracos
[/quote]
Eu estou achando o livro até engraçado, falando da parte de experiência do GUJ. Explico:
Lendo o capítulo de imutabilidade, enquanto lia a primeira parte fiquei pensando “É, um dos melhores exemplos de imutabilidade é a classe String, todos os métodos aproveitam mesmo array de caracteres, e só muda de onde começam e onde termina, bem que poderiam falar disso.”
Uma página depois, pimba.
Quase todos os capítulos estou tendo esse sentimento de ler a primeira parte e saber o que vem a seguir. Acho que estou passando tempo demais com vocês.
Quanto a possíveis erros de ortografia etc. detectados podemos utilizar este tópico para informar aos autores? ou preferem por e-mail, mp, etc ?[/quote]
Pode mandar por email, ja recebemos duzias deles, assim como da outra vez :).
Uma questão à se pensar, o livro direciona à Frameworks que envolve o Core J2EE/JEE, mas e fora dele o que vai falar sobre outras plataformas que já são tendências de Mercado, a visão de arquitetura não poderia ter uma independência da Plataforma Java, mesmo porque Servidores de Aplicações podem rodar outras especificações que se comunicam por J2EE.
Sobre o que aborda determinada metodologia Ágil e como promover DDD, TDD, FDD, BDD em meios de padrões, como decidir com precisão para que padrão devo recorrer na hora de questionar determinada implementação pelo processo de desenvolvimento.
[quote=Sergio Lopes]Oi pessoal!
Não sei dizer se vamos ter uma versao em PDF, vou ver com a editora.
[]'s e obrigado pelo feedback!
Sérgio[/quote]
Se uma versão em PDF do Livro for liberada ao publico, acredito que vai ser de bom agrado à todos, ampliaria mais o acesso a informação, e ajudaria a fazer uma segunda edição do livro com mais riqueza de detalhes e aperfeiçoamento, devido a um numero maior de leitores.
No site (http://www.arquiteturajava.com.br/) está escrito:
"Previsão de lançamento: 1o Semestre de 2010"
está parecendo no site 10!
os tópicos são muito bons. Aguardo ancioso pelo lançamento.
[quote=Adelar]No site (http://www.arquiteturajava.com.br/) está escrito:
"Previsão de lançamento: 1o Semestre de 2010"
está parecendo no site 10!
os tópicos são muito bons. Aguardo ancioso pelo lançamento.
[/quote]
Poisé, fiquei confuso, daí vim desenterrar esse tópico.
Tirei o dia pra ler os capítulos liberados e fiquei ansioso pela versão final, com certeza serei um dos primeiros compradores.
Gostaria de deixar uma sugestão:
como se trata de um livro sobre arquitetura e design de software, seria interessante ter um capítulo explicando exatamente o que é cada um, quais as fronteiras e quais as responsabilidades de um arquiteto e projetista. Também trocaria o design do título por projeto, como utilizei antes. Acho que não há necessidade de usar o termo em inglês nesse caso.
[quote=fabiocsilva]Gostaria de deixar uma sugestão:
como se trata de um livro sobre arquitetura e design de software, seria interessante ter um capítulo explicando exatamente o que é cada um, quais as fronteiras e quais as responsabilidades de um arquiteto e projetista. Também trocaria o design do título por projeto, como utilizei antes. Acho que não há necessidade de usar o termo em inglês nesse caso.[/quote]
Sem querer me meter mas já me metendo…
A pergunta é boa mas a melhor resposta é “depende”.
Na área de arquitetura:
Dizemos projeto de arquitetura. É assim que falamos quando contratamos um arquiteto para projetar nossa casa.
Arquiteto faz o projeto, então é o projetista. Antigamente costuma-se chamar de projetista àquele que faz o desenho concebido pelo arquiteto. Isso antes de existir o Autocad. Hoje o Arquiteto senta no computador, cria o projeto e ele mesmo desenha.
E na área de TI?
A mesma coisa. O arquiteto faz o projeto e ele mesmo o detalha.
E onde entra o "depende"que falei?
É que na nossa área acho errado separar as funções tipo fulano só faz isto, beltrano espera fulano acabar para começar. Em muitas equipes o projeto é feito pela equipe em reuniões. O arquiteto ou projetista não fica isolado em uma torre de marfim (já li isto… tem gente aqui que vai lembrar…). Ele é mais um na equipe.
Escrevi “depende” porque ainda há lugares em que existe o arquiteto na torre de marfim como se fosse a rainha do formigueiro. Mas não quero falar sobre isto. Não é assim que acho que devam ser as coisas.
Acho que divaguei. Se não entendeu, saiba que eu também não… porisso nem reli…
O livro tem uma discussão boa sobre o que é Arquitetura, o papel do Arquiteto, onde entra o Design e etc. É bem na linha do “depende” mesmo, já que não há consenso sobre esses termos e há muita discussão. Mostraremos pontos de vista diferentes, como do Fowler e outros.
Para quem esteve no CaelumDay BSB esse sábado, o Paulo Silveira apresentou uma prévia dessa discussão no início do evento. Para os outros, aguardem o livro
E nem que em inglês projeto = design mas design tem outros significados além de projeto. Em engenharia o projeto vem sempre antes da execução e no texto do Fowler está escrito: Design is part of the programming processes and as the program evolves the design changes. Em TI o design evolui.
Prefiram ler a versão original.
Lendo dá para perceber diferença entre os termos sob o ponto de vista do Fowler. Aliás este é um dos mais importantes artigos do Fowler. E ele voltou ao tema na apresentação deste ano em http://universite-du-si.com/fr/conferences/6/sessions/909
