Come si chiama questo modello / tecnica?

Non penso che questo sia un modello di design in quanto tale (almeno non da solo). A me sembra che tu stia utilizzando la reflection per semplificare la registrazione quando usi un contenitore IoC.

Ad esempio, se hai più risolutori di problemi per i tuoi problemi e hai qualcosa del genere:

public interface ISolveProblems<T> where T: Problem
{
    void Solve(T problem);
}

public abstract class Problem
{
}

public class BigProblem : Problem
{
}

public class BigProblemSolver : ISolveProblems<BigProblem>
{
    public void Solve(BigProblem problem)
    {
        // do whatever
    }
}

public class SomeOtherBigProblemSolver : ISolveProblems<BigProblem>
{
    public void Solve(BigProblem problem)
    {
        // do whatever
    }
}

Quindi registrare tutto a mano è un problema una volta che hai centinaia di cose, ma usando il reflection puoi collegare tutto molto facilmente all'avvio dell'applicazione. Questa non è una catena di responsabilità, anche se puoi farlo anche con questa tecnica.

Non sono sicuro che questo abbia un nome specifico, ma in generale penso che avere le cose impostate in un modo che permetta di avere una "architettura collegabile".

È essenzialmente una versione leggermente modificata del modello Chain of Responsibility , direttamente fuori dal GoF.

Nel COR, un oggetto comando viene indirizzato a un dispatcher, che fa riferimento a diversi gestori, ognuno dei quali dichiara (di solito tramite un metodo, ma tramite attributi o convenzioni va bene) indipendentemente dal fatto che siano in grado di gestire o meno il comando comando. Se è così, allora lo gestiscono; in caso contrario, passa al gestore successivo.

Non sono sicuro che sia il modello di Chain of Responsibility in questo caso. Stai sostituendo affermazioni esplicite con una riflessione (tipo di una meta-programmazione) basata su convenzioni di denominazione. Mi sembra che tu stia da qualche parte tra DSL e IOC .

Ho un modello alternativo - ho un dizionario che associa valori a puntatori di funzioni / lambdas ecc.

La versione di Python (C # e C e C ++ e molti altri possono fare anche questo)

>>> def p1(): print("hi")
... 
>>> def p2(): print("hello")
... 
>>> d = {'p1' : p1, 'p2' : p2} 
>>> d['p1']()
hi
>>> 

Si chiama Localizzatore di servizio e viene utilizzato in molti posti, incluso OSGI. Tranne che i localizzatori di solito non eseguono la scansione delle classi, ma usano alcuni file di configurazione. Numerose app basate su plugin sono implementate su OSGI, inclusi Eclipse e Android.

Un modello simile può essere trovato in un'altra app basata su plugin - Netbeans, il meccanismo chiamato "ricerca". Specifica un'interfaccia e ricevi la sua implementazione.

Sembra una combinazione del Pattern di strategia e Modelli metodo di fabbrica per me.

Factory / Factory Method Pattern
The factory method pattern is an object-oriented design pattern to implement the concept of factories. Like other creational patterns, it deals with the problem of creating objects (products) without specifying the exact class of object that will be created.

Strategy Pattern
In computer programming, the strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime. Formally speaking, the strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

I due modelli sono spesso used in combinazione l'uno con l'altro come il modello Method Factory si occupa del meccanismo con cui vengono istanziati gli oggetti corretti (è un pattern creazionale ), e il Pattern della strategia si occupa di come vengono utilizzati e selezionati i diversi algoritmi implementati dai diversi oggetti creati dal Pattern di fabbrica (poiché è un modello comportamentale ).

Certamente, è most spesso il Pattern Strategico che viene utilizzato come meccanismo per sostituire l'eccessivo switch o case selezioni.