Troppi suffissi di pattern & # 8221; - odore di design?

Question

Mi sono appena trovato a creare una classe chiamata " InstructionBuilderFactoryMapFactory " ;. Questo è 4 "suffissi di pattern" su una classe. Mi ha subito ricordato questo:

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

È un odore di design? Devo imporre un limite a questo numero?

So che alcuni programmatori hanno regole simili per altre cose (ad es. non più di N livelli di indiretta del puntatore in C.)

Tutte le lezioni mi sembrano necessarie. Ho una mappa (fissa) dalle stringhe alle fabbriche, cosa che faccio sempre. L'elenco si sta allungando e voglio spostarlo fuori dal costruttore della classe che utilizza i costruttori (che sono creati dalle fabbriche che si ottengono dalla mappa ...) E come al solito sto evitando Singletons.

Answer 1

Lo vedo come un odore di design - mi farà pensare se tutti quei livelli di astrazione stanno tirando abbastanza peso.

Non riesco a capire perché tu abbia voluto nominare una classe "InstructionBuilderFactoryMapFactory"? Esistono altri tipi di fabbriche - qualcosa che non crea una InstructionBuilderFactoryMap? O ci sono altri tipi di InstructionBuildersFactories che devono essere mappati?

Queste sono le domande a cui dovresti pensare quando inizi a creare classi come queste. È possibile aggregare tutte quelle diverse fabbriche di fabbrica in una sola e quindi fornire metodi separati per la creazione di fabbriche. È anche possibile mettere quelle fabbrica-fabbrica in un pacchetto diverso e dare loro un nome più conciso. Pensa a modi alternativi per farlo.

Answer 2

Un buon consiglio è: l'API pubblica di classe (e che include il suo nome) dovrebbe rivelare l'intenzione, non l'implementazione. A me (come cliente) non importa se hai implementato il modello del costruttore o il modello di fabbrica.

Non solo il nome della classe sembra cattivo, ma non dice nulla su ciò che fa. Il suo nome si basa sulla sua implementazione e struttura interna.

Uso raramente un nome di modello in una classe, ad eccezione di (a volte) Fabbriche.

Modifica:

Ho trovato un interessante articolo sulla denominazione di Coding Horror, per favore dai un'occhiata !

Answer 3

Molti schemi in un nome di classe sono sicuramente un odore, ma un odore non è un indicatore definito. È un segnale per "fermarsi per un minuto e ripensare il design". Molte volte quando ti siedi e pensi che una soluzione più chiara diventi evidente. A volte a causa dei vincoli a portata di mano (tecnico / tempo / potere umano / ecc.) Significa che l'odore dovrebbe essere ignorato per ora.

Per quanto riguarda l'esempio specifico, non credo che i suggerimenti della galleria di arachidi siano una buona idea senza più contesto.

Answer 4

Ho pensato la stessa cosa. Nel mio caso, l'abbondanza di fabbriche è causata da "costruire per testabilità". Ad esempio, ho un costruttore come questo:

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

Qui ho un parser - l'ultima classe di cui ho bisogno. Il parser viene creato chiamando metodi su un builder. I costruttori (uno nuovo per ogni parser che deve essere costruito) sono ottenuti dalla fabbrica del costruttore.

Ora, cosa h..l è ParserFactory? Ah, sono felice che tu l'abbia chiesto! Per testare l'implementazione del generatore di parser, devo chiamare il suo metodo e quindi vedere quale tipo di parser è stato creato. L'unico modo per farlo senza interrompere l'incapsulamento della particolare classe del parser che il costruttore sta creando è mettere un punto di intercettazione proprio prima della creazione del parser, per vedere cosa succede nel suo costruttore. Quindi ParserFactory. È solo un modo per me di osservare in un unit test ciò che viene passato al costruttore di un parser.

Non sono del tutto sicuro di come risolverlo, ma ho la sensazione che staremmo meglio nel passare le classi piuttosto che nelle fabbriche, e Java farebbe meglio se potesse avere metodi di classe adeguati piuttosto che membri statici.