Como escrever main () de uma maneira OOP?

StackOverflow https://stackoverflow.com/questions/325453

  •  11-07-2019
  •  | 
  •  

Pergunta

Quando comecei a programar, escrevi tudo no Main. Mas, como aprendi, tentei fazer o mínimo possível em meu main() métodos.

Mas de onde você decide dar à outra classe/método a responsabilidade de assumir o programa main()? Como você faz isso?

Eu já vi muitas maneiras de fazer isso, assim:

class Main
{
  public static void main(String[] args)
  {
    new Main();
  }
}

E alguns gostam:

class Main {

   public static void main(String[] args) {

    GetOpt.parse(args);

    // Decide what to do based on the arguments passed
    Database.initialize();
    MyAwesomeLogicManager.initialize();
    // And main waits for all others to end or shutdown signal to kill all threads.
  }
}

O que deve e não deve ser feito em main()? Ou não há balas de prata?

Obrigada pelo tempo!

Foi útil?

Solução

Na minha opinião, o "principal" de um projeto considerável deve conter cerca de três chamadas de função:

  • Chamando uma função de inicialização que configura todas as configurações, preferências, etc. para o aplicativo.
  • Iniciando o principal "controlador" do aplicativo
  • Esperando o controlador principal terminar e depois chamar uma função de rescisão que limpa qualquer coisa que precise ser limpa em "Main" (embora o controlador já tenha cuidado da maior parte da limpeza).

Qualquer aplicação considerável será dividida em pedaços de funcionalidade, geralmente com alguma hierarquia. O controlador principal pode ter vários controladores crianças para recursos específicos.

Fazer dessa maneira facilita muito a localização de funcionalidades específicas, e a separação das pessoas é melhor.

Obviamente, como outras respostas disseram, realmente não há bala de prata no desenvolvimento de software. Para um projeto curto, posso colocar tudo em principal apenas para obter as coisas rapidamente. Eu acho que também depende do idioma - algumas opções podem ser mais fáceis do que outras em idiomas específicos.

Outras dicas

Código na função principal:

  • Não pode ser testado na unidade.
  • Não é possível receber dependências por injeção.
  • Não pode ser reutilizado por outros aplicativos semelhantes ao primeiro que você escreve.

Portanto, código na função principal:

  • Deve ser tão simples que você está feliz apenas com os testes funcionais/do sistema.
  • Deve ser responsável por definir o rolamento da bola para as dependências usadas por todos os seus outros códigos (ou seja, atos principais como uma fábrica super que cria seu aplicativo).
  • Deve fazer apenas as coisas específicas da maneira como seu aplicativo é configurado (ou seja, não é nada qual código de teste ou a versão demo precisará fazer exatamente da mesma maneira).

Na prática, isso significa que aplicativos reais não têm muito em Main. Aplicativos de brinquedo e programas de um tiro podem ter bastante no Main, porque você não planeja testá-los ou reutilizá-los de qualquer maneira.

Na verdade, parte do que eu digo acima é específico de C ++. Os métodos principais Java, é claro, podem ser chamados pelo código de teste ou aplicativos variantes. Mas eles ainda não tomam objetos como parâmetros, apenas argumentos da linha de comando; portanto, a extensão em que podem ser isolados em teste ou se comportar bem em termos de reutilização, é bastante baixa. Eu acho que você poderia passar nomes de classe para que eles instanciem e usem para criar o restante do aplicativo.

Editar: alguém removeu as tags "C ++, Java" desta pergunta. Então: o que eu digo acima é C ++ e Java específico. Outros idiomas podem tratar o principal de uma maneira que é menos especial; nesse caso, também pode não haver motivo específico para você tratá -lo especialmente.

Qualquer que seja o seu barco, como eles dizem. :) Você deve realmente se concentrar em tornar o código simples, fácil de ler e eficiente, usando as ferramentas necessárias para conseguir isso. Se ele merece colocar muito código em Main - faça -o. Se você acha que os objetos tornariam as coisas mais organizadas - siga assim.

Fazendo uma única instância de class Main e então chamando o método da instância Main() O que faz todo o trabalho é tão bom quanto escrever tudo no método principal diretamente.

Eu diria que não é o que está na sua função principal, mas o que não é. Dependendo da complexidade do seu projeto, você deseja dividi -lo em seções funcionais, como "funções de banco de dados", "Exibir funções", "chá com o vigário", etc.

É tudo sobre a legibilidade do código. Outra pessoa, que nunca viu seu programa antes, e a princípio, uma boa idéia generalizada do que ele faz?

Então, então pode ver facilmente onde ir para cavar um pouco mais fundo no mecanismo?

Cada seção funcional que você usa é fazer apenas um bloco lógico de processos? Não precisa fazer apenas uma coisa, mas não deveria estar fazendo tudo Além da pia da cozinha.

Divida seu código de uma maneira que ele seja sustentável por uma fonte externa.

Porque os céus sabem, quando se trata disso, se alguém - else- pode corrigir o bug, é melhor =)

Como uma resposta direta à sua pergunta, eu colocaria as chamadas de função para cada um dos principais componentes do Main, a configuração, o processo e o acabamento, para que qualquer pessoa que o olhar obtenha uma rápida visão geral de como o programa funciona. Eles podem então perfurar ainda mais, caso precisem.

Veja, o conteúdo e a forma do método "principal" dependem muito de linguagem e ambiente. Em Java, todas as aulas podem ter um public static void main() Método, por isso é totalmente viável ter mais de um.

Mas agora, vamos pensar sobre isso através da Lei da Modularização de Parnas: "Todo módulo esconde um segredo, e esse segredo é algo que pode mudar". O "segredo" do módulo chamado inicialmente é os detalhes da interface do processo com o sistema operacional: coisas como obter os argumentos e lidar com terminações irregulares. Em Python, isso leva a algo assim:

def main(args=None):
    #argument processing
    #construct instances of your top level objects
    #do stuff

if __name__ == "__main__":
   try:
      main(Sys.Argv)
   except: # everything
      # clean up as much as you can
   else:
      # normal cleanup, no exceptions

O ponto aqui é que você obtém tudo do ambiente possível e chama a função principal (); Você pega todas as exceções não capturadas e faz algo inteligente com eles antes que o programa morra.

Eu acho que o método principal deve explicar, o que o programa faz ao iniciar. Portanto, pode chamar métodos iniciais de zação, mas a lógica deve ser extraída em métodos.

No seu exemplo, eu não criaria um método main (), mas o colocaria no original.

O design do seu programa decidirá a forma do seu "principal".

Ter uma "regra" que diz como sua principal função deve ser, é - IMHO - um não sentido.

Lembre -se de que, se alguém quiser ter uma idéia de como seu programa funciona, o primeiro lugar que provavelmente olhará é o principal (pelo menos eu faria). Então, não acho que seja uma boa ideia colocar o mínimo possível nele. Mas eu diria para colocar o mínimo necessário para obter uma visão dos pássaros de como seu programa funciona.

Assim, acho que sua maior preocupação na implementação de uma função principal deve ser a legibilidade.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top