Design de software: muitos objetos estáticos?

Question

Design de software: muitos objetos estáticos?

#1 resposta do (3 votos)

5

Sobre o assunto

Eu hesitei por algum tempo entre usar objetos singletons ou objetos estáticos simples. Depois de ter lido muitas opiniões diferentes, eu fiz o meu:

If you don't need to prevent multiple creation of an object, don't use a singleton.

Por isso, usei principalmente objetos estáticos.

Contexto

Meu programa é um programa científico complexo. Ele deve se comunicar com o mundo externo (usando zmq), gerar alguns logs e tempo para garantir que tudo esteja bem.

O que eu fiz

Logger

Eu lidei com os logs criando / destruindo o objeto Logger toda vez que eu precisei dele. Funções estáticas como

Logger::log() << "My Log";

constrói o objeto, e na destruição (fim da função de chamada) o log é gerado. E tudo bem!

Zmq

Como é necessário em todos os lugares no código, a classe que implementa o zmq não pode pertencer a um objeto. Portanto, acesso a um objeto estático criado acima da função main() .

Timers

Mais uma vez, meus temporizadores devem ter tempo de várias funções e serem impressos de uma só vez para facilitar o diagnóstico: a mesma solução para mim, um objeto TimerList estático contendo todos os timers usados.

A questão

Agora que você sabe tanto quanto eu sobre meu projeto: é um projeto ruim?

O que você faria em vez disso? Singletons? Algo mais?

Aqui está o meu main.cpp

bool READONLY;

// Must be started first to be deleted last.
zmq::context_t context(1);
zmq_ext::socket_t logSocket(context, ZMQ_PUB);
namespace TimingModule{
   TimerList tm;
}

//Must be static so that exit() do a proper deletion.
static App app;

namespace Messenger {
    Messenger messenger(context);
}

int main(int argc, char *argv[])
{
   return app.run()
}

Não há resposta exata porque é mais um conjunto de recomendações e boas práticas: compilar os comentários perspicazes seria uma boa resposta. Ele ajudou muito. Obrigado!

design design-patterns

por ochurlaud 10.05.2016 / 15:24

fonte

1 resposta

Tags design design-patterns

As inspeções formais são usadas na prática hoje? Segurança do servidor e do MySQL para aplicativos Java / JDBC?

score 3 · Answer 1

Eu não diria que você está usando um design ruim. Há sempre um custo na codificação - para ganhar o prêmio mais digno da classe 'CS' / mais orientado a objeto não é realmente o que é codificação. O código é uma ferramenta, como qualquer outro e como a maioria das ferramentas - você inventa usos para essas ferramentas conforme necessário.

Eu acho mais fácil usar uma classe estática para coisas do tipo 'utilitário' como você tem aqui e depois desestabilizá-las. Em essência, você só precisa saber quando são criados, destruídos e em qual deles você está se referenciando, em vez de reconstruir uma classe singleton, que tem um formato muito diferente. A maneira que eu costumo construir minhas classes estáticas é bem parecida com a maneira como eu trato os objetos de qualquer maneira, menos alguns da contabilidade - então é mais facilmente escalável.

Em suma: se você não precisa complicar seu produto e economizar tempo com sua solução, não há problema algum com o que você fez. À medida que você for mais experiente, aprenderá como manter seu código gerenciável, de modo que, se precisar dimensioná-lo e torná-lo instável, você já criou seu modelo de como funciona 1 em uma bolha.

Não há punição maior, no entanto, por ter construído uma solução muito não escalável e seu chefe lhe diz no dia seguinte para que suporte x1000.