Effective java 2

Continuando a minha saga através do livro Effective Java de Joshua Block, vou agora comentar item 2 do Livro (Executando o singleton através de construtores privados).

Singleton é um padrão de projeto que estabelece que uma classe só poderá ter um único objeto instanciado, esse é um padrão relativamente comum, por isso, há muita polêmica em torno dele, muito acreditam que o uso do singleton descaracteriza a orientação a objeto. Eu acho que não é bem assim, o que aconteceu com o singleton foi um mal muito comum em computação, ele virou moda, e por ter se tornado moda, muita gente abusou do seu uso, isso é uma coisa legal do Effective Java, o singleton é bastante abordado, com isso podemos fazer o uso correto desse padrão de projeto.

Basicamente temos duas alternativas para o uso de construtores privados. A primeira consistiria em deixar um instância da classe definida como estática, publica e final, mantendo o construtor privado. A segunda consistiria em manter uma instância estática e privada, fornecendo um método estático e publico para o acesso a instância, evidentemente, assim como na primeira alternativa devemos deixar o construtor como privado.

A principal vantagem da primeira alternativa é clareza na implementação do singleton, pois é um pouco óbvio que uma classe que não tenha construtores e uma instância da própria classe como pública, estática e final, pois o fato desse objeto da classe ser final, de certa forma denúncia um singleton.

A principal vantagem da segunda alternativa é possibilidade de ser fazer novas coisas através do método estático e publico se obter a instância. Por exemplo, poderia se escolher um construtor diferente ou controlar o número de instâncias como em um pool de objetos.

Um aspecto que pode causar desconforto no uso do singleton é na serialização de objetos, a simples implementação da interface Serializable pode não ser suficiente, entretanto, vou deixar para tratar os pormenores desse assunto mais adiante.

Effective Java 1

Fiz esse blog para tratar dois assuntos, basicamente, Computação e Informação, quando eu digo informação, estou falando de ciência da informação, ainda não falei nada de computação, então esse será o primeiro de um série de post sobre o livro “Effective Java” de Joushua Block, pq cho que esse é um bom pretexto para falar de uma das coisas que eu mais gosto, programação de computadores.
Embora esse seja um livro de Java, ele poderia muito bem se chamar Effective SmallTalk, ou Effective Rubi ou Effetive qualquer outra linguagem da Orientação a Objetos, pois acredito que esse livro que fale muito mais de Orientação a Objetos do que qualquer outra coisa, como por exxemplo, os detalhes da sintaxe Java. O livro é divido em 57 tópicos, vou comentar cada um deles sobre meu ponto de vista. O primeiro tópico é o seguinte “Considere fornecer métodos státicos para fabricar objetos ao invés de um construtor”.
A primeira boa razão para se fazer isso é: métodos abstratos tem um nome, diferentemente dos construtores que devem ter o mesmo nome do que a classe, por exemplo, considere os dois exemplos a seguir: a classe cachorro usa um contrutor Cachorro() e a classe gato usa um método statico novoGato(), o nome do método novoGato() é muito mais intuitivo que o contrutor Cachorro(), mesmo que esse método não tivesse nenhum comentário ou JavaDoc, ficaria muito fácil de saber o que ele faz.

public class Cachorro{
public Cachorro(){
}
}

public class Gato{
public static Gato novoGato(){
return new Gato();
}
}

A Segunda razão para se usar métodos státicos para criar objetos, o invés de usar construtores é: Em um método stático vc não é obrigado a criar um objeto novo toda vez que o método é chamado. A aplicação para isso é o popular partten singleton, mas outras aplicações para isso com certeza pode sem implementas, dependendo, é claro do escopo do projeto que vc esteja trabalhando.

A terceira razão para se utilizar métodos estáticos para a criação de objetos é que eles podem retornar objetos de qualquer tipo que seja subclasse da classe em questão, isso sim, dá uma grande liberdade ao desenvolvedor, enquanto está trabalhando em seu projeto. A API de colletions nativa do Java usa e abusa dessa idéia.

Mas como tudo na vida, há desvantagens de se usar métodos estáticos para criar objetos, são elas: classes que não tenham seus construtores públicos (public) ou protegidos (protect), como é o caso da implementação do singleton, não poderão gerar sub-classes. Métodos státicos usados para criar novos objetos são iguais aos outros métodos estáticos, não há nada que os diferencie dos outros métodos státicos.

Arquisteps

Olá pessoal, hoje vou apresentar o resultado do meu trabalho de conclusão de curso no curso de bacharelado de Biblioteconomia e Documentação na Escola de Comunicações da Universidade de São Paulo e Artes, o Arquisteps.
O Arquisteps é um programa desenvolvido em Java e C, como uma função bem simples, auxiliar na elaboração do Plano de Classificação e Tabela de Temporalidade, esta é uma versão beta, com alguns bugs, por isso, não recomendo o uso comercial do programa, todavia, estou precisando de ajuda: sugestões de melhorias, relatórios de bugs e claros desenvolvimentos, serão muito bem vindos.
O programa e o manual do usuário podem ser baixados no link abaixo:

Instalador do Arquisteps

Winisis benção ou maldição?

Com o Winsis dá para construir planilhas compatíveis com o Marc, já ouvi muito bibliotecário falar que não gosta do Marc, mas pó, se vc é bibliotecário e não gosta de padrão, é melhor vc usar um sistema de locadora, pelo menos o empréstimo vai funcionar legal. A interface num é problema, dá pra custumizar, não o suficiente, pelo menos pra mim, mas dá pra customizar. Outra coisa é a confusão com os nomes, Winisis não é Microsis, Winisis não roda em linha de comando, o Microsis sim. Aliás eu gosto de linha de comando, o mysql até bem pouco tempo atrás só tinha linha de comando, mas admito usar a linha de comando com destreza é coisa de usuário avançado, tem um ponto muito bom no Winisis, o arquivo invertido, ele indexa texto muito bem, se vc pegar um sisteminha qualquer, desenvolvido com banco de dados relacionais (mysql,postgree,oracle,sqlsever) em que o cara fique usando “Select * from table where like %text%” a performace vai para a meretriz que deu a luz e os sistema vai ser uma porcaria, o cara vai ter de fazer um banco muito bem feito, com vários index, enfim, não é coisa para amador.
Por outro lado dão muita ênfase ao Winisi nos cursos de Bibliotecnomia, acho que o maior problema não é o Winsis em si, o maior problema é ter o Winisis como única opção, quando foi criado, o Winisis era uma ótima ferramenta, entretanto, existem hoje várias tecnologia como: open-url, Haverst de metadados, FRBR a até mesmo os já batidos z39.50, circulação de material e DSI são razões para não se usar o Winisis em uma biblioteca séria. Entretanto, existem algumas consultorias que fazem um bom trabalho com o Winisis e até fazem com que algumas das suas precariedades sejam relevadas, mas infelizmente, algumas vezes, chamar uma consultoria tira do Winisis um o seu maior ponto positivo, ele deixa de ser gratuito, pois vc tem de pagar pela consultoria.
Enfim, o que vc acha, o Winsis é uma benção ou maldição?