É sempre uma boa idéia usar o nome do padrão de design nas classes de implementação? [fechadas]

Recentemente me deparei com um moderadamente grande base de código python com lotes de MyClassAbstractFactory, MyClassManager, MyClassProxy, MyClassAdapteretc. classes.

Embora, por um lado, esses nomes me indicassem pesquisar e aprender os padrões correspondentes, eles não eram muito descritivos do que a classe faz .

Além disso, eles parecem cair dentro da lista proibida de palavras na programação: variable, process_available_information, data, amount, compute: nomes excessivamente amplas, que não nos diz nada sobre a função quando usado por si só .

Então deveria haver CommunicationManagerou melhor PortListener? Ou talvez eu não entenda o problema ...?

• AbstractFactoryé de fato uma má escolha para um nome. Não há como saber o que é criado por esta fábrica e, quando você procurar uma entidade que cria Animals, nunca encontrará a fábrica correspondente pelo nome.

• AnimalAbstractFactorytambém não é uma escolha sábia, pois na maioria dos idiomas seria redundante com a abstractpalavra - chave na assinatura.

  Dito isto, existem várias boas razões, destacadas pelos comentários, para realmente incluir Abstractno nome: não apenas existem vários contextos em que você não tem a assinatura completa, mas apenas o nome, mas também mantendo AnimalFactoryuma interface pode ser uma escolha sábia (a menos que, infelizmente, a convenção da linguagem / estrutura seja prefixar as interfaces com I).

• AnimalCreationUtilitytambém seria uma má escolha: se for uma fábrica , facilite as coisas para as pessoas que lerão o código e a chamem de fábrica .

• abstract AnimalFactoryestá bem Não possui redundância e é claro que é uma fábrica abstrata que delega a criação de animais a seus filhos.

Portanto, sim, incluir o nome do padrão de design é uma boa ideia, mas deve ser apenas uma parte do nome e não deve ser redundante com as outras partes da assinatura.

Depende do exemplo específico. O padrão Builder quase sempre é melhor atendido ao nomear sua classe * Builder, enquanto um Singleton geralmente não precisa ser nomeado como tal.

Se você não colocar o nome do padrão no nome da sua classe, e talvez até o faça, geralmente coloque um comentário na classe que explique que ele implementa um padrão específico.

O objetivo de usar nomes de padrões nas classes é facilitar a compreensão do que a classe faz. Se você nomear a classe AnimalFactory, é óbvio que a classe cria instâncias Animal. Se o nome da sua classe incluir o nome de um padrão e ele não descrever o que faz, você escolheu um padrão errado ou o implementou incorretamente.

Eu acho que pode funcionar muito bem. Por exemplo:

// Command for retrying card entry with CVN.
public class RetryCardEntryWithCVNCommand { ... }

// Query for getting expired accounts
public class GetExpiredAccountsQuery { ... }

// Decorator for logging exception. Implies that it's an additional 
//mechanism for logging exceptions.
public class LogExceptionToDbDecorator { ... }

// Factory for creating account filters
public class AccountFilterFactory { ... }