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.

Você deve estar se perguntando: aonde você quer chegar ?
Simples: se tudo isso que citei é muito óbvio para você, meus parabéns ! Você deve ser um profissional preocupado com a documentação !

Sim, da mesma forma que você precisou ler para entender como funciona a API de reflexão nativa do PHP, o seu colega de projeto precisará ler a documentação daquele Webservice que você fez para o projeto.
Partindo da minha analogia, seu amigo precisa ter como pré-requisito: saber ler e conhecimentos em PHP para poder implementar x)

Pensamento óbvio o meu, claro, claro que sim ! Mas pensa aí rapidinho: quantos códigos nos últimos tempos você pegou totalmente sem documentação, isso sem falar em outros aspectos, como qualidade interna e blablablá [no bom sentido] que profissionais aptos a escrever grandes softwares fazem [Se essa última palavra não faz sentido para você, recomendo ler este livro para entender o que é um grande software]

Aquela velha estória de que quem manja mesmo lê o código e já era caiu por terra. Para um formmail até que pode ser, mas aplicações modularizadas com um modelo bem definido e aplicado e uma chuva de classes trabalhando neste modelo precisa muito mais do que uma simples leitura de código. O mínimo necessário são os comentários do tipo DocBlock além dos comentários inline e por fim e não menos importante Classes, atributos, comportamentos, variáveis locais e constantes com nomes reais do que fazem, recebem ou são.

Isto é um DocBlock retirado daqui !

Para fechar, eu recomendo fortemente que você caso não conheça, dê uma boa olhada e claro, passe lá e pegue sua cópia gratuitamente dele, o PHPDoc em PHPdoc.org. Não vou me prolongar em explicar o que ele tem ou o que faz. O site está lá completinho.

Veja você mesmo neste exemplo online onde foi gerado o manual do Smarty Template. Ele por si só já diz tudo. Agora é com você

O papo agora é sobre a sobrecarga do PHP, mais precisamente 2 deles que são: __get() e __set().

Eu particularmente já os conhecia, mas somente essa semana resolvi fazer uns testes e ver suas utilidades e limitações.

Bom, chega de papo e vamos ao source:

Controller.php

Partindo do princípio que você tenha noções básicas de MVC, acima é nossa Controller.php. Ele recebe os dados vindo do usuário e indica para qual Modelo(Model) será derecionado os dados para aplicarmos a regra de negócio.

Falando em Modelo...

O mais importante de tudo é isso aqui, ó:

Setando isto, assim que eu chamar: $metodo->Id = 2 meu atributo Id do objeto Modelo passará a ter o valor 2. Caso eu simplesmente rode um $metodo->Id; eu poderei resgatar o valor passado ao atributo.

Para quem ainda não viu os atributos da class Metodo, aqui estão eles:

Note que eu descrevi no Método construtor da classe uma iteração foreach para correr o $Params em busca de setters para setar. Obviamente se passarmos um Atributo não existente, um erro será lançado, para tanto será necessário um tratamento do dado inserido para garantir que o atributo realmente existe.

Como descrevemos a Dao ali no método Adiciona() da classe Modelo, coloco seu conteúdo abaixo:

Então, se eu criasse a seguinte estrutura:

Os três atributos (1, Fulaninha e 22) seriam passados à seus respectivos Atributos dentro da Classe Modelo, pois a Controller fez o tratamento desse Array passando os valores coerentes de acordo com a exigência da classe Modelo.

Uma alternativa seria inutilizar esse método construtor __construct(Array $params) e chamar os valores direto, para isto, basta modificarmos nossa Controller que estará tudo resolvido:

Pronto, não utilizamos mais o __construct() para popular nossos atributos.

Desvantagens
Apesar de ser muito útil e facilitar muito a criação dos getters e setters das nossas aplicações, vale lembrar que essa forma deixa muito 'limitada' nosso controle ao gets e sets do objeto. Uma das limitações se dá quanto ao nome do método get/set que usando a sobrecarga, nos obriga a usar o mesmo nome do atributo criado na classe.
Outro problema é quanto a atualização de nomes. Se eu precisar mudar o nome do atributo, terei que mudar em toda a extensão do código criado, Controllers, Daos e Views.

Resumindo: Essa é uma ferramenta que pode lhe ajudar muito da mesma forma que pode te quebrar legal. Cabe você avaliar quando usá-la e quando usar o tradicional:

Quem já ouviu falar de design patterns e que programa em PHP ? Melhor: quem que programa em PHP e está utilizando qualquer uma das patterns mais conhecidas ?

Isso não é nada espantoso! Os programadores PHP em sua grande parcela ainda não acordaram para a nova realidade: código mais extensível e pensado. Nunca falei aqui, mas acho que o PHP tem um defeito grave: ser super simples. Isso estragou, em partes a fama da linguagem.

Vamos a um exemplo: duelo. Java Vs PHP.

Java: Hello world no shell

PHP procedural

PHP O.O

O que é mais fácil ? PHP ou Java ? PHP procedural ou PHP O.O ? Essa facilidade fez com que várias aplicações inseguras e mal pensadas infestassem a rede, causando uma rejeição do PHP por parte de vários Clientes e com isso, empresas de desenvolvimento de software. Isso é ruim para a linguagem, ruim para o profissional sério e ruim para o cliente que terá que pagar mais caro por uma tecnologia como o Java.

Hélio, tá, mas onde entra os design patterns nessa sua conversa mole ? Ok, até o momento eu tangenciei o tema, mas veja que para existir Pattern é ideal que haja Programação Orientada a objetos com tudo que temos direito.

Design patterns nada mais é que um conjunto de conceitos que visa auxiliar na resolução de um problema comum entre os programadores de verdade.

E dale exemplos

MVC (Model View Control - Modelo Visualização Controle) :: essa Pattern foi desenvolvida para resolver o problema da lambança de códigos, ou seja, um arquivo faz tudo: conecta no banco, traz dados, exibe na tela, pega retorno do cliente, aplica regra de negócio e salva no banco.
Imagine uma aplicação como E-commerce feita desta forma! Loucura hein! Falando em lambança, encontrei recentemente em um dos projetos que assumi, um arquivo executa.php. Já ouviu falar dele ? O "faz tudo" ? Não ? Assunto para outro post!

Então, como eu ia dizendo: para resolver o problema de manter tudo nas "costas" de uma mesma aplicação, foi pensado e desenvolvido esse modelo MVC onde a aplicação fica separada em camadas. Na camada mais baixa, fica o modelo, que faz a interação com o servidor de banco de dados, sistema de arquivos e etc.; Depois temos a classe que processa os dados recebidos pelo usuário e se passar por checagens simples é entregue a "Model"; e por fim, temos a View que nada mais é do que o HTML que o usuário vê, sem PHP, sem CSS sem Javascript misturado.

Criando um diagrama bobo temos:

Banco de dados -> Model -> Controller -> View

View: Usuário clica no botão submit com o campo Nome preenchido.
Controller recebe esse formulário. Verifica se o nome tá setado (sem checar seu valor). Setado ? Ok, manda para a model.
Model recebe e aplica a regra de negócio: no exemplo, o nome precisa ter pelo menos 3 caracteres. Tem ? Ok, pega o poll de conexão com o banco de dados e salva.
Retorna "true" para a Controller que exibe uma mensagem de "Sucesso" na View

DAO: (Data Access Object) :: Essa Pattern tem como objetivo separar a Model em dois: regra de negócio do acesso ao banco de dados. No nosso exemplo anterior, a Usuario.php receberia da UsuarioController.php o dado e a mesma aplicaria a regra de negócio. Após estar ok, a Usuario.php enviaria o status de "ok, pode gravar" para o UsuarioDao.php e este gravaria a informação no banco (verificando se o nome não existe por exemplo) e retornaria a informação de "true" para nosso Usuario.php.
Veja que ela tem como objetivo deixar a Model mais limpa e legível à manter regra de negócio e acesso ao banco tudo junto.

Factory Pattern (Fábrica) :: tem por objetivo englobar vários recursos dentro de um mesmo método usando os blocos de condição "if" ou "switch". Exemplo:

Veja que no exemplo o método Pesquisa() é um só mas dependendo do tipo de informação que ele recebe, executa uma ação diferente. Isso é a Pattern Factory, novamente resolvendo outro problema usando conceitos simples. Uma outra forma de resolver o mesmo problema seria criando vários métodos PesquisaId() PesquisaNome(), porém, estariamos deixando de lado a Pattern Factory.

Singleton :: essa Pattern tem como objetivo evitar que uma mesma variável, poll de conexão e etc., ocupe mais espaço na memória. Vamos a um exemplo:

No desenho que criei no Gimp, ao conectar com o banco é alocado certo endereço da memória para ele. Caso eu faça outra requisição de conexão, ao invés de alocar outro endereço de memória, ele vai usar o mesmo endereço. Pense em algo fixo. Posso fazer "n" requisições que ele sempre usará o mesmo espaço que foi alocado inicialmente.

A mágina está no public static $Con. Estou definindo que o $Con será estático.
Abaixo, o script que está na imagem:

Caso tenha interessado o assunto, você poderá pesquisar outras diversas Patterns que propõem solução para vários outros "problemas" que temos diariamente. Esse foi apenas um panorama geral sobre Design Patterns.

Com o advento do PHP 5 OO, começaram a surgir o que já era esperado: uma chuva de frameworks. Tem framework para quase tudo hoje: XML, manupilação de dados, automatização de rotinas na view, abstração de database, até modelos mais avançados, complexos e completos como o CodeIngniter e o Symfony. Mas até onde isso é vantajoso ? Será que nós programadores estamos preparados para nos adaptarmos a essas frameworks ?

1. Conhecendo os participantes
Quando produzimos um software temos em mente que aquela aplicação é totalmente conhecida por nós, ou pelo menos o máximo possível, e que atrás dela há apenas Classes e funções criadas por nós e linguagem nativa (no caso o PHP).

Com frameworks temos um cenário totalmente diferente: código código e mais código por trás daquela framework que nós não temos a minima noção do que faz, onde há possíveis falhas e se aquela era a melhor forma de se fazer tal funcionabilidade. Entretanto, temos um "modelo" bem genérico ao nosso dispor, evitando que percamos tempo criando algo que tem pronto.

Os defensores de frameworks dizem que se você não sabe o que tem dentro da framework é porque você não quer saber o que há nela e ponto. Por outro lado, os defensores do código "na unha", dizem que se é para usar frameworks, ler a mesma seria uma tremenda perca de tempo e sendo assim, é melhor criar suas próprias classes/funções e usar em suas aplicações todas.

2. Quebrando paradigmas
Com o tempo estive analisando os prós e contras da framework e hoje, consegui chegar a uma linha de pensamento que talvez seja agradável ou não para você: "Frameworks. Consuma com moderação.".
E é exatamente isso que tenho feito de uns tempos para cá: uso algumas poucas frameworks para auxiliar em algumas tarefas e o resto eu vou criando na mão e criando meu "pacote".

Não adianta ser radical. Não usar framework nenhuma é meio que loucura atualmente. Se você é das antigas e já tem seus pacotes até pode ser, mas começar hoje a nadar contra a maré é suicídio.

Eu faço assim atualmente:
Pergunto : A framework "X" faz o que ?
Respondo: ah, de acordo com o site, ele cria um blog em 20 minutos.
Afirmo: Então essa framework é a "tal" que faz tudo ? Ótimo, não serve para mim!

Você pode estar me xingando a rodo neste momento, mas tenho para mim que ficar preso a uma framework é suicídio! Ficarei dependente de algo assim como um drogado depende da droga! Loucura! Se encontrar um problema na framework, terei que esperar uma nova versão, ou então debugar tudo para encontrar o erro/solução; Pensa no WordPress: tem uma falha, todo mundo que tem o WordPress instalado fica preocupado, pois é por lá que entrarão no seu sistema e danificarão suas informações. afinal o bug é público! E adaptar-se a nova forma de trabalho daquela framework, também não é tarefa fácil.

Estive vendo o Symfony PHP e constatei que ele é estilo o Ruby On Rails! Tudo por linha de comando. Tenho que ficar digitando comandos no meu querido shell para criar coisas dentro do projeto ? Não, isso infelizmente não é minha realidade!

Para mim, framework está como uma "biblioteca" de recursos, e não um novo modo de trabalhar com a linguagem de programação.

3. Frameworks
Atualmente eu estou utilizando a framework Jquery para Javascript e o Smarty Template para templates no PHP.

Talvez um dia eu mude de concepção, mas atualmente estou bem feliz assim e creio que muitos estejam como eu