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