Classe de funções comum no sistema

Programação Java
#1

Buenas pessoal!!!

Venho aqui com uma dúvida que até então nunca havia parado pra pensar.

Tem métodos que eu utilizo com bastante frequencia e em diversas classes/pacotes diferentes.

Em alguns casos eu duplicava o método na classe que eu precisava dele, em outros casos eu dava um new na classe que o implementava e chamava o método (“new MinhaClasse().meuMetodo(…)”).

Hoje eu parei pra pensar um pouco nestes métodos.

Então me veio duas perguntas e gostaria de um respaldo de vocês…

1 - Será que é viável criar uma classe “FuncoesComum” e por tudo que é comum entre as classes lá (Tenho entre 20 e 30 métodos)?

2 - Se for viável, eu deveria criar métodos estáticos para não ficar instanciando toda vez que utilizar, ou faço métodos não estáticos e dou um new toda vez que for usar as funções?

Agradeço a opinião de todos :!: :!:

#2

Em meus programas costumo ter uma classe “Util”, só com métodos estáticos. Quando eu repito muito alguns métodos dessa classe Util, eu os jogo em uma biblioteca de utilitários.
Costumo também ter um pacote “util” quando tenho classes que não são do negócio e que são usadas por várias classes do aplicativo.

#3

Hmm… Obrigado pela opinião entanglement…

Logicamente acredito que um método só vai para esta classe se é muito utilizado, e por várias classes, então independente da quantidade de métodos implementados na classe, você os cria estático nesta classe Util? Ou aconselhas a utilizar somente as principais funções mesmo?

#4

Eu uso essa classe Util como um repositório de funções estáticas que são usadas no projeto e não são de negócio - por exemplo, um método que, dada uma java.util.Date, o retorna como uma String formatada no formato “dd/MM/yyyy” merece para mim uma função utilitária, já que eu vou usar isso no código inteiro :slight_smile:

Se alguma coisa precisa de uma classe para funcionar, crio uma classe :slight_smile:

#5

Hmm… Legal, tava indo na mesma linha de pensamento que você tem…

Tenho alguns métodos para validar data, hora, transformar hora em segundos, entre outra funções. Também tenho umas classes de manipulação de Strings, validação de objetos coisa e tal…
Acredito que para manter uma boa organização eu poderia criar uma classe UtilDate e outra Util, ou você botaria tudo na mesta classe?

#6

Pode usar várias classes - provavelmente se você tiver muitos métodos, vale a pena criar um “.jar” separado para usar em vários projetos seus.

Mas eu não uso muito isso, talvez porque sou muito preguiçoso e desorganizado .

#7

Novamente te agradeço o comentário…

Agora vem uma última dúvida…

O software que eu presto manutenção é multi-thread, é aconselhável que eu faça os métodos desta classe synchronized para evitar que mais de uma thread acesse o método ao mesmo tempo?

#8

Boa pergunta.

Usar “synchronized” sem saber o que está fazendo pode deixar seu sistema mais lento, porque você está efetuando sincronização desnecessária.

Por exemplo, um método utilitário como o seguinte:

public static String diaMesAno (int dia, int mes, int ano) {
    return String.format ("%02d/%02d/%04d", dia, mes, ano);
}

não precisa ser synchronized.
Na verdade, se um método estático usar apenas variáveis locais e parâmetros, provavelmente não precisará de sincronização.
Ele pode ter problemas se usar variáveis estáticas (em alguns casos, é necessário sincronizar o acesso a essas variáveis estáticas).

Dependendo do que você estiver usando, o correto é usar um ThreadLocal, não um synchronized.

Exemplo: as classes SimpleDateFormat e DecimalFormat não são “thread-safe”. Entretanto, tanto usar isto:

public static String formatarDataAtual() {
    return new SimpleDateFormat ("dd/MM/yyyy").format (new java.util.Date());
}

quanto

private static String formatarDataAtual () {
    return df.get().format (new java.util.Date());
}
private static ThreadLocal<SimpleDateFormat> df = new ThreadLocal<SimpleDateFormat>() {
    protected SimpleDateFormat initialValue() { return new SimpleDateFormat ("dd/MM/yyyy"); }
};

não têm problemas de “thread-safetiness” e não precisam (nem devem) ser synchronized.

#9

Muito interessante…

Eu desconhecia a ThreadLocal, depois de sua resposta fiz uma pequena pesquisa sobre o que ela faz, a explicação do ViniGodoy neste link http://www.guj.com.br/java/65183-threadlocal me deu uma breve noção sobre a mesma. Neste final de semana vou fazer mais umas pesquisas sobre a classe…

Em um caso como o abaixo, como eu poderia deixar o SimpleDateFormat acessível à apenas uma Thread por vez?

public class Exemplo {

	private static SimpleDateFormat dataBrasil = new SimpleDateFormat("dd/MM/yyyy");

	public static String getDataBrasil(Date date){
		if(date != null)
			return dataBrasil.format(date);
		return null;
	}

	public static boolean isDataValida(String data){
		try{
                        //Se eu usar o seu exemplo "getDf()" ao invés de dataBrasil este objeto será o mesmo do debaixo? ou eu deveria declarar um SimpleDateFormat aqui?
			dataBrasil.setLenient(true);
			dataBrasil.parse(data);
			return true;
		}catch(Exception ex){
			return false;
		}
	}
.
.
.(Vários métodos que utilizam o date format...)

	
}
#10