Hoje na faculdade estava vendo o código de um colega que está aprendendo PHP e comecei a discutir com ele algumas melhorias, o resultado final foi tão satisfatório e diferente do original que resolvi criar um post pra mostrar como o código evoluiu.

O código original - Orientado à objetos ou PHP estruturado?

O código original já estava dentro de uma classe, mas não faria diferença nenhuma se fosse PHP estruturado… não lembro exatamente o nome dos métodos/variáveis, mas o restante está igualzinho:

A primeira mudança foi trocar esse switch, que não está fazendo nada além de definir o valor da variável $bool como true ou false se o $type for um dos valores válidos (jpg, png ou gif)… Nada melhor então do que usar a função in_array():

WOW! Reduzimos de 21 para 7 linhas… mas ainda assim, se fosse estruturado não teria diferença nenhuma.

Meu amigo me disse que essa classe seria para verificar os tipos de arquivos (extensões), por exemplo “se é uma imagem” ou “se é um doc”… Então criamos outro método para verificar DOCs:

Atributos, melhor tê-los

O código está melhorando, mas ainda assim tem algo errado… não é responsabilidade dos métodos fImage e fDoc saber a lista de extensões válidas… isso não deveria pertencer à classe como um todo e poder ser reutilizado?

Atributos e métodos estáticos

Agora sim está parecendo uma classe normal, com atributos e métodos… Aí percebi que de orientada à OBJETOS essa classe não tem nada! Não estamos trabalhando com objetos.. O uso atual dessa classe seria assim:

Eu não trabalho o objeto $cFileType, apenas instancio e utilizo um único modo… então vamos economizar um pouco de memória, transformando os métodos em métodos estáticos:

E agora a utilização ficou um pouco mais simples:

Sendo que você ainda pode usar o cFileType::image (pra ter uma lista de imagens válidas) em qualquer parte da sua aplicação sem instanciar a classe.

Reutilização de código

Segundo a abordagem DRY, não devemos nos repetir… Por isso aquele in_array() começou a me incomodar… Vai que você está verificando 30 tipos diferentes de arquivos, todos os métodos fazendo exatamente a mesma coisa… mas aí você decide mudar o in_array() pra algo mais eficiente ou aceitar até o caminho absoluto de um arquivo… vai mudar em 30 métodos na mão?

A responsabilidade de verificar se o valor $type tá dentro de uma “lista” válida não é dos métodos fImage e fDoc.. então vamos delegar:

Agora se precisarmos mudar essa lógica de verificar se o $type tá dentro de uma “lista” válida, só vamos precisar mudar em um lugar só.

cFileType? fType? fImage? O resultado final

Temos que concordar que os nomes de classe e métodos escolhidos pelo meu amigo não são os mais intuitos… Então como uma modificação final, sugiro a seguinte classe devidamente renomeada:

Com uma utilização bem simples e intuitiva:

Espero que tenham gostado! :)

Pra quem quiser ver o código completo da classe final, com os métodos comentados: https://gist.github.com/1338259