Ouvi e já pude ler isto não uma, nem duas, mas sim diversas vezes. Argumentação padrão de quem defende uma “Orientação à Objetos mais estática” – se é que podemos chamar isso de OO.

Vejamos um exemplo nada científico que fiz:

Criei os seguintes exemplos:

<?php
class Estatico {

    public static function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
           echo Estatico::outraCoisa();
           $i++;
        }
    }

    public static function outraCoisa() {
        return "Conteúdo";
    }
}

Estatico::fazAlgumaCoisa();

<?php
class Instancia {

    public function fazAlgumaCoisa() {
        $i = 0;
        while ($i < 10000) {
            echo $this->outraCoisa();
            $i++;
        }
    }

    public function outraCoisa() {
        return "Conteúdo";
    }
}
$objInstancia = new Instancia();
$objInstancia->fazAlgumaCoisa();

Os resultados após rodar quatro vezes cada foram:

Ou seja: 91.09 ms para o estático contra 90.07 para a versão non-static. Obviamente foi apenas um teste sem qualquer relevância, pois rodei em minha máquina pessoal com várias outras aplicações rodando em background. É perceptível porém, que a diferença não é absurda que compense o uso de estático por este motivo.

Deixando a questão de “performance” de lado, partimos para questões arquitetônicas:

• Identidade
• SoC – Separation of Concerns (Principio de Separação das Responsabilidades)
• Encapsulamento
• Estado
• DRY – Don’t Repeat Yourself
• Associações – sejam elas composições ou agregações

Ao perder Identidade e Estado as possibilidades daquele método – ou da classe inteira, caso use estático em tudo – tem o leque de utilidade reduzido para:

• Service
• Facade
• Factory
• Helpers – no âmbito de serem apenas funções que realizam determinada tarefa na aplicação sem qualquer valor ao Domínio

Com isso, perdemos também o Princípio de Separação das Responsabilidades, ou seja, a classe perde o controle sobre a integridade dos dados que ela deveria controlar e proteger contra acesso ou alteração indevidos.

Listei o DRY também por um motivo simples: com métodos estáticos, perdemos a grande chance de usar as variáveis de instância da classe à favor da mesma. Exemplo:

class UsuarioEstatico {

    public static function login($usuario, $senha) {
        // valida o usuário e zaz
        $autenticador = new Autenticador();
        $autenticador->autentica($usuario, $senha);
    }

    public static function logout($usuario) {
        // verifica se a sessao está aberta
        $autenticador = new Autenticador();
        $autenticador->fechaSessaoPara($usuario);
    }
}

class Usuario implements Autenticavel {
    private $autenticador;

    public function __construct($usuario, $senha) {
        // manipula os dados de entrada
        $this->autenticador = new Autenticador($this);
    }

    public function login() {
        return $this->autenticador->autentica();
    }

    public function logout() {
        return $this->autenticador->fechaSessao();
    }
}

Repare no modelo estático: foi necessário instanciar o antenticador por duas vezes em pontos diferentes. Opa, repetiu ! Mesmo que o autenticador fosse estático, teriamos duplicação, pois teriamos que certificar que o usuário existe e tudo mais. Isso porque não comentei como ficaria o lado cliente dessa implementação estática. O cliente – seja Controller, WebService ou qualquer classe em outra camada no domínio – teria que conhecer muita coisa sobre implementação dessa classe para poder manipulá-la.

Como bônus, repare que perdemos neste caso também o Polimorfismo, uma vez que eu poderia ter esse Autenticador() como base de autenticação para qualquer tipo (Usuário, Funcionário, Gerência, Administradores…)

O uso de métodos ou funções – sim, há diferença – estáticas pode ser bem-vindo nos itens já enumerados. Alguns developers porém, ainda que nestes casos são contra o uso por achar a ideia estática demasiadamente anti-oo.