MVC + DAO - Qual forma deveria optar no PHP?

no Java, na classe Modelo eu posso criar na classe funcionario o atributo Setor s, porém o PHP não é tipado, como eu poderia resolver esse caso de associação?

A maneira como ensinaram OOP para as pessoas é baseado em linguagens estaticamente tipadas então há limitações quando tenta usar orientação a objeto em linguagens dinamicamente tipadas. Há uma forma de programação que é baseado no modelo do Smalltalk que muitos chama de programação orientada a objeto, mas seu criador recentemente admite que o modelo é orientado à mensagens^*.

PHP ainda é uma linguagem de script, seus códigos rodam por uma fração de segundo ou até por alguns segundos, então fazem coisas muito rápidas, são naturalmente microsserviços, então OO não é algo que ajude muito neste tipo de ambiente.

Por isso tentar reproduzir em PHP a forma como se faz em Java é esquisito, mesmo que seja o que todo mundo esteja fazendo. Não é algo com fundamento, é só porque alguém disse que quem não fizer assim é mulher do padre. Se deseja usar o mesmo modelo do Java e ter algo parecido com PHP use Hack, que é o que o PHP quer ser e é mantido por pessoas altamente qualificadas para fazer funcionar.

Nem Java chama isto que está se referindo como atributo, só em UML que o termo é usado oficialmente. Nas linguagens isto chama-se campo. E em PHP não pode ter um tipo.

Um detalhe importante: muitas metodologias pregam que não deve-se usar getters/setters, eu acho exagero, mas faz algum sentido, na forma como as pessoas costumam usar está errado mesmo. Algumas perguntas para refletir:

• Quando é útil separar estado de comportamento?
• Por que não devo alterar os "getter"s e "setter"s?
• É realmente necessário usar métodos para mutator e acessor (setter e getter) no PHP? E o desempenho?
• Exemplo real do uso de encapsulamento
• O que acontece na vida real em um ambiente de desenvolvedores se o programador não encapsular um atributo?
• Qual a diferença entre referenciar um atributo diretamente ou por get/set

Uma das coisas que pode fazer em um setter em PHP é verificar se o dado é de determinado tipo. Mas PHP já permite que coloque o tipo no parâmetro e o interpretador pode fazer a verificação para você. Isso faz mais sentido em uma linguagem compilada. Isto nem de perto é tipagem estática que Hack possui, é só type hinting que tem alguma vantagem.

Aliás, classes na forma como é construída, para usar como contrato, só faz sentido em linguagem compilada e estaticamente tipada.

Uma forma que algumas pessoas usam e eu acho bem plausível, em linguagens de tipagem dinâmica, apesar de eu ser filosoficamente contra é o uso de notação húngara. Assim todas variáveis, e até métodos poderiam ter no seu nome indicando qual é o tipo dela, o que é uma documentação difícil de ignorar, ainda que polua um pouco o nome. Mas novamente, se isto é uma preocupação, vai pra Hack, ou Java, ou outra linguagem que usa o melhor dos dois mundo, como C#.

Isso é uma rasa tentativa de evitar o problema de Gettier que impera por aí, o que não quer dizer que isto aqui seja o conhecimento que ele fala.

---

^* OOP não é message based

• Troca de e-mail com Alan Kay onde ele mostra implicitamente que o termo foi um infortúnio (ele até diz que se opõe ao modelo que "todas" linguagem implementam OOP, por isso: ou parem de usar o termo OOP, ou parem de impor a visão dele para essas linguagens)
• Mensagem de e-mail onde ele lamenta não ter focado em mensagens
• Ele mesmo responde quando o questionam
• Comentado
• Entrada 2122503 da ISO-IEC-2382-15
• Wikipedia sobre passagem de mensagem
• Discussão de gente altamente qualificada sobre o assunto
• Excelente comparação entre os dois modelos de "OOP"
• Outra interessante reflexão
• Outra comparação entre o modelo de Smalltalk e de C++
• Finalmente um debate interessante sobre o assunto

caso eu quisesse o nome do setor em que o funcionário está relacionario, ficaria $f = new Funcionario(); $f->getSetor->getNome();

Respondendo comentário, não exatamente, seria mais algo como:

$f->getSetor()->getNome();

Coloquei no GitHub para referência futura.

Esta é uma forma de fazer, partindo do princípio que setor é um objeto que possui um método que pega o seu nome. Claro que poderia ignorar o getter e acessar direto o campo se torná-lo público.

após algumas pesquisas aqui no site, vi que no PHP a classe Modelo do MVC é onde ficam métodos (crud...), porém no Java ficam apenas os atributos, e esses métodos na classe DAO, isso se deve ao uso da persistência de dados, ou apenas um jeito diferente de usar o MVC?

Existem várias formas de se ver o MVC. As classes (no plural) que representam um modelo costumam ter métodos que fazem todas operações que o objeto pode fazer, ou pode ter só os métodos que são regras de negócio (tem um DAO), ou podem ser completamente anêmicos e só possuírem estado, ou pode fazer um meio termo se fizer muito sentido.

As pessoas fazem de forma diferente por dois principais motivos:

• elas não sabem o que estão fazendo e só copiam um modelo que viram em algum lugar, portanto não importa, já é um erro a motivação do uso
• elas sabem o que estão fazendo e escolhem um caminho porque fazem mais sentido para eles trabalharem assim, seja porque a equipe trabalha desta forma, seja porque o problema que lida funciona melhor.

Há metodologias que pregam uma coisa ou outra. Não dá para dizer o que é mais certo, apesar seguir uma filosofia. Alguns frameworks obrigam fazer de uma determinada forma. Por exemplo: OOP mais puro usa a forma de ter tudo nele; DDD já prega tudo muito separado, e há o meio termo que costuma ser mais pragmático.

Em ambientes muito organizados eu prefiro o DAO ou algo semelhante de forma separada. Em ambientes pouco organizados, o que não é o mesmo de bagunçado, apenas uma forma de pouca cerimônia, que é o que linguagens como PHP sempre pregou, aí você faz o que é mais simples e pode colocar junto se é algo específico. Pra falar a verdade uma das grandes vantagens que PHP tem e as pessoas estão jogando no lixo programando como se fosse Java é generalizar soluções e sequer precisar cuidar da gravação de forma específica.

Java não ajuda muito, embora possa fazer, mas mesmo linguagens mais burocráticas, como C# estão incentivando a generalização com reflexão e mais recentemente com geração de código, pode ter o melhor dos dois mundos.

As pessoas não fazem de forma diferente porque elas não entendem o que estão fazendo, só seguindo receitas de bolo encontradas em livros, ou pior, em blogs e vídeos na internet, ou pior ainda em posts isolados por em fóruns, outros sites e pasmem, em WhastsApp! Isso é o que se chama de "dica Miojo"^*, é rápido, resolve seu problema em 3 minutos, mas depois te dá mais fome e te causa problema de saúde! E eu sei que ninguém vai ler tudo o que tem linkado para formar sua própria opinião :P

---

^*Miojo é marca registrada da Nissin e não tem nada a ver com o assunto. O termo "Dica Miojo" é invenção do meu amigo João Benito "Excel man" Savastano.

Primeira dúvida: no Java, na classe Modelo eu posso criar na Classe funcionario o atributo Setor s, porém o PHP não é tipado, como eu poderia resolver esse caso de associação?

Você cria o atributo do mesmo jeito:

class Funcionario{
    private $setor;
    //...getters e setters
}

Obviamente, nada vai te obrigar a colocar em setor um objeto do tipo Setor, mas se você for minimamente organizado vai saber que essa variável foi criada pra isso. Outra opção é usar algum tipo de validação nos setters, se garantir o tipo for tão crítico pra você.

Segunda dúvida: após algumas pesquisas aqui no site, vi que no PHP a classe Modelo do MVC é onde ficam métodos (crud...), porém no Java ficam apenas os atributos, e esses métodos na classe DAO, isso se deve ao uso da persistência de dados, ou apenas um jeito diferente de usar o MVC?

Isso é mais organização de quem está escrevendo o código do que regra geral. Por definição no Model é onde ficariam as regras de negócio da aplicação, mas como muitas vezes o que vemos na internet são exemplos mais simples e didáticos, você vê esse tipo de coisa. Outra questão é que a maioria dos frameworks PHP não usam DAO para a persistência, mas o modelo de ActiveRecord, onde a própria classe da entidade persistente contém os métodos de CRUD. Isso acaba criando essas situações onde sistemas simples acabam criando Models que apenas repassam o CRUD, ao invés de terem realmente alguma lógica de negócio.