IoC / DI neden Python'da yaygın değil?

Java'da IoC / DI , web uygulamalarında, neredeyse tüm mevcut çerçevelerde ve Java EE'de yaygın olarak kullanılan çok yaygın bir uygulamadır. Öte yandan, birçok büyük Python web uygulaması da var, ancak Zope'un yanı sıra (duyduğum kod için gerçekten korkunç olmalı) IoC'nin Python dünyasında çok yaygın olmadığı görülüyor. (Yanlış olduğumu düşünüyorsanız lütfen bazı örnekler verin).

Elbette Python, springpython için popüler Java IoC çerçevelerinin birkaç klonu vardır . Ancak bunların hiçbiri pratikte kullanılmıyor gibi görünüyor. En azından, böyle bir şey kullanan bir Django veya sqlalchemy + <insert your favorite wsgi toolkit here>tabanlı web uygulamasına hiç rastlamadım .

Bence IoC'nin makul avantajları var ve örneğin django-default-user-modelini değiştirmeyi kolaylaştıracaktı, ancak Python'daki arayüz sınıflarının ve IoC'nin yaygın kullanımı biraz tuhaf görünüyor ve »pythonic« değil. Ama belki birinin daha iyi bir açıklaması var, IoC neden Python'da yaygın olarak kullanılmıyor.

Aslında DI / IoC olduğunu sanmıyorum o Python nadir. Ne olduğunu nadir, ancak, DI / IoC olan çerçeveler / konteynerler .

Bir düşünün: DI konteyneri ne yapar? Yapmanıza izin verir

1. bağımsız bileşenleri birlikte eksiksiz bir uygulamaya bağlayın ...
2. ... işlem esnasında.

"Birlikte kablolama" ve "çalışma zamanında" için isimlerimiz var:

1. betik
2. dinamik

Dolayısıyla, bir DI kapsayıcısı dinamik bir kodlama dili için bir yorumlayıcıdan başka bir şey değildir. Aslında şunu ifade edeyim: tipik bir Java / .NET DI kapsayıcısı, popo çirkin, bazen XML tabanlı sözdizimi ile gerçekten kötü bir dinamik komut dosyası dili için berbat bir yorumlayıcıdan başka bir şey değildir.

Python'da program yaparken, emrinizde güzel, parlak bir betik diliniz olduğunda neden çirkin, kötü bir betik dili kullanmak istersiniz? Aslında, bu daha genel bir soru: hemen hemen her dilde programladığınızda, Jython ve IronPython'unuz olduğunda neden çirkin, kötü bir komut dosyası dili kullanmak istersiniz?

Özetlemek gerekirse: DI / IoC uygulaması Python'da Java'da olduğu gibi aynı nedenlerle önemlidir. Uygulama DI / IoC ait Ancak diline inşa edilmiştir ve tamamen kaybolur sık sık bu yüzden hafif.

(Bir benzetmenin kısa bir kenarı: montajda, bir alt program çağrısı oldukça büyük bir anlaşma - yerel değişkenlerinizi ve kayıtlarınızı belleğe kaydetmeniz, dönüş adresinizi bir yere kaydetmeniz, talimat işaretçisini aradığınız alt rutine değiştirmeniz, bittiğinde bir şekilde alt rutininize atlamasını sağlayın, argümanları callee'nin bulabileceği bir yere koyun, vb. IOW: montajda, "altyordam çağrısı" bir Tasarım Deseni ve daha önce gibi diller vardı Yerleşik alt program çağrıları olan Fortran, insanlar kendi "alt program çerçevelerini" inşa ediyorlardı. Alt program çerçevelerini kullanmamanız nedeniyle alt program çağrılarının Python'da "nadir" olduğunu söyleyebilir misiniz?)

BTW: Bu mantıksal sonucuna DI almaya neye benzediğini bir örnek için, bir göz atın Gilad Bracha 'ın Dili Programlama tellalların konuyla ilgili ve onun yazıları:

• Zararlı Olarak Değerlendirilen Yapıcılar
• Ölümcül enjeksiyon
• İthalat Yasağı ( devam )

Bunun bir kısmı modül sisteminin Python'da çalışma şeklidir. Sadece bir modülden içe aktararak bir çeşit "singleton" ücretsiz alabilirsiniz. Modüldeki bir nesnenin gerçek bir örneğini tanımladığınızda, herhangi bir istemci kodu onu içe aktarabilir ve gerçekten çalışan, tamamen oluşturulmuş / doldurulmuş bir nesne alabilir.

Bu, nesnelerin gerçek örneklerini içe aktarmadığınız Java'nın tersidir. Bu, onları her zaman kendiniz başlatmanız gerektiği anlamına gelir (veya bir çeşit IoC / DI tarzı yaklaşım kullanın). Statik fabrika yöntemleri (veya gerçek fabrika sınıfları) kullanarak her şeyi kendiniz başlatmanın zorluğunu azaltabilirsiniz, ancak yine de her seferinde yenilerini yaratmanın kaynak yüküne maruz kalırsınız.

IoC ve DI, olgun Python kodunda süper yaygındır. Ördek yazımı sayesinde DI'yi uygulamak için bir çerçeveye ihtiyacınız yok.

En iyi örnek, Django uygulamasını şu şekilde kullanarak nasıl ayarlayacağınızdır 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 DI'yi yoğun olarak kullanıyor:

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

Hatırlatmama izin ver ( kaynak ):

"Bağımlılık Enjeksiyonu" 5 sentlik bir kavram için 25 dolarlık bir terimdir. [...] Bağımlılık enjeksiyonu, bir nesneye örnek değişkenlerini vermek anlamına gelir. [...].

Django, kontrolün ters çevrilmesini büyük ölçüde kullanır. Örneğin, veritabanı sunucusu yapılandırma dosyası tarafından seçilir, ardından çerçeve veritabanı istemcilerine uygun veritabanı sarma örnekleri sağlar.

Fark, Python'un birinci sınıf tiplere sahip olmasıdır. Sınıflar da dahil olmak üzere veri türleri kendileri nesnedir. Belirli bir sınıfı kullanmak için bir şey istiyorsanız, sadece sınıfı adlandırın. Örneğin:

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

Daha sonra kod yazarak bir veritabanı arayüzü oluşturabilir:

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

Java ve C ++ 'ın ihtiyaç duyduğu kazan plakası fabrika işlevleri yerine, Python bunu bir veya iki sıradan kodla yapar. Bu, işlevsel ve zorunlu programlamanın gücüdür.

İnsanların Bağımlılık enjeksiyonunun ve kontrolün ters çevrilmesinin artık ne anlama geldiğini gerçekten görmediğini görüyor.

Denetimi tersine çevirme kullanımı, başka sınıflara veya işlevlere bağlı sınıflara veya işleve sahip olmaktır, ancak işlev kodu sınıfında örnekleri oluşturmak yerine, parametre olarak almak daha iyidir, bu nedenle gevşek bağlantı elde edilebilir. Bu, daha fazla test edilebilirlik ve liskov ikame ilkesine ulaşmak için birçok faydaya sahiptir.

Görüyorsunuz, arayüzler ve enjeksiyonlarla çalışarak, davranışınızı kolayca değiştirebileceğiniz için kodunuz daha anlaşılır hale gelir, çünkü tek bir kod satırını (belki DI yapılandırmasında bir veya iki satır) yeniden yazmak zorunda kalmazsınız. sınıfını, sınıfınızın beklediği arabirimi uygulayan sınıflar, arabirimi izledikleri sürece bağımsız olarak değişebilir. Kodun ayrıştırılmasını ve bakımı kolay tutulması için en iyi stratejilerden biri, en azından tek sorumluluk, ikame ve bağımlılık tersine çevirme ilkelerini takip etmektir.

Bir nesneyi bir paketin içinde kendiniz başlatabilir ve kendiniz enjekte etmek için içe aktarabilirseniz iyi bir DI kütüphanesi nedir? Seçilen cevap doğrudur, çünkü java'nın prosedürel bölümleri (sınıfların dışındaki kodlar) olmadığı için, sıkıcı konfigürasyon xml'lerine giren her şey, bu nedenle tembel bir yük modası üzerinde bağımlılıkları başlatmak ve enjekte etmek için bir sınıfa ihtiyaç vardır, böylece uçup gitmezsiniz. performansınız, python üzerinde ise sadece kodunuzun "prosedürel" (sınıflar dışında kod) bölümlerindeki enjeksiyonları kodlarsınız

Birkaç yıl boyunca Python kullanmadım, ancak dinamik olarak yazılmış bir dil olmaktan başka her şeyden daha çok şey olduğunu söyleyebilirim. Basit bir örnek olarak, Java'da, bir şeyin uygun şekilde standart olarak yazıldığını test etmek istersem, DI'yi kullanabilir ve yazılan metni yakalamak ve doğrulamak için herhangi bir PrintStream'i geçebilirim. Ancak Ruby'de çalışırken, doğrulamak için STDOUT'ta 'koyar' yöntemini dinamik olarak değiştirebilirim, DI'yi tamamen resim dışında bırakabilirim. Bir soyutlama oluşturmamın tek nedeni, onu kullanan sınıfı test etmekse (Dosya sistemi işlemlerini veya Java'da saati düşünün) o zaman DI / IoC çözümde gereksiz karmaşıklık yaratır.

Aslında, DI ile yeterince temiz ve kompakt bir kod yazmak oldukça kolaydır (acaba, o zaman / sonra pythonic olacak mı , ama yine de :)), örneğin ben aslında bu kodlama yolu perefer:

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!

Evet, bu sadece fonksiyonları / sınıfları parametreleştirmenin basit bir biçimi olarak görülebilir, ancak işini yapar. Yani, belki de Python'un varsayılan dahil pilleri burada da yeterlidir.

PS Python'da basit boole mantığını dinamik olarak değerlendirirken bu naif yaklaşımın daha büyük bir örneğini de yayınladım .

IoC / DI bir tasarım konseptidir, ancak maalesef genellikle belirli diller (veya yazım sistemleri) için geçerli bir kavram olarak kabul edilir. Bağımlılık enjeksiyon kaplarının Python'da çok daha popüler hale geldiğini görmek isterim. Bahar var, ama bu bir süper çerçeve ve "Python Way" i dikkate almadan Java kavramlarının doğrudan bir limanı gibi görünüyor.

Python 3'teki Ek Açıklamalar verildiğinde, tam özellikli, ancak basit bir bağımlılık enjeksiyon kabında bir çatlamaya karar verdim: https://github.com/zsims/dic . Bir .NET bağımlılık enjeksiyon kapsayıcısından (o alanda oynuyorsanız IMO'nun harika olduğu) bazı kavramlara dayanmaktadır, ancak Python kavramlarıyla mutasyona uğramıştır.

Python'un dinamik doğası nedeniyle insanların sıklıkla başka bir dinamik çerçeveye ihtiyaç duymadığını düşünüyorum. Bir sınıf yeni stil 'nesnesinden' miras alındığında dinamik olarak yeni bir değişken oluşturabilirsiniz ( https://wiki.python.org/moin/NewClassVsClassicClass ).

yani düz python'da:

#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()

Ancak https://github.com/noodleflake/pyioc adresine bakın, aradığınız şey bu olabilir.

yani pyioc'ta

from libs.service_locator import ServiceLocator

#main.py
ServiceLocator.register(PostgresConnection)

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

"Jörg W Mittag" cevabını geri verdim: "DI / IoC'nin Python uygulaması o kadar hafif ki tamamen yok oluyor".

Bu ifadeyi yedeklemek için Java'dan Python'a taşınan ünlü Martin Fowler örneğine bir göz atın: Python: Design_Patterns: Inversion_of_Control

Yukarıdaki bağlantıdan da görebileceğiniz gibi, Python'da bir "Kapsayıcı" 8 kod satırına yazılabilir:

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

Benim 2 sentim, çoğu Python uygulamasında buna ihtiyaç duymamanız ve ihtiyacınız olsa bile, birçok Java şapkacısının (ve geliştirici olduğuna inanan beceriksiz kemancıların) bunu sadece Java'da popüler olduğu için kötü bir şey olarak görmesidir. .

Bir IoC sistemi aslında, her bir nesnenin diğerlerine bağımlı olabileceği ve kendisi de diğer nesnelere bağımlı olabileceği karmaşık nesne ağlarınız olduğunda yararlıdır. Böyle bir durumda, tüm bu nesneleri bir kez tanımlamak ve bunları mümkün olduğunca fazla örtük kurala dayalı olarak otomatik olarak bir araya getirmek için bir mekanizmaya sahip olmak istersiniz. Uygulama kullanıcısı / yöneticisi tarafından basit bir şekilde tanımlanacak konfigürasyonunuz varsa, bileşenlerini basit bir XML dosyası (konfigürasyon olacaktır) gibi bir şeyden okuyabilen bir IoC sistemini istemenin ek bir nedeni de budur.

Tipik Python uygulaması, bu kadar karmaşık bir mimari olmadan çok daha basit, sadece bir dizi komut dosyasıdır. Şahsen bir IoC'nin gerçekte ne olduğunu biliyorum (burada belirli cevaplar yazanların aksine) ve sınırlı Python deneyimimde buna hiç ihtiyaç duymadım (ayrıca her yerde Spring kullanmıyorum, avantajlar olduğunda verir onun geliştirme yükü haklı değil).

Bununla birlikte, IoC yaklaşımının gerçekten yararlı olduğu Python durumları var ve aslında burada Django'nun kullandığını okudum.

Yukarıdaki aynı mantık, Java dünyasındaki Aspect Oriented Programming'e de uygulanabilir, ancak AOP'nin gerçekten değerli olduğu vaka sayısının daha da sınırlı olması farkı.

pytest fikstür hepsi DI ( kaynak ) dayalı

@Jorg ile DI / IoC'nin Python'da mümkün, daha kolay ve daha güzel olduğu konusunda hemfikirim. Eksik olan, onu destekleyen çerçeveler, ancak birkaç istisna var. Aklıma gelen birkaç örneği işaret etmek için:

• Django yorumları, kendi Yorum sınıfınızı özel mantık ve formlarınızla ilişkilendirmenizi sağlar. [Daha fazla bilgi]

• Django, Kullanıcı modelinize eklemek için özel bir Profil nesnesi kullanmanıza izin verir. Bu tamamen IoC değil, iyi bir yaklaşım. Şahsen ben yorum çerçevesi gibi Kullanıcı modeli delik değiştirmek istiyorum. [Daha fazla bilgi]

Bence, bağımlılık enjeksiyonu gibi şeyler katı ve aşırı karmaşık bir çerçevenin belirtileridir. Kodun ana gövdesi kolayca değiştirilemeyecek kadar ağır hale geldiğinde, küçük parçalarını seçmek, onlar için arayüzler tanımlamak ve daha sonra insanların bu arayüzlere takılan nesneler aracılığıyla davranışlarını değiştirmesine izin vermek zorunda kalırsınız. Her şey yolunda ve iyi, ama ilk etapta bu tür karmaşıklıklardan kaçınmak daha iyidir.

Aynı zamanda statik olarak yazılmış bir dilin belirtisidir. Soyutlamayı ifade etmeniz gereken tek araç kalıtım ise, o zaman hemen hemen her yerde kullandığınız şey budur. Bunu söyledikten sonra, C ++ oldukça benzerdir, ancak Java geliştiricilerinin yaptığı her yerde Builders ve Interfaces ile olan ilgiyi asla yakalayamadı. Çok az jenerik kod az gerçek fayda ile yazmanın pahasına esnek ve genişletilebilir olma hayaliyle aşırı coşkulu olmak kolaydır . Bence bu kültürel bir şey.

Tipik olarak Python insanları, her şey yapabilen ancak olası yapılandırma permütasyonlarının şaşırtıcı bir dizisini sunan One True Tool (Bin Olası Eklentiyle) yerine, tutarlı ve basit bir bütün olan iş için doğru aracı seçmeye alışkın olduğunu düşünüyorum . Gerektiğinde hala değiştirilebilir parçalar vardır, ancak ördek yazmanın esnekliği ve dilin göreceli sadeliği nedeniyle sabit arayüzleri tanımlamanın büyük biçimciliğine gerek yoktur.

Java güçlü yazılan doğanın aksine. Python'un ördek yazma davranışı, nesneleri etrafta geçirmeyi çok kolaylaştırır.

Java geliştiricileri, sınıf esnekliğini ve nesneler arasındaki ilişkiyi oluşturmaya odaklanırken, işleri esnek tutarlar. IoC bunu başarmak için son derece önemlidir.

Python geliştiricileri işi bitirmeye odaklanıyor. Sadece ihtiyaç duyduklarında sınıfları bağlarlar. Sınıfın türü hakkında endişelenmelerine bile gerek yok. Sürdürebildiği sürece, bu bir ördek! Bu doğa IoC'ye yer bırakmıyor.