Perché IoC / DI non è comune in Python?

In Java IoC / DI è una pratica molto comune che viene ampiamente utilizzata nelle applicazioni Web, quasi tutti i framework disponibili e Java EE. D'altra parte, ci sono anche molte grandi applicazioni Web Python, ma a parte Zope (che ho sentito dovrebbe essere davvero orribile da codificare) l'IoC non sembra essere molto comune nel mondo Python. (Per favore, nomina alcuni esempi se pensi che mi sbagli).

Esistono ovviamente diversi cloni di famosi framework IoC Java disponibili per Python, ad esempio springpython . Ma nessuno di loro sembra abituarsi praticamente. Almeno, non mi sono mai imbattuto in un'applicazione web basata su Django o sqlalchemy + <insert your favorite wsgi toolkit here>che utilizza qualcosa del genere.

A mio avviso, l'IoC presenta vantaggi ragionevoli e semplificherebbe la sostituzione del modello django-default-user, ad esempio, ma l'uso estensivo di classi di interfaccia e IoC in Python sembra un po 'strano e non "pythonic". Ma forse qualcuno ha una spiegazione migliore, perché l'IoC non è ampiamente usato in Python.

In realtà non penso che DI / IoC siano così rari in Python. Ciò che è insolito, tuttavia, sono i framework / container DI / IoC .

Pensaci: cosa fa un contenitore DI? Te lo permette

1. collega componenti indipendenti in un'applicazione completa ...
2. ... in fase di esecuzione.

Abbiamo nomi per "cablaggio insieme" e "in fase di esecuzione":

1. scripting
2. dinamico

Quindi, un contenitore DI non è altro che un interprete per un linguaggio di script dinamico. In realtà, lascia che lo riformuli: un tipico contenitore DI Java / .NET non è altro che un brutto interprete per un linguaggio di scripting dinamico davvero brutto con una sintassi brutta, a volte basata su XML.

Quando programmi in Python, perché dovresti voler usare un brutto e brutto linguaggio di scripting quando hai un linguaggio di scripting bello e brillante a tua disposizione? In realtà, questa è una domanda più generale: quando programmi in quasi tutte le lingue, perché dovresti usare un brutto e brutto linguaggio di scripting quando hai Jython e IronPython a tua disposizione?

Quindi, per ricapitolare: la pratica di DI / IoC è altrettanto importante in Python come in Java, esattamente per gli stessi motivi. L' implementazione di DI / IoC, tuttavia, è integrata nel linguaggio e spesso così leggera da svanire completamente.

(Ecco un breve accenno per un'analogia: nell'assemblaggio, una chiamata di subroutine è un affare piuttosto importante: devi salvare le variabili locali e i registri in memoria, salvare l'indirizzo di ritorno da qualche parte, cambiare il puntatore delle istruzioni alla subroutine che stai chiamando, fai in modo che salti in qualche modo nella tua subroutine quando è finita, metti gli argomenti da qualche parte in cui la chiamata può trovarli, e così via. IOW: nell'assemblaggio, "chiamata alla subroutine" è un modello di progettazione, e prima che esistessero lingue come Fortran che aveva chiamate subroutine incorporate, la gente stava costruendo i propri "framework subroutine". Diresti che le chiamate subroutine sono "non comuni" in Python, solo perché non usi i framework subroutine?)

BTW: per un esempio di quello che sembra a prendere DI alla sua logica conclusione, dare un'occhiata a Gilad Bracha 's Neolingua linguaggio di programmazione ed i suoi scritti sul tema:

• Costruttori considerati dannosi
• Iniezione letale
• Un divieto di importazione ( continua )

Parte di esso è il modo in cui il sistema di moduli funziona in Python. Puoi ottenere una sorta di "singleton" gratuitamente, semplicemente importandolo da un modulo. Definire un'istanza effettiva di un oggetto in un modulo, quindi qualsiasi codice client può importarlo e ottenere effettivamente un oggetto funzionante, completamente costruito / popolato.

Ciò è in contrasto con Java, dove non si importano istanze effettive di oggetti. Ciò significa che devi sempre istanziarli tu stesso (o utilizzare una sorta di approccio in stile IoC / DI). Puoi mitigare il fastidio di dover istanziare tutto da solo disponendo di metodi factory statici (o classi factory effettive), ma poi incorri ancora nel sovraccarico di risorse di crearne di nuovi ogni volta.

IoC e DI sono super comuni nel codice Python maturo. Semplicemente non hai bisogno di un framework per implementare DI grazie alla digitazione duck.

Il miglior esempio è come si configura un'applicazione Django usando settings.py:

# settings.py
CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': REDIS_URL + '/1',
    },
    'local': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'snowflake',
    }
}

Django Rest Framework utilizza DI pesantemente:

class FooView(APIView):
    # The "injected" dependencies:
    permission_classes = (IsAuthenticated, )
    throttle_classes = (ScopedRateThrottle, )
    parser_classes = (parsers.FormParser, parsers.JSONParser, parsers.MultiPartParser)
    renderer_classes = (renderers.JSONRenderer,)

    def get(self, request, *args, **kwargs):
        pass

    def post(self, request, *args, **kwargs):
        pass

Lasciami ricordare ( fonte ):

"Iniezione delle dipendenze" è un termine di 25 dollari per un concetto da 5 cent. [...] Iniezione di dipendenza significa dare a un oggetto le sue variabili di istanza. [...].

Django fa grande uso dell'inversione del controllo. Ad esempio, il server di database è selezionato dal file di configurazione, quindi il framework fornisce le istanze appropriate del wrapper di database ai client del database.

La differenza è che Python ha tipi di prima classe. I tipi di dati, comprese le classi, sono essi stessi oggetti. Se vuoi che qualcosa utilizzi una determinata classe, è sufficiente nominare la classe. Per esempio:

if config_dbms_name == 'postgresql':
    import psycopg
    self.database_interface = psycopg
elif config_dbms_name == 'mysql':
    ...

Il codice successivo può quindi creare un'interfaccia del database scrivendo:

my_db_connection = self.database_interface()
# Do stuff with database.

Invece delle funzioni di fabbrica del boilerplate di cui hanno bisogno Java e C ++, Python lo fa con una o due righe di codice ordinario. Questa è la forza della programmazione funzionale contro imperativa.

Sembra che le persone non capiscano davvero cosa significhino l'iniezione di dipendenza e l'inversione del controllo.

La pratica di utilizzare l'inversione del controllo è quella di avere classi o funzioni che dipendono da altre classi o funzioni, ma invece di creare le istanze all'interno della classe del codice funzione è meglio riceverlo come parametro, quindi l'accoppiamento libero può essere archiviato. Ciò comporta numerosi vantaggi, in quanto maggiore testabilità e l'archiviazione del principio di sostituzione di Mosca.

Vedi, lavorando con interfacce e iniezioni, il tuo codice diventa più gestibile, dal momento che puoi cambiare facilmente il comportamento, perché non dovrai riscrivere una singola riga di codice (forse una o due righe sulla configurazione DI) del tuo classe per modificarne il comportamento, poiché le classi che implementano l'interfaccia che la tua classe sta aspettando possono variare indipendentemente fintanto che seguono l'interfaccia. Una delle migliori strategie per mantenere il codice disaccoppiato e facile da mantenere è seguire almeno i singoli principi di inversione di responsabilità, sostituzione e dipendenza.

A cosa serve una libreria DI se puoi istanziare un oggetto da solo all'interno di un pacchetto e importarlo per iniettarlo tu stesso? La risposta scelta è giusta, dal momento che java non ha sezioni procedurali (codice al di fuori delle classi), tutto ciò che va in noiosi xml di configurazione, quindi la necessità di una classe per istanziare e iniettare dipendenze su un modo di caricamento pigro in modo da non soffiare via la tua performance, mentre su Python devi solo codificare le iniezioni nelle sezioni "procedurali" (codice al di fuori delle classi) del tuo codice

Non uso Python da diversi anni, ma direi che ha più a che fare con il fatto che sia un linguaggio tipizzato dinamicamente che altro. Per un semplice esempio, in Java, se volessi provare che qualcosa è stato scritto in modo appropriato per standardizzare, potrei usare DI e passare qualsiasi PrintStream per catturare il testo che viene scritto e verificarlo. Quando lavoro in Ruby, tuttavia, posso sostituire dinamicamente il metodo 'put' su STDOUT per fare la verifica, lasciando DI completamente fuori dal quadro. Se l'unica ragione per cui sto creando un'astrazione è testare la classe che la sta utilizzando (pensa alle operazioni del file system o all'orologio in Java), DI / IoC crea complessità inutili nella soluzione.

In realtà, è abbastanza facile scrivere codice sufficientemente pulito e compatto con DI (mi chiedo, sarà / rimarrà pitonico allora, ma comunque :)), per esempio in realtà approfondisco questo modo di codificare:

def polite(name_str):
    return "dear " + name_str

def rude(name_str):
    return name_str + ", you, moron"

def greet(name_str, call=polite):
    print "Hello, " + call(name_str) + "!"

_

>>greet("Peter")
Hello, dear Peter!
>>greet("Jack", rude)
Hello, Jack, you, moron!

Sì, questo può essere visto come una semplice forma di parametrizzazione di funzioni / classi, ma fa il suo lavoro. Quindi, forse anche le batterie incluse in Python sono sufficienti qui.

PS Ho anche pubblicato un esempio più ampio di questo approccio ingenuo alla valutazione dinamica di una semplice logica booleana in Python .

IoC / DI è un concetto di design, ma sfortunatamente è spesso preso come un concetto che si applica a determinati linguaggi (o sistemi di battitura). Mi piacerebbe vedere i contenitori per iniezione di dipendenza diventare molto più popolari in Python. C'è Spring, ma questo è un super-framework e sembra essere una porta diretta dei concetti Java senza molta considerazione per "The Python Way".

Considerate le annotazioni in Python 3, ho deciso di avere una crepa in un contenitore di iniezione di dipendenza completo, ma semplice: https://github.com/zsims/dic . È basato su alcuni concetti di un contenitore di iniezione di dipendenze .NET (che IMO è fantastico se stai giocando in quello spazio), ma mutato con i concetti di Python.

Penso che a causa della natura dinamica di Python le persone non vedano spesso la necessità di un altro framework dinamico. Quando una classe eredita dal nuovo 'oggetto' di stile, puoi creare una nuova variabile in modo dinamico ( https://wiki.python.org/moin/NewClassVsClassicClass ).

cioè in pitone semplice:

#application.py
class Application(object):
    def __init__(self):
        pass

#main.py
Application.postgres_connection = PostgresConnection()

#other.py
postgres_connection = Application.postgres_connection
db_data = postgres_connection.fetchone()

Tuttavia dai un'occhiata a https://github.com/noodleflake/pyioc questo potrebbe essere quello che stai cercando.

vale a dire in pioioc

from libs.service_locator import ServiceLocator

#main.py
ServiceLocator.register(PostgresConnection)

#other.py
postgres_connection = ServiceLocator.resolve(PostgresConnection)
db_data = postgres_connection.fetchone()

Appoggio la risposta di "Jörg W Mittag": "L'implementazione Python di DI / IoC è così leggera che svanisce completamente".

Per eseguire il backup di questa affermazione, dai un'occhiata al famoso esempio di Martin Fowler portato da Java a Python: Python: Design_Patterns: Inversion_of_Control

Come puoi vedere dal link sopra, un "Contenitore" in Python può essere scritto in 8 righe di codice:

class Container:
    def __init__(self, system_data):
        for component_name, component_class, component_args in system_data:
            if type(component_class) == types.ClassType:
                args = [self.__dict__[arg] for arg in component_args]
                self.__dict__[component_name] = component_class(*args)
            else:
                self.__dict__[component_name] = component_class

Il mio 2 centesimi è che nella maggior parte delle applicazioni Python non ne hai bisogno e, anche se ne avevi bisogno, è probabile che molti odiatori di Java (e violinisti incompetenti che credono di essere sviluppatori) lo considerino qualcosa di brutto, solo perché è popolare in Java .

Un sistema IoC è effettivamente utile quando si hanno reti complesse di oggetti, in cui ogni oggetto può essere una dipendenza per molti altri e, a sua volta, essere esso stesso dipendente da altri oggetti. In tal caso, dovrai definire tutti questi oggetti una volta e disporre di un meccanismo per metterli insieme automaticamente, in base al maggior numero possibile di regole implicite. Se hai anche la configurazione che deve essere definita in modo semplice dall'utente / amministratore dell'applicazione, questo è un motivo in più per desiderare un sistema IoC in grado di leggere i suoi componenti da qualcosa come un semplice file XML (che sarebbe la configurazione).

La tipica applicazione Python è molto più semplice, solo un mucchio di script, senza un'architettura così complessa. Personalmente sono consapevole di cosa sia effettivamente un IoC (contrariamente a quelli che hanno scritto alcune risposte qui) e non ho mai sentito il bisogno di farlo nella mia esperienza Python limitata (inoltre non uso Spring ovunque, non quando i vantaggi dà non giustificare il suo sovraccarico di sviluppo).

Detto questo, ci sono situazioni Python in cui l'approccio IoC è effettivamente utile e, in effetti, ho letto qui che Django lo usa.

Lo stesso ragionamento sopra potrebbe essere applicato alla programmazione orientata agli aspetti nel mondo Java, con la differenza che il numero di casi in cui AOP è veramente utile è ancora più limitato.

apparecchi pytest tutti basati su DI ( sorgente )

Concordo con @Jorg sul fatto che DI / IoC è possibile, più facile e ancora più bello in Python. Ciò che manca sono i framework che lo supportano, ma ci sono alcune eccezioni. Per indicare un paio di esempi che mi vengono in mente:

• I commenti di Django ti consentono di collegare la tua classe di commenti con la tua logica e i tuoi moduli personalizzati. [Ulteriori informazioni]

• Django ti consente di utilizzare un oggetto profilo personalizzato da collegare al tuo modello utente. Questo non è completamente IoC ma è un buon approccio. Personalmente vorrei sostituire il modello utente del foro come fa il framework dei commenti. [Ulteriori informazioni]

A mio avviso, cose come l'iniezione di dipendenza sono sintomi di un quadro rigido e troppo complesso. Quando il corpo principale del codice diventa troppo pesante per cambiare facilmente, ti ritrovi a doverne raccogliere piccole parti, definirne le interfacce e quindi consentire alle persone di cambiare comportamento attraverso gli oggetti che si collegano a quelle interfacce. Va bene e va bene, ma è meglio evitare quel tipo di complessità in primo luogo.

È anche il sintomo di un linguaggio tipicamente statico. Quando l'unico strumento che devi esprimere per astrazione è l'eredità, allora è praticamente quello che usi ovunque. Detto questo, C ++ è piuttosto simile ma non ha mai suscitato il fascino di Builders e Interfaces ovunque che gli sviluppatori Java abbiano fatto. È facile esagerare con il sogno di essere flessibile ed estensibile al costo di scrivere troppi codici generici con pochi vantaggi reali . Penso che sia una cosa culturale.

In genere penso che le persone di Python siano abituate a scegliere lo strumento giusto per il lavoro, che è un insieme coerente e semplice, piuttosto che lo strumento One True (With A Thousand Possible Plugins) che può fare qualsiasi cosa ma offre una serie sconcertante di possibili permutazioni di configurazione . Ci sono ancora parti intercambiabili ove necessario, ma senza la necessità del grande formalismo di definire interfacce fisse, a causa della flessibilità della tipizzazione anatra e della relativa semplicità del linguaggio.

A differenza della forte natura tipizzata in Java. Il comportamento di battitura delle anatre di Python semplifica il passaggio degli oggetti.

Gli sviluppatori Java si stanno concentrando sulla costruzione della struttura di classe e della relazione tra oggetti, mantenendo le cose flessibili. L'IoC è estremamente importante per raggiungere questo obiettivo.

Gli sviluppatori di Python si stanno concentrando sull'ottenere il lavoro svolto. Collegano le lezioni quando ne hanno bisogno. Non devono nemmeno preoccuparsi del tipo di classe. Finché può ciarlare, è un'anatra! Questa natura non lascia spazio all'IoC.