bibliotecas...

[criatividade zero 17]

queria tirar uma duvida sobre bibliotecas de arquivos...

se tivermos, por ex:

 

xml.php, cache.php, log.php

cada uma tem seu metodo de leitura/escrita de arquivos, o seria mais 'comodo' manter um file.php para gerenciar o trabalho com arquivos?

 

 

como trabalham com isso, qual padrão que vcs adotam?

[]s

[mangakah 217]

Como assim?

 

O que você quer dizer com "bibliotecas de arquivos"? Seria um sistema de gerenciamento de arquivos? Ou uma classe para tratar de leitura/escrita de arquivos?

 

Se for sobre gerenciamento de arquivos eu uso o do CPANEL ou então o excelente eXtplorer.

 

Caso se trate de uma classe para leitura/escrita, eu evito usar PHP para isso (muito arriscado), só mesmo para escrever logs de erros e olhe lá. Uso classes do Zend Framwork ou PEAR para isso.

[criatividade zero 17]

no exemplo das classes que dei acima...

xml.php, cache.php, log.php

 

todos os 3 fariam parte de uma biblioteca (library)

e todos os 3 teriam um metodo de escrita e leitura de um arquivo em questão

 

 

xml::read($file)
xml::write($file , 'conteudo')

cache::read($file)
cache::write($file)

...

 

e por ai vai

o que queria saber seria melhor manter a leitura e escrita dos arqivos na propria classe, ou usar uma classe file.php apenas para esse fim

 

 

class Cache
{
public static function read( $file )
{
	$fp = fopen( $file , 'a+' );
	fwrite( $fp , 'conteudo' );
	fclose( $fp );
}

--- OU ---

public static function read( $file )
{
	file::fopen( $file , 'a+' );
}
}

 

 

ficou mais claro?

é duvida simples

[mangakah 217]

O melhor mesmo é usar um framework. Mas... das duas opções que você deu, o melhor, na minha opinião, é não usar uma classe só para escrever e ler todo tipo de arquivo pois ela acabará ficando monstruosa e difícil de manter. Recomendo que você crie por exemplo uma classe Xml que abstraia tudo relativo a xml tanto leitura quanto escrita e derivadas dessa classe Xml_Write (para escrita) e Xml_Read (para leitura), além de Xml_Exception para tratar exceções, etc. Pense sempre no princípio da abstração.

[criatividade zero 17]

o xml, no caso, teria leitura e escrita como métodos separador

class Xml_Read e class Xml_Write, pois nem sempre ambos se fazem necessários...

posso apenas precisar ler um XML ou posso apenas gerar um XML

 

no caso do Cache

deveria ser class Cache com os metodos de read e write, pois ambos - nesse caso - se fazem necessário, ja que quando eu for ler o cache e não existir, eu vou cria-lo

 

isso seria correto o correto?!

 

 

 

abstração não era meu foco ainda, estou indo por etapas pra aprender melhor...

tenho muito ainda, não adianta querer aprender tudo de uma vez

como diz o ditado, devagar e sempre :D

[Bruno Augusto 417]

Assim, cada classe que precisa ler/escrever alguma coisa precisa invariavelmente de um método read/write,

 

Isso porque cada módulo lê/escreve os dados de um jeito diferente. XML, ecoa os nós com o texto devido,por exemplo.

 

Agora quando o resultado da escrita é exportado para um arquivo físico, isto é, da rotina que o cria NÃO vai dirto para a tela, você está trabalhando com Sistema de Arquivos.

 

Pensa comigo: Você repetiria MESMO as rotinas fopen/fwrite/fclose ou fopen/<while>/fread/fclose?

[mangakah 217]

Pensa comigo: Você repetiria MESMO as rotinas fopen/fwrite/fclose ou fopen/<while>/fread/fclose?

 

Eu simplesmente usaria file_get_contents() para ler e file_put_contents() para escrever. Não sei você, mas eu criaria outra classe só pra essas funções...

[Bruno Augusto 417]

Pois é, com essas duas funções podem e/ou devem ser usadas, mas esse não é o ponto do tópico, certo?

[mangakah 217]

Pois é, com essas duas funções podem e/ou devem ser usadas, mas esse não é o ponto do tópico, certo?

 

Bom... na minha opinião tem a ver sim, o tópico é sobre se a criação de uma classe só para tratar de escrita/leitura de arquivos é vantajosa ou não. Eu disse que não, você disse que sim e então eu rebati mostrando que as funções de leitura e escrita de arquivos podem ser feitas com apenas duas funções do FileSystem. A única coisa que faltaria, pelo menos que eu consigo lembrar agora, é a função 'append' (modo 'a' ou 'a+' da função fwrite) para adicionar linhas a um arquivo sem sobrescrevê-lo, mas isso só é usado para coisas muito específicas como escrever uma nova entrada no log, por exemplo, e poderia muito bem ficar numa classe Logging.

 

Se tem alguém saíndo do tópico não sou eu.

[Bruno Augusto 417]

Calma cara, não estou e ninguém está te julgando, estamos apenas debatendo.

 

Eu mesmo, durante muito tempo preferi essas duas funções.

 

Confesso que nunca cheguei a testar a performance delas em comparação aos trios citados, mas hoje prefiro usar minha classe de manipulação de streams, ao invés de manipular os arquivos.

 

Tenho um criador de streams, com suporte à contexts inclusive, e outras duas classes à parte, uma para leitura e outra para escrita, todas elas respeitando suas interfaces, facilitando o meu trabalho.

 

P.S.: file_put_contents() suporta sim append mode. Basta passar a flag FILE_APPEND no terceiro parâmetro.

[mangakah 217]

@Bruno Claro, se em meu último post deixei a inpressão de estar irritado essa é totalmente enganosa.

 

Ah, sim havia me esquecido do segundo parametro da função file_put_contents que suporta algumas flags... bem lembrado, mas o controle não é tão preciso como o uso de ponteiros e outros recursos da FileSystem.

[criatividade zero 17]

boas opinioes

50% pra um lado e 50 pro outro hehehehe

 

seguindo a questão da duvida inicial...

. quem escreve o log, quem escreve o xml

. quem lê o log, quem lê o xml

 

 

entendo que seria facil a manutenção, e etc...

mas vejamos, se hj eu tenho a classe log abaixo

 

class Log {
       public static function write() {
	File::write( $file );
       }
}
Log::write( 'arquivo_log.txt' );

 

 

se amanha eu precisar fazer o log disparar um email

teriamos que iniciar ou estender até a classe email.php?

 

 

não seria mais pratico ou eficiente manter os metodos proprios?

class Log {
       public static function mail() {
	...
       }
       public static function write() {
	File::write( $file );
	self::mail();
       }
}
Log::write( 'arquivo_log.txt' );

[mangakah 217]

Log

O seu exemplo não me parece um exemplo do mundo real. Não faz sentido enviar mensagens de log por email. Uma classe Log para logging só precisa fazer duas coisas, escrever no log e resgatar registros anteriores. Se necessitar extender: filtros, funções de processamento e geração de relatórios, etc. Mas email não...

 

Xml

Você vai usar XML para que? XML pode ser usada par muitas coisas, tais como WebServices, armazenar dados, armazenar parâmetros de configuração, armazer arquivos de idioma (Tmx, por exemplo) e cada uso desses requer uma classe diferente e uma maneira diferente de usar as funções das bibliotecas XML do PHP. XML é um formato, não uma tarefa, você faz classes para realizarem tarefas. Veja o caso do Zend Framework, ele tem a classe Config que abstrai todas as tarefas de ler/escrever parâmetros de configurações e deriadas dessa as classes Config_Ini (para parâmetros armazenados no formato INI), Config_Xml (para o formato XML), etc. Tem também a classe Translate para abstrair tudo relativo a traduções e adaptadores para cada um dos formatos usados para se armazenar strings de traduções (Tmx, Tbx, etc).

 

Cache

Só precisa gerar, verificar a validade e retornar o conteúdo em cache se ainda válidos. E adaptadores para cada uma das bibliotecas PHP para cache (memcached, Xcache, APC, etc).

 

Pra concluir, mesmo que enviar dados de log por email fosse interessante, você deve ter uma classe de email separada para isso, de qualquer forma você precisará ter uma, afinal vai usar email para muitas outras coisas, então por que não aproveitá-la?

[criatividade zero 17]

o caso que citei foi apenas um exemplo ficticio!

 

outro exemplo, seria referente a criptografia, hash - classes usuario e session

as 2 teriam metodos encriptar e reverso

seguindo a abstração, deveria ter uma classe separada para (hash.php) para encriptar e fazer o reverso?

pq não ter encriptar() e reverso() como metodo de cada classe?

[mangakah 217]

Uma classe Usuário só se for como modelo (mapa da tabela usuários no banco de dados). deveria haver aí sim classes de tarefas que os usuários fazem: Autenticação, Cadastro, GerenciarConta(alterar senha, recuperar senha, excluir conta, editar dados, etc) e Acl para listas de controle de acesso.

 

Classes sessão e criptografia separadas só se sua aplicação (agora ou no futuro) for usar esses recursos para outras coisas além de armazenar dados de login e criptografar senhas, respectivamente.

[criatividade zero 17]

Uma classe Usuário só se for como modelo (mapa da tabela usuários no banco de dados). deveria haver aí sim classes de tarefas que os usuários fazem: Autenticação, Cadastro, GerenciarConta(alterar senha, recuperar senha, excluir conta, editar dados, etc) e Acl para listas de controle de acesso.

não, não é um modelo do MVC

seria uma biblioteca, onde recupero informações do usuario, tipo de conta, etc...

 

 

Classes sessão e criptografia separadas só se sua aplicação for usar esses recursos para outras coisas além de armazenar dados de login e criptografar senhas, respectivamente.

então seria assim?

 

 

class Session {
       public static function cript() {
       }
       public static function decript() {
       }
}

class Usuario {
       public static function cript() {
       }
       public static function decript() {
       }
}

 

 

mas Log e Cache não contém um metodo de escrita?

class Log {
       public static function write() {
       }
}

class Cache {
       public static function write() {
       }
}

 

 

se Log->write() usar MD5 pra gerar um nome de arquivo, deveria abstrair uma classe Hash?

isso que não estou conseguindo compreender

[Bruno Augusto 417]

...mas o controle não é tão preciso como o uso de ponteiros e outros recursos da FileSystem.

E é por isso que prefiro não usar, de fato, essas duas funções e sim diretamente com as streams, que são "procuráveis" (ou seja lá qual for a melhor tradução para seekable).

 

Agora, criatividade zero, nesse você deveria abstrair as informações. Vou escrever de cabeça, desculpe se estiver algo errado:

 

AbstractLogger.php

<?php

abstract class AbstractLogger implements ILogger {

   protected $file;

   public function __construct( $file ) {
       $this-> file =& $file;
   }

   abstract public function read();

   abstract public function write( $data, $append = TRUE );

   public function getFile() {
       return $this -> file;
   }
}

ILogger.php

<?php

interface ILogger {

  public function getFile();
}

Com isso, cada tipo de Logger que você criar deverá extender essa classe abstract e deverá ter os métodos AbstractLogger::read() e AbstractLogger::write(), já que são abstratos.

 

Daí ficaria assim:

 

FileLogger.php

<?php

class FileLogger extends AbstractLogger {

   public function read() {
       return file_get_contents( $this -> file );
   }

   public function write( $data, $append = TRUE ){

       if( $append == FALSE ) {

           return file_put_contents( $this -> file, $data );

       } else {

           return file_put_contents( $this -> file, $data, FILE_APPEND );
       }
   }
}

Assim, quando você usar:

 

$logger= new FileLogger( 'log.txt' );

$logger -> write( 'Some data' );
$logger -> write( 'Some data is being appended' );

//...

var_dump( $logger-> read() );

[criatividade zero 17]

obrigadão pela explicação 'visual' :D

 

sem levar em conta os outros métodos necessários... para uma classe XML, deveria seguie esse esquema?

abstract class AbstractXml implements IXml {
}

interface IXml {
}

class FileXml extends AbstractLogger {
}

 

 

outra duvida que apareceu agora...

esse exemplo que você postou, eu via como uma classe unica com todos os metodos inclusos - como saber qual o melhor caso de se usar abstração, ja que eu via isso como uma classe simploria para uma lib?

 

 

no caso que citei, de Cache e Log, via como a União em matematica

ambos possuem um metodo de gravação write-> file_put_contents( $this -> file, $data );

julguei esse metodo write como AUB, como uma classe 'auxiliar' que pudesse ser separada para ser chamada dentro de cada uma como File::write()

 

nem tudo que tem o mesmo codigo (escrita, leitura), precisa ser dividido?

 

 

tenham paciencia com as minhas perguntas :D

[Bruno Augusto 417]

Então, mas eu acho que se você tiver suas classes cada uma fazendo aquilo que foi concebida para fazer vai facilitar uma futura manutenção.

 

Existe essa possibilidade que você falou, mas eu acho que ficaria bem menos flexível.

 

Nela você não teria uma classe abstrata, com métodos abstratos e sim todos eles prontos para utilização:

 

Logger.php

<?php

class Logger implements ILogger {

   protected $file;

   public function __construct( $file ) {
       $this -> file =& $file;
   }

   public function read() {
       return file_get_contents( $this -> file );
   }

   public function write( $data, $append = TRUE ) {

       if( $append == FALSE ) {

           return file_put_contents( $this -> file, $data );

       } else {

           return file_put_contents( $this -> file, $data, FILE_APPEND );
       }
   }

   public function getFile() {
       return $this -> file;
   }
}

Entendeu? Vai funcionar do mesmo jeito porém, imagine o cenário.

 

Você, dessa forma tem suporte a Log por TXT e indiretamente por todo tipo de conteúdo em texto plano (XML, INI, PHP...) mas e se de repente você precisar dar um UP no seu sistema, criando uma seção num possível Painel Administrativo em que o Administrador pode ver os logs deerro gerados e gerenciá-los via interface Web?

 

Para esse tipo de caso o seu Logger deveria de alguma forma acessar o banco de dados previamente conectado para enviar as informações certo? Mas veja que nessa última implementação você teria que começar a fazer gambiarras nervosas com condicionais desnecessários:

 

//...

   public function write( $method = 'file', $data, $append = TRUE ) {

       if( $method == 'file' ) {

           if( $append == FALSE ) {

               return file_put_contents( $this -> file, $data );

           } else {

               return file_put_contents( $this -> file, $data, FILE_APPEND );
           }

       } elseif( $method == 'bd' ) {

           // Obtém o link, efetua a consulta resgata o retorno e verifica se foi adicionado
       }
   }

//...

E o que você faria se quisesse mandar também por e-mail? Mais um condicional? E lembre-se que ficou pequeno aqui no exemplo, mas tem tod a rotina que vai aí no meio que pode fazer você perder os cabelos quando for dar uns tapas no código.

 

Em contrapartida, usando a abstração sugerida, cada lógica fica na sua própria classe, arrumadinha, com poucas linhas de código (facilita a manutenção) além ser super flexível, já que cada novo método de Log bastaria uma nova classe.

[criatividade zero 17]

então com a implementação e abstração, seguindo o molde do #17

poderia apenas criar DbLogger para fazer o instert na database como metodo alternativo à criação do file???

 

 

/* nova classe pra log no DB*/
class DbLogger extends AbstractLogger
{
public function write( $data, $append = TRUE )
{
	db insert ... ($data);
}
}

// escrevendo o log no DB
$logger = new DbLogger();
$logger -> write( 'Some data' );

// escrevendo o log no log.txt
$logger= new FileLogger( 'log.txt' );
$logger -> write( 'Some data' );

 

é isso?