Eu tenho visto que para interpretar o comportamento de uma classe como um todo teria que abrir 200 pequenas classes. Como organizar as pastas de classes em um projeto real ? Porque acho ( como iniciante ), que é mais fácil achar o problema em um switch do que procurar nessas classes aninhadas dentro de atributos de outras.
Solucionado (ver solução)
Solucionado
(ver solução)
3
respostas
respostas
Orientação a objetos x procedural
Olá, Rubens.
Não entendi muito bem sua dúvida, mas posso te afirmar o seguinte: não vai ser mais fácil encontrar o problema em um switch. rsrsrsr
Principalmente quando não tiver sido você o desenvolvedor dessa parte específica do código, sem contar que quando mais um caso for adicionado, você corre risco de quebrar código que funcionava anteriormente.
Quanto à organização de pastas, existem diversas recomendações, mas no geral, os seguintes passos vão te guiar bem:
- Defina pacotes pro seu projeto. Por exemplo: Um pacote para os objetos do domínio (Cliente, Produto, etc.), um pacote para acesso ao banco de dados, um pacote para classes utilitárias, etc.
- Cada pacote terá sua pasta, onde as classes correspondentes serão armazenadas
- O pacote deverá ter um namespace correspondente no PHP, para organização e autoloading (depois dá uma pesquisada sobre o composer)
Espero ter ajudado.
Abraços!
O que eu quis dizer é: adicionar um if vai ser como adicionar uma classe. Ler uma página as vezes é mais fácil que abrir várias abas da IDE para entender também, não sei se fui claro. Um if a mais = uma classe a mais. Eu quero refatorar o código do meu primeiro projeto que venho trabalhando há 8 meses e quero aprender essa organização de pastas. Tem algum curso aqui que fala do composer ?
solução!
Minha experiência me diz que, quando não se escreve o código do jeito certo, fica muito difícil de dar manutenção. Um arquivo de 1000 linhas de código, com um monte de if / else ou switchs é uma verdadeira dor de cabeça. É um convite para repetição de código, onde se concerta a mesma coisa em vários lugares, e onde as complicações pra entender o funcionamento de algo aparecem.
Algumas das chaves da Orientação a Objetos é dividir a responsabilidade em classes de menor escopo possível. Assim, quando alguma responsabilidade falhar em ser cumprida, você saberá qual classe falhou e onde terá que dar manutenção. Um outro ganho é poder escrever uma responsabilidade apenas uma vez e usá-la sempre que necessário, evitando assim a reescrita de código. Existem várias outras vantagens que vão sendo ativadas com a experiência e uso de padrões de projeto.
Exemplo: Em frameworks bem escritos, com o uso de ORMs, a orientação a objeto permite a troca de uma opção de banco de dados, como MySQL para PostgreSQL ou SQL Server apenas mudando uma linha de código. Todo o resto fica transparente para o sistema.
Existem infinitos outros exemplos como o acima e você verá com a sua própria experiência.