escolher entre os módulos e Classes

Question

Na minha aplicação eu tenho que manter alguns métodos de todo o estado de aplicação global e de aplicação global como a usuários conectados no momento, o número total de respostas, criar um arquivo de configuração aplicativo etc. Existem duas opções:

1. Faça um arquivo appstate.py separado com variáveis ??globais com funções sobre eles. Parece bem inicialmente, mas parece que estou em falta algo na clareza do meu código.

2. Criar um AppState classe com funções de classe em um arquivo appstate.py, todos os outros módulos foram definidos por seus trabalhos específicos. Isso parece bem. Mas agora eu tenho que escrever mais linha como appstate.AppState.get_user_list (). Além disso, os métodos não são muito relacionados entre si. Eu posso criar classes separadas, mas que seria demais classes.

EDIT: Se eu usar classes I estará usando classmethods. Eu não acho que há uma necessidade de instanciar a classe a um objeto.

Answer 1

A segunda abordagem parece melhor. Eu usaria o primeiro apenas para arquivos de configuração ou algo assim.

De qualquer forma, para evitar o problema que você poderia sempre:

from myapp.appstate import AppState

Dessa forma, você não tem que escrever a linha longa mais.

Answer 2

Parece que o dilema clássico: -).

Em Python, não há nada sujo ou vergonhoso sobre a escolha de usar um módulo se essa é a melhor abordagem. Afinal, módulos, funções, e similares são, de fato, cidadãos de primeira classe na língua, e oferecer a introspecção e propriedades que muitas outras linguagens de programação oferecem apenas pelo uso de objetos.

A maneira que você descreveu suas opções, ele meio que parece que você não está muito louco por uma abordagem baseada em classe neste caso.

Eu não sei se você já usou o framework Django, mas se não, ter um olhar para a documentação sobre como lidar com configurações. Estes são app-largura, eles são definidos em um módulo, e eles estão disponíveis globalmente. A maneira como ele analisa as opções e expô-los a nível mundial é bastante elegante, e você pode encontrar uma abordagem tão inspiradora para as suas necessidades.

Answer 3

A segunda abordagem só é significativamente diferente da primeira abordagem se você tiver o estado do aplicativo armazenados em uma instância de AppState, caso em que a sua queixa não se aplica. Se você está apenas armazenar o material em uma classe e usando métodos static / classe, sua classe não é diferente de um módulo, e seria pythônico ao invés realmente tê-lo como um módulo.

Answer 4

Por que não ir com uma instância dessa classe? Dessa forma, você pode até ser capaz mais tarde de ter 2 "sessões" diferentes em execução, dependendo do que exemplo você usar. Ele pode torná-lo mais flexível. Talvez adicionar algum método get_appstate() ao módulo para que ele instanciates a classe uma vez. Mais tarde, se você pode querer vários casos você pode alterar esse método para, eventualmente, ter um parâmetro e usar algum dicionário etc. para armazenar essas instâncias.

Você também pode usar decoradores de propriedade btw para tornar as coisas mais legível e ter a flexibilidade de armazená-lo como e onde você quer que ele armazena.

Eu concordo que seria mais Python para usar a abordagem do módulo em vez de classmethods.

BTW, eu não sou um grande fã de ter as coisas disponível globalmente por alguns de "mágica". Eu prefiro usar algum chamada explícita para obter essa informação. Então eu sei onde as coisas vêm e como depurá-lo quando as coisas falham.

Answer 5

Veja este exemplo:

configuration
|
+-> graphics
|   |
|   +-> 3D
|   |
|   +-> 2D
|
+-> sound

A verdadeira questão é: Qual é a diferença entre classes e módulos nesta hierarquia, como poderia ser representado por ambos os meios

As classes representam tipos. Se você implementar a sua solução com aulas em vez de módulos, você é capaz de verificar um objeto gráfico para ele é tipo adequado, mas escrever funções de gráficos genéricos.

Com aulas você pode gerar valores parametrizados. Isto significa que é possível inicializar de forma diferente sons classe com um construtor, mas é difícil para inicializar um módulo com diferentes parâmetros.

O ponto é que você realmente algo diferente do ponto de vista de modelagem.

Answer 6

Eu iria com a rota aulas uma vez que irá organizar melhor o seu código. Lembre-se que para facilitar a leitura que você pode fazer isso:

from appstate import AppSate

Answer 7

Eu definitivamente ir para a segunda opção: já ter usado o primeiro, agora estou forçado a refatorar, como a minha aplicação evoluiu e tem que apoiar construções mais modulares, então agora eu preciso para lidar com múltiplas configurações simulataneous' '.

A segunda abordagem é, IMO, mais flexível e à prova de futuro. Para evitar as linhas mais longas de código, você poderia usar from appstate import AppState em vez de apenas import appstate.