Classe só com métodos static

[Filipe_Moraes 15]

Olá pessoal.

Desenvolvi uma classe que controla o idioma de um site.

A minha questão é que a classe só tem métodos "static", não seria melhor usar funções no lugar de uma classe?

 

Porém dentro da classe os métodos precisam aceder outros métodos, não para alterar o estado das variáveis (nessa classe não existe, até porque só tem método static), mas para fazer validações, ou seja, esses métodos retornam sim/não.

Para usar esse métodos não posso usar o "$this->" então tenho que fazer "language::metodo_que_valida()".

 

Bom, a meu ver o código fica mais elegante com classe, mas a nível de performance, é igual?

Agradeço a vossa ajuda.

[Henrique Barcelos 290]

Se sua classe tem só métodos estáticos, então você não está utilizando orientação a objetos de fato.

 

Bom, a meu ver o código fica mais elegante com classe, mas a nível de performance, é igual?

Não acho nada elegante um monte de:

Classe::metodo()

=P

 

Ao que tudo indica, você projetou errado essa classe. Poste o código para darmos uma olhada.

[Filipe_Moraes 15]

Olá, obrigado pela sua ajuda.

Então, por isso perguntei se seria melhor fazer por funções... :grin: com certeza não projetei bem essa classe.

 

Vou explicar como está o sistema de idiomas.

- Não estou armazenando na base de dados os textos, antes estou colocando em arquivos ".ini", porque nem sempre a melhor solução é a base de dados.

- Cada página tem o seu arquivo ".ini" correspondente, assim só carrego para a página as variáveis necessárias, colocar todos os textos em um só arquivo não seria a melhor prática.

- O nome do arquivo é composto pelo código do idioma + nome da pagina, exemplo: "pt-BR.contacts.ini"

- O método "setUserLocale" da classe "language" é responsável por armazenar em cookie e em sessão o idioma escolhido pelo utilizador.

- O método "localeExist" verifica se o código do idioma é válido para o sistema, ou seja, verifica se temos os arquivos de tradução para esse idioma.

- O método "getLocaleDefault" captura o idioma padrão do site caso o idioma informado não exista em nosso sistema.

- O método "openFile" abre o arquivo de tradução correspondente, de acordo com o idioma e a página requisitada.

 

 

Veja me código como ficou:

class language{
      public static function setUserLocale($_locale){
	$cLocale = strreplace($_locale);
	$expire = time()+60*60*24*30;

	if(!language::localeExist($cLocale)){$cLocale = language::getLocaleDefault();}

	$_SESSION['LOCALE'] = $cLocale;
	unset($_COOKIE['locale']); 
        setcookie('locale',null,-1);
	setcookie('locale',$_SESSION['LOCALE'],$expire,'/',' ',null,true);


}

private static function getLocaleDefault(){
	$locale = parse_ini_file(PATH_LANGUAGE.'/locale.ini');
	return $locale['DEFAULT'];
}

private static function localeExist($_locale){
	$locale = parse_ini_file(PATH_LANGUAGE.'/locale.ini');
	$aLocale = explode(",",$locale['LOCALE']);
	if(in_array($_locale,$aLocale)){return true;}
	return false;
}

public static function openFile($_page){
	$page = strreplace($_page);
	$file = PATH_LANGUAGE.'/'.$_SESSION['LOCALE'].'.'.$page.'.ini';
	if (file_exists($file) && is_readable($file)){
		return parse_ini_file($file);
	}else{
		die;
	}
}
}

 

Ficou grande... :blush:

Agradeço a sua ajuda!

[João Batista Neto 448]

...não seria melhor usar funções no lugar de uma classe?

 

É exatamente o que você está fazendo. A classe, nesse caso, está servindo apenas como um namespace para suas funções.

 

Bom, a meu ver o código fica mais elegante com classe, mas a nível de performance, é igual?

 

A nível de performance, é indiferente. Agora, o que o leva a achar mais "elegante" a utilização errada de um conceito?

 

com certeza não projetei bem essa classe.

 

Fato!

 

Trabalhar com localização não envolve apenas a tradução de textos. De fato, existem N outros pontos que precisam ser considerados, como data, moeda, cultura/costumes, etc.

 

Seu participante de localização deve, necessariamente, ser capaz de representar esses aspectos.

 

- Não estou armazenando na base de dados os textos, antes estou colocando em arquivos ".ini", porque nem sempre a melhor solução é a base de dados.

- Cada página tem o seu arquivo ".ini" correspondente, assim só carrego para a página as variáveis necessárias, colocar todos os textos em um só arquivo não seria a melhor prática.

- O nome do arquivo é composto pelo código do idioma + nome da pagina, exemplo: "pt-BR.contacts.ini"

- O método "setUserLocale" da classe "language" é responsável por armazenar em cookie e em sessão o idioma escolhido pelo utilizador.

- O método "localeExist" verifica se o código do idioma é válido para o sistema, ou seja, verifica se temos os arquivos de tradução para esse idioma.

- O método "getLocaleDefault" captura o idioma padrão do site caso o idioma informado não exista em nosso sistema.

- O método "openFile" abre o arquivo de tradução correspondente, de acordo com o idioma e a página requisitada.

 

Veja: http://userguide.icu-project.org/locale/resources

[João Batista Neto 448]

Lendo este tópico achei um dos se não o mais importante até agora. O fato é que estrutura não é só os participantes (objetos) isolados se comportarem de maneira correta e sim o projeto como um todo deve ser planejado.

 

Ao criar um projeto é como criar uma empresa e como tal devo prever o máximo que eu puder, os riscos, a comunicação desde os membros até o usuário final(Cliente).

 

Um projeto mal estruturado é um modelo que segue o conceito do "vou fazendo" e isso é fatal pois você não saberá como os objetos se comunicarão uma vez que, você não sabe qual será o próximo passo.

 

+1 por este trecho!

 

Belíssima colocação. Principalmente em relação ao fragmento "é como criar uma empresa" até o restante da frase. Muito bom mesmo!

 

Você não entendeu o que é orientação a objetos, $this é o próprio objeto, ou você não se lembra que em Java script usamos:

 

Não seria o próprio objeto, mas uma referência a ele. Chegou bem perto, mas não é exatamente isso.

 

Você tem que usar object::static por que vai chamar um método várias vezes e seria incomodo fazer $new object o tempo todo.

 

No PHP, o Paamayim Nekudotayim é utilizado como resolução de escopo, acesso a membros estáticos e constantes de classe. Na prática, seu uso deve ser evitado ao máximo, uma vez que, ao utilizá-lo, existe uma referência explícita à classe que declara o membro. Isso significa que, ao utilizar membros estáticos, você passa a estar limitado em sua utilização, violando o princípio de design D.I.P.. De fato, melhor seria passar a referência ao objeto que será utilizado, do que referenciá-lo explicitamente no participante que o utiliza.

 

Notei que você deve chamar estes methods por todos os seus scripts, isto acontece porque você não está usando

Singleton.

 

o.O

 

class language extends languageSettings{

 

Vejo esse fragmento, pela própria nomenclatura dos participantes, como uma clara violação ao S.R.P.. Language USA LanguageSettings. Esse fragmento, pela nomenclatura, é tão errado quanto fazer class Person extends Database, é um erro gravíssimo do ponto de vista da orientação a objetos.

 

Note que aqui " construct( $language ) " eu não usei "language $language" para que você não se torne dependente do objeto que configura o idioma.

 

O acoplamento, nesse caso, ocorreria apenas pelo fato de Language ser uma classe concreta.

 

Ocorre que orientação a objetos trata-se, na verdade, de confiança. O relacionamento entre os participantes ocorre, exatamente, porque um participante sabe os limites das responsabilidades dos outros participantes. Esse conhecimento se dá através da interface do objetos e, sendo assim, ao especificar a interface no construtor, você estará garantindo que o objeto possa confiar no outro, sem ter que checar se o que foi recebido é, de fato, aquilo que era esperado.

 

Melhor seria, se o código demonstrado fosse:

 

interface Language {
//...
}

class ConcreteLanguage implements Language {
//...
}

class SomeClassThatUsesLanguage {
private $language;


public function __construct(Language $language) {
   	$this->language = $language;
}

public function doSomething() {
   	echo $this->language->getString('something');
}
}

$language = new ConcreteLanguage();
$object = new SomeClassThatUsesLanguage($language);

 

Como pode perceber, o acoplamento que você diz no seu exemplo, só ocorre devido à referência explícita à classe concreta Language.

 

class MinhaClassParaLerUmBanco extends language{

 

Novamente, uma violação clara ao S.R.P.. Tome cuidado com isso, Wercks!

[João Batista Neto 448]

object::static é apenas para compreensão do que nosso amigo estava fazendo e não que estou sugerindo.

 

De fato, eu havia compreendido exatamente o inverso do que você estava dizendo. Mas agora, relendo seu texto, consegui entender o que você disse.

[João Batista Neto 448]

Gostaria que você editasse a parte que você me confunde com alguém sem experiência.

 

Não compreendi.

[João Batista Neto 448]

Não seria um erro que um cara que contribui com o PHP iria cometer, imagine alguém lendo isso um dia e falar nossa! olha o erro que Wercks cometeu aqui, posso perder minha credibilidade de anos em uma frase.

 

Editei por ser irrelevante. Mas mantive a parte que possui conteúdo útil para o autor do tópico.

 

Uma credibilidade não se destrói com uma coisa tão boba., ainda mais, porque a thread seguiu e a retratação está em um post logo abaixo.

 

Mas, de fato, o que me motivou a escrever aquele post, nem foi o object::static, mas os seguintes fragmentos:

 

Notei que você deve chamar estes methods por todos os seus scripts, isto acontece porque você não está usando

Singleton.

 

class language extends languageSettings{

 

class MinhaClassParaLerUmBanco extends language{

 

Sou bastante chato, quando o assunto é OOD. Não é nada contigo, é que acredito, veementemente, que design é algo extremamente delicado.

[Filipe_Moraes 15]

A nível de performance, é indiferente. Agora, o que o leva a achar mais "elegante" a utilização errada de um conceito?

 

Olá João.

Até então não estava na minha cabeça a utilização de um conceito errado.

Concordo, ao olhar para o meu código reparei que não ficou bom, não ficou profissional, o que me levou a pedir a vossa ajuda (que considero muito importante).

 

Ao olhar para o conceito de orientação a objeto, realmente não faz sentido o que eu fiz, é como se colocasse rodas de bicicleta em uma moto :grin:/>

 

O que mais dizer dessa bizarrice? É aprender e aperfeiçoar, eu chego lá!

 

Agradeço a vossa ajuda ( foi importante ), irei refazer o meu sistema de idiomas.

[João Batista Neto 448]

O que mais dizer dessa bizarrice? É aprender e aperfeiçoar, eu chego lá!

 

:D

 

hehehe, faz parte! Bizarrices a parte, você tem um conjunto de requisitos bacana:

 

- Não estou armazenando na base de dados os textos, antes estou colocando em arquivos ".ini", porque nem sempre a melhor solução é a base de dados.

- Cada página tem o seu arquivo ".ini" correspondente, assim só carrego para a página as variáveis necessárias, colocar todos os textos em um só arquivo não seria a melhor prática.

- O nome do arquivo é composto pelo código do idioma + nome da pagina, exemplo: "pt-BR.contacts.ini"

 

Deixo apenas um comentário para o "Cada página tem seu arquivo .ini". Alguns termos utilizados, são comuns para N "páginas". Dessa forma, prefira trabalhar mais baixo nível, lidando com strings, em vez de páginas completas. Essa abordagem com strings é bastante interessante se você for trabalhar apenas com países, cuja leitura é da esquerda para a direita.

 

Leia todo esse artigo, ele é bastante interessante para seu propósito: http://docs.oracle.com/javase/tutorial/i18n/TOC.html

[Filipe_Moraes 15]

Sou bastante chato, quando o assunto é OOD. Não é nada contigo, é que acredito, veementemente, que design é algo extremamente delicado. 

Olá mais um vez.

Realmente é algo que se deva dar muita importância, até mesmo para um pequeno trabalho, afinal, é de pequeno que se aprende! :grin:

 

Obrigado João e Wercks, pela vossa ajuda.

[01100011cc 15]

Pra finalizar estou muito feliz por ter a chance de está nesta discussão bonita e construtiva para todos.

 

Não querendo ser chato, mais sendo realista, bastava as primeiras respostas de ambos, depois dela, vejo apenas uma briga sem sentido, um querendo mostrar os erros dos outro, e o outro querendo se opor porem apoiando e não aceitando o que o outro quer dizer...

 

sendo mais objetivo, quiz dizer: Discussão nada bonita e pouco construtiva.

[Filipe_Moraes 15]

Bom, queria postar o resultado.

Ficou da seguinte forma:

-> Estruturei um conjunto de pastas para separar por código do idima/região, ficou assim:

.language

..pt (codigo do idioma)

....br (região)

....pt (região)

..en (codigo do idioma)

....us (região)

....gb (região)

 

-> Cada região contem um ficheiro "define.ini" que possui algumas configurações, como moeda, formato de data, etc...

-> A classe que postei no primeiro post troquei pela seguinte função:

--> Uma função para identificar o código do idioma e região do utilizador, se caso não existir a região do utilizador, o sistema buscará uma mais próxima, por exemplo, imagina que tenho o código do idioma "pt" e a região "BR", mas alguém de Portugal acessou o site, o sistema identifica que existe algo em "pt" mas não tem a região "PT" (que representa Portugal), então usará os ficheiros para a região "BR", que é o mais próximo.

 

Existe também funções de apoio, como buscar o código do idioma padrão caso não exista do cliente, função para buscar a região padrão, verificar se os dados do cookie são válidos (porque salvo em cookie caso o utilizador volte ao site), etc...

 

Bom, foi só para dizer que acabei com a classe, passei a respeitar a região do utilizador, levando em conta formatações como data, moeda, etc... mas mantendo o sistema de arquivos ".ini", que considero melhor do que gravar em base de dados.

 

Obrigado pela vossa ajuda.