Posso acabar usando principalmente classes estáticas?

Question

Atualmente estou reescrevendo um e-shop - mas apenas do lado do cliente, ou seja,o CMS permanece praticamente intacto.Não estou usando uma estrutura pré-construída, pois o sistema precisa manter a compatibilidade com versões anteriores do CMS e preciso ter total liberdade na estrutura do código.

O novo sistema é puramente baseado em MVC e eu tenho um Bootstrapper que carrega controladores baseados no uri atual e este último usa modelos para o trabalho real - tanto com sessões quanto com o banco de dados.

dr. É meu primeiro projeto sem framework pré-construído.

Sou muito inexperiente quando se trata de padrões de design.Eu sei como funciona a maioria dos mais populares, mas nunca os coloquei em uso.

Agora estou suspeitando de cheiros de código porque todos os meus modelos são classes que consistem puramente em métodos estáticos.Não encontro vantagens em fazê-los de maneira diferente.Rotineiramente preciso de alguns dos métodos em vários lugares do código.Ou sejaPreciso buscar o usuário logado no layout principal, verificar os direitos do usuário para ver a página atual no bootstraper, exibir o painel do usuário pelo controlador.Eu precisaria reinstanciar um objeto a cada vez ou manter um objeto global se não estivesse usando estática.Também não haverá necessidade de mais de uma aula por vez.

Devo estar faltando alguma coisa, porque mesmo que eu use OOP, algumas das minhas classes são apenas contêineres sem sentido para seus métodos (e às vezes algumas variáveis ​​privadas).Eu poderia estar usando PHP4 e funções simples.

Quaisquer comentários ou conselhos serão muito apreciados.

EDITAR: apesar de todas essas respostas educadas, não estou convencido.Embora seja provavelmente por causa da minha falta de experiência, ainda não prevejo nada de errado com a configuração atual.Quer dizer, eu nem imagino uma situação em que eu teria algum inconveniente devido à arquitetura do código como é agora.Espero não aprender uma lição dura quando for tarde demais para mudar alguma coisa...

Answer 1

Você está certo, é um cheiro de código e todo mundo dirá que é ruim.

Então aqui eu sugiro fazer uma auto-avaliação da gravidade do problema:

• Você tem aulas com muitos getter e setter?

• São seus funções estáticas como o abaixo?

  Se sim, tente mover a lógica na classe MyClass isso já será muito mais OO.Esse é um erro clássico do mundo processual/script.

---

 static void myMethod( MyClass anObject )
 {
     // get value from anObject
     // do some business logic
     // set value of anObject
 }

---

• Você tem muito estado global, como dados que você busca na sessão atual?

  Se sim, avalie se deseja alterá-lo.A maneira OO seria passar a sessão pela cadeia de chamadas.Mas, na prática, é conveniente acessar a sessão como um objeto global.Mas isso impede a testabilidade.Tente remover algum estado global e transformá-lo em um objeto regular que você passa e manipula nos métodos.

Faça esta avaliação e tente identificar Utilitário Aulas, Serviços aulas e o objetos de negócios.Classes utilitárias são classes auxiliares com métodos utilitários (por exemploformatação, conversão, etc.) que podem ser estáticos.A classe de serviço faz alguma lógica de negócios, mas deve ser sem estado e uma instância é suficiente.Objetos de negócios são user, products, article, etc.é onde você deve concentrar seu esforço.Tente transformar dados simples em objetos com algum comportamento incorporado.

Dê uma olhada em a entidade deveria ser burra.Mesmo que seja para java, os conceitos são gerais.

EDITAR

Aqui está minha análise com base no seu comentário:

• Você não tem um modelo de domínio com entidades.Você manipula o banco de dados diretamente.
• O que você chama de modelo é o que eu chamo Serviços e é onde você executa a lógica de negócios que manipula os dados.As classes de serviço são apátrida, qual é correto.Como você apontou na pergunta, você precisa recriá-los constantemente, criar uma instância global ou usar métodos estáticos.

O paradigma OO diria que você deveria tentar ter um modelo de domínio onde mapeasse seu banco de dados com entidades.Tenha pelo menos um modelo de domínio anêmico onde as entidades são contêineres de dados enfadonhos que são carregados/persistidos no banco de dados.Então o paradigma OO também diria para colocar um pouco de lógica nas entidades, se possível.

Diria também transformar os serviços em objetos para facilitar a composição e a reutilização.Se fosse o caso, você poderia, por exemplo, agrupar todos os serviços com um interceptador para iniciar/parar transações ou fazer alguma verificação de segurança, o que não será possível fazer com métodos estáticos.

O que você descreve (sem entidades + serviços processuais sem estado) não é considerado um ótimo design OO.Eu sugeriria que você introduzisse pelo menos um modelo de domínio anêmico e DAO.Em relação aos serviços processuais sem satélite, esta é na verdade a realidade de muitas aplicações web - se você não precisar de mais, você pode segui-lo.

Meus 2 centavos

Answer 2

Se você está usando principalmente classes estáticas, então realmente retirou o objeto da programação orientada a objetos.Não estou dizendo que você está fazendo as coisas incorretamente, estou dizendo que talvez seu sistema não deva ser adequado para OOP.Talvez seja um aplicativo simples que requer algumas funções utilitárias básicas (envia e-mail, etc).Neste caso, a maior parte do seu código se torna muito processual.

Se você estiver lidando com bancos de dados, poderá ter uma classe de banco de dados estática e uma camada de negócios simples, e seu aplicativo php interage com sua camada de negócios, que por sua vez interage com sua camada de banco de dados.Isso se torna sua típica arquitetura de 3 camadas (algumas pessoas gostam de se referir a isso como 4 camadas e separar o banco de dados real da camada de dados, a mesma coisa).

Se você não está realmente chamando métodos que requerem um objeto, qual é o objetivo de todas essas classes estáticas, apenas uma pergunta a ser feita.

Answer 3

Uma coisa que você pode notar é que se você planeja fazer qualquer tipo de teste de unidade com zombaria/stubbing, provavelmente terá dificuldades, pois classes e métodos estáticos não são fáceis de zombar, fazer stub ou testar.

Answer 4

Eu seria cauteloso ao usar variáveis ​​e classes estáticas em aplicativos da web.Se você realmente precisa compartilhar uma instância entre usuários, não há problema em ter uma única instância (padrão de design de pesquisa "Singleton").

No entanto, se você estiver tentando manter o estado nas páginas, deverá fazer isso utilizando o ViewState ou o objeto Session.

Se você tivesse uma variável estática global, poderia ter uma situação em que usuários simultâneos lutassem para atualizar o mesmo valor.

Answer 5

Resposta curta:Tudo bem, mas você está abrindo mão dos benefícios do OOP.

Um raciocínio por trás do uso de objetos é que na maioria das vezes há mais de um tipo de objeto que desempenha uma função.Por exemplo, você pode trocar seu objeto de acesso a dados DBVendor1 por um objeto de acesso a dados DBVendor2 que tenha a mesma interface.Isso é especialmente útil se você estiver usando testes de unidade e precisar trocar objetos que fazem trabalho real por objetos fictícios (mocks e stubs).Pense em seus objetos com a mesma interface das peças de Lego, com cores diferentes que se encaixam e são facilmente intercambiáveis.E você simplesmente não pode fazer isso com objetos estáticos.

É claro que a maior flexibilidade dos objetos tem um preço:A inicialização dos objetos e reuni-los dá mais trabalho (como você escreveu) e leva a mais código e objetos que reúnem outros objetos.É aqui que padrões de design criacionais como construtor e fábrica entre no jogo.

Se você quiser seguir esse caminho, aconselho que leia sobre Injeção de dependência e usando um Estrutura DI.

Answer 6

Tecnicamente não há nada de errado em fazer isso.Mas praticamente você está perdendo muitos benefícios da programação orientada a objetos.Escreva também o código/funcionalidade a que pertence.por exemplo:

 user.doSomeTask()

no objeto do usuário faz mais sentido do que

 UserUtils.doSomeTask(User user)

Usando conceitos OOP você abstrai a funcionalidade a que ela pertence e no futuro ajuda a alterar seu código, estender a funcionalidade mais facilmente do que usar métodos estáticos.

Answer 7

Existem vantagens em usar métodos estáticos.Uma delas é que, como você não pode herdá-los, eles têm melhor desempenho.Mas usá-los o tempo todo limita você.Todo o paradigma da OOP é baseado na reutilização das classes base minuciosas do uso da herança.