O que estou falando aqui são classes aninhadas. Basicamente, tenho duas classes que estou modelando. Uma classe DownloadManager e uma classe DownloadThread. O conceito OOP óbvio aqui é composição. No entanto, composição não significa necessariamente aninhamento, certo?
Eu tenho um código parecido com este:
class DownloadThread:
def foo(self):
pass
class DownloadManager():
def __init__(self):
dwld_threads = []
def create_new_thread():
dwld_threads.append(DownloadThread())
Mas agora estou me perguntando se há uma situação em que o aninhamento seria melhor. Algo como:
class DownloadManager():
class DownloadThread:
def foo(self):
pass
def __init__(self):
dwld_threads = []
def create_new_thread():
dwld_threads.append(DownloadManager.DownloadThread())
Não conheço Python, mas sua pergunta parece muito geral. Ignore-me se for específico para Python.
O aninhamento de classes tem tudo a ver com escopo. Se você acha que uma classe só fará sentido no contexto de outra, então a primeira provavelmente é uma boa candidata para se tornar uma classe aninhada.
É um padrão comum tornar as classes auxiliares como classes privadas aninhadas.
fonte
private
classes não se aplica tanto ao Python, mas um escopo de uso implícito ainda se aplica definitivamente.Há outro uso para classe aninhada, quando se deseja construir classes herdadas cujas funcionalidades aprimoradas são encapsuladas em uma classe aninhada específica.
Veja este exemplo:
Observe que no construtor de
foo
, a linhaself.a = self.bar()
construirá umfoo.bar
quando o objeto que está sendo construído for realmente umfoo
objeto e umfoo2.bar
objeto quando o objeto que estiver sendo construído for na verdade umfoo2
objeto.Se a classe
bar
fosse definida fora da classefoo
, bem como sua versão herdada (que seria chamadabar2
por exemplo), então definir a nova classefoo2
seria muito mais doloroso, porque o construtor defoo2
precisaria ter sua primeira linha substituída porself.a = bar2()
, o que implica reescrever todo o construtor.fonte
Não há realmente nenhum benefício em fazer isso, exceto se você estiver lidando com metaclasses.
a classe: suíte realmente não é o que você pensa que é. É um escopo estranho e faz coisas estranhas. Realmente nem chega a ser uma aula! É apenas uma forma de coletar algumas variáveis - o nome da classe, as bases, um pequeno dicionário de atributos e uma metaclasse.
O nome, o dicionário e as bases são todos passados para a função que é a metaclasse, e então é atribuída à variável 'nome' no escopo onde a classe: suíte estava.
O que você pode ganhar mexendo com metaclasses e, de fato, aninhando classes dentro de suas classes padrão de estoque, é mais difícil de ler o código, mais difícil de entender o código e erros estranhos que são terrivelmente difíceis de entender sem estar intimamente familiarizado com o porquê da 'classe' escopo é totalmente diferente de qualquer outro escopo python.
fonte
except myInstanceObj.CustomError, e:
Você pode usar uma classe como gerador de classe. Como (em alguns códigos improvisados :)
Eu sinto que quando você precisar dessa funcionalidade, ela ficará muito clara para você. Se você não precisa fazer algo semelhante, provavelmente não é um bom caso de uso.
fonte
Não, composição não significa aninhamento. Faria sentido ter uma classe aninhada se você quiser ocultá-la mais no namespace da classe externa.
De qualquer forma, não vejo nenhuma utilidade prática para aninhamento no seu caso. Isso tornaria o código mais difícil de ler (entender) e também aumentaria o recuo, o que tornaria as linhas mais curtas e mais sujeitas a divisão.
fonte