เหตุใด IoC / DI จึงไม่ธรรมดาใน Python

ใน Java IoC / DIเป็นวิธีปฏิบัติทั่วไปที่ใช้กันอย่างแพร่หลายในเว็บแอปพลิเคชันเกือบทุกเฟรมเวิร์กที่มีอยู่และ Java EE ในทางกลับกันมีเว็บแอพพลิเคชั่น Python ขนาดใหญ่จำนวนมาก แต่นอกเหนือจาก Zope (ซึ่งฉันได้ยินมาว่าน่ากลัวรหัส) IoC ดูเหมือนจะไม่ธรรมดาในโลก Python (โปรดระบุชื่อตัวอย่างถ้าคุณคิดว่าฉันผิด)

มีแน่นอนหลายโคลนนิ่งนิยม Java IoC กรอบพร้อมใช้งานสำหรับหลามspringpythonตัวอย่างเช่น แต่ดูเหมือนว่าจะไม่มีใครใช้มันได้เลย อย่างน้อยฉันไม่เคยเหยียบย่ำแอปพลิเคชันบนเว็บDjangoหรือsqlalchemy + <insert your favorite wsgi toolkit here>ซึ่งใช้อะไรแบบนั้น

ในความคิดของฉัน IoC มีข้อได้เปรียบที่สมเหตุสมผลและจะทำให้ง่ายต่อการแทนที่ django-default-user-model ตัวอย่างเช่น แต่การใช้อินเตอร์เฟซคลาสที่กว้างขวางและ IoC ใน Python นั้นค่อนข้างแปลกและไม่ใช่ "pythonic « แต่บางคนอาจมีคำอธิบายที่ดีกว่าทำไม IoC ไม่ได้ใช้อย่างกว้างขวางใน Python

ฉันไม่คิดว่าจริง DI / IoC เป็นที่ผิดปกติในหลาม อะไรเป็นเรื่องผิดปกติ แต่มี DI / IoC กรอบ / ภาชนะบรรจุกรอบ

ลองคิดดู: ภาชนะ DI ทำอะไร? จะช่วยให้คุณ

1. รวมส่วนประกอบอิสระเข้าด้วยกันเป็นแอปพลิเคชันที่สมบูรณ์ ...
2. ... ที่รันไทม์

เรามีชื่อสำหรับ "เดินสายเข้าด้วยกัน" และ "ที่รันไทม์":

1. สคริปต์
2. พลวัต

ดังนั้นคอนเทนเนอร์ DI ไม่มีอะไรเลยนอกจากเป็นล่ามสำหรับภาษาสคริปต์แบบไดนามิก ที่จริงฉันขอใช้ถ้อยคำใหม่ว่า: คอนเทนเนอร์ Java / .NET DI ทั่วไปไม่มีอะไรนอกจากล่ามเส็งเคร็งสำหรับภาษาสคริปต์แบบไดนามิกที่ไม่ดีจริงๆพร้อมกับน่าเกลียดบางครั้งใช้ไวยากรณ์ XML

เมื่อคุณเขียนโปรแกรมใน Python ทำไมคุณถึงต้องการใช้ภาษาสคริปต์ที่น่าเกลียดและไม่ดีเมื่อคุณมีภาษาสคริปต์ที่สวยงามและยอดเยี่ยมเมื่อคุณต้องการ ที่จริงแล้วเป็นคำถามที่ทั่วไปมากขึ้น: เมื่อคุณเขียนโปรแกรมในภาษาใดภาษาหนึ่งทำไมคุณต้องการใช้ภาษาสคริปต์ที่น่าเกลียดและไม่ดีเมื่อคุณมี Jython และ IronPython

ดังนั้นการสรุป: การฝึกฝน DI / IoC นั้นสำคัญกับ Python เหมือนกับใน Java ด้วยเหตุผลเดียวกันทั้งหมด การดำเนินการ DI / IoC มาใช้นั้นถูกสร้างขึ้นเป็นภาษาและมีน้ำหนักเบาจนหายไปอย่างสมบูรณ์

(ต่อไปนี้เป็นคำย่อสำหรับการเปรียบเทียบ: ในแอสเซมบลีการเรียกรูทีนย่อยเป็นข้อตกลงที่สำคัญ - คุณต้องบันทึกตัวแปรโลคัลและลงทะเบียนหน่วยความจำบันทึกที่อยู่ผู้ส่งของคุณไว้ที่อื่นเปลี่ยนตัวชี้คำแนะนำเป็นรูทีนย่อย จัดให้มันกระโดดกลับเข้าไปในรูทีนย่อยของคุณเมื่อเสร็จแล้วใส่อาร์กิวเมนต์บางแห่งที่ผู้ค้นหาสามารถพบพวกเขาและอื่น ๆ IOW: ในการประชุม "การเรียกรูทีนย่อย" เป็นรูปแบบการออกแบบและก่อนที่จะมีภาษาเช่น Fortran ซึ่งมีการเรียกรูทีนย่อยในตัวผู้คนกำลังสร้าง "รูทีนย่อยเฟรมเวิร์ก" ของตัวเองคุณจะบอกว่าการเรียกรูทีนย่อยเป็น "ผิดปกติ" ใน Python เพียงเพราะคุณไม่ได้ใช้กรอบย่อยรูทีน

BTW: สำหรับตัวอย่างของสิ่งที่ดูเหมือนว่าจะนำ DI ไปสู่ข้อสรุปเชิงตรรกะลองดูที่ภาษาโปรแกรมของNewspeakของGilad Brachaและงานเขียนของเขาในหัวข้อ:

• ก่อสร้างถือว่าเป็นอันตราย
• ฉีดตาย
• ห้ามนำเข้า ( ต่อ )

ส่วนหนึ่งเป็นวิธีที่ระบบโมดูลทำงานใน Python คุณสามารถรับ "ซิงเกิลตัน" ได้ฟรีเพียงแค่นำเข้ามันจากโมดูล กำหนดอินสแตนซ์ที่แท้จริงของวัตถุในโมดูลและจากนั้นรหัสลูกค้าใด ๆ ที่สามารถนำเข้าและจริง ๆ แล้วได้รับวัตถุทำงาน / สร้างขึ้นอย่างสมบูรณ์

ตรงกันข้ามกับ Java ซึ่งคุณไม่ได้นำเข้าอินสแตนซ์ของวัตถุที่แท้จริง ซึ่งหมายความว่าคุณจะต้องยกตัวอย่างพวกเขาด้วยตัวเองเสมอ (หรือใช้แนวทางสไตล์ IoC / DI บางประเภท) คุณสามารถลดความยุ่งยากในการสร้างอินสแตนซ์ทุกอย่างด้วยตนเองโดยใช้วิธีการแบบคงที่จากโรงงาน (หรือคลาสโรงงานจริง) แต่จากนั้นคุณยังคงต้องใช้ทรัพยากรในการสร้างสิ่งใหม่ในแต่ละครั้ง

IoC และ DI นั้นพบได้ทั่วไปในรหัส Python ที่เป็นผู้ใหญ่ คุณไม่จำเป็นต้องมีกรอบในการใช้ DI เนื่องจากการพิมพ์เป็ด

ตัวอย่างที่ดีที่สุดคือวิธีการตั้งค่าแอปพลิเคชัน Django โดยใช้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 อย่างหนัก:

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

ให้ฉันเตือน (ที่มา ):

"การพึ่งพาการฉีด" เป็นคำที่ 25 ดอลลาร์สำหรับแนวคิด 5 เซ็นต์ [... ] การฉีดพึ่งพาหมายถึงการให้วัตถุตัวแปรอินสแตนซ์ของมัน [ ... ]

Django ใช้ประโยชน์จากการควบคุมแบบผกผัน ตัวอย่างเช่นเซิร์ฟเวอร์ฐานข้อมูลถูกเลือกโดยไฟล์กำหนดค่าจากนั้นเฟรมเวิร์กจะจัดเตรียมอินสแตนซ์ wrapper ฐานข้อมูลที่เหมาะสมให้กับฐานข้อมูลไคลเอ็นต์

ความแตกต่างคืองูใหญ่มีประเภทชั้นหนึ่ง ชนิดข้อมูลรวมถึงคลาสเป็นวัตถุของตัวเอง หากคุณต้องการบางสิ่งบางอย่างในการใช้คลาสเฉพาะให้ตั้งชื่อคลาสนั้น ตัวอย่างเช่น:

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

รหัสหลังจากนั้นสามารถสร้างส่วนต่อประสานฐานข้อมูลโดยการเขียน:

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

แทนที่จะเป็นฟังก์ชั่นจากโรงงานสำเร็จรูปที่ Java และ C ++ ต้องการ Python ใช้รหัสธรรมดาหนึ่งหรือสองบรรทัด นี่คือจุดแข็งของการทำงานกับการเขียนโปรแกรมที่จำเป็น

มันเห็นว่าผู้คนไม่ได้รับสิ่งที่พึ่งพาการฉีดและการผกผันของการควบคุมหมายถึงอีกต่อไป

วิธีปฏิบัติในการใช้การควบคุมการผกผันคือการมีคลาสหรือฟังก์ชั่นที่ขึ้นอยู่กับคลาสหรือฟังก์ชั่นอื่น แต่แทนที่จะสร้างอินสแตนซ์ซึ่งในคลาสของฟังก์ชั่นรหัสจะเป็นการดีกว่าที่จะรับมันเป็นพารามิเตอร์ นั่นมีประโยชน์มากมายเช่นเดียวกับความสามารถในการทดสอบได้มากกว่าและเพื่อให้เข้าใจหลักการการทดแทน liskov

คุณเห็นโดยการทำงานกับส่วนต่อประสานและการฉีดรหัสของคุณจะได้รับการบำรุงรักษามากขึ้นเนื่องจากคุณสามารถเปลี่ยนพฤติกรรมได้อย่างง่ายดายเพราะคุณไม่จำเป็นต้องเขียนรหัสบรรทัดเดียวอีกครั้ง (อาจเป็นหนึ่งหรือสองบรรทัดในการกำหนดค่า DI) คลาสที่จะเปลี่ยนพฤติกรรมของมันเนื่องจากคลาสที่ใช้อินเทอร์เฟซที่คลาสของคุณกำลังรออยู่อาจแตกต่างกันอย่างอิสระตราบใดที่พวกเขาติดตามอินเตอร์เฟส หนึ่งในกลยุทธ์ที่ดีที่สุดในการรักษารหัส decoupled และง่ายต่อการบำรุงรักษาก็คือการปฏิบัติตามหลักการความรับผิดชอบการสับเปลี่ยนและการพึ่งพาอย่างน้อยหนึ่งครั้ง

ห้องสมุด DI เหมาะสำหรับอะไรถ้าคุณสามารถสร้างอินสแตนซ์วัตถุด้วยตนเองภายในแพ็คเกจและนำเข้ามันเพื่อฉีดด้วยตัวเอง? คำตอบที่เลือกนั้นถูกต้องเนื่องจาก java ไม่มีส่วนของโพรซีเดอร์ (โค้ดด้านนอกของคลาส) ทั้งหมดที่เข้าสู่การกำหนดค่า xml ที่น่าเบื่อดังนั้นความต้องการของชั้นเรียนในการสร้างอินสแตนซ์และการพึ่งพาการโหลดแบบขี้เกียจ ประสิทธิภาพการทำงานของคุณในขณะที่อยู่บนงูหลามคุณเพียงเขียนโค้ดส่วนที่ "ขั้นตอน" (รหัสนอกคลาส) ของโค้ดของคุณ

ไม่ได้ใช้ Python มาหลายปีแล้ว แต่ฉันจะบอกว่ามันเกี่ยวข้องกับการเป็นภาษาที่พิมพ์แบบไดนามิกมากกว่าสิ่งอื่นใด ตัวอย่างง่ายๆใน Java ถ้าฉันต้องการทดสอบว่าสิ่งที่เขียนถึงมาตรฐานอย่างเหมาะสมฉันสามารถใช้ DI และส่งผ่านใน PrintStream ใด ๆ เพื่อจับภาพข้อความที่เขียนและตรวจสอบ เมื่อฉันทำงานใน Ruby แต่ฉันสามารถแทนที่วิธี 'puts' บน STDOUT แบบไดนามิกเพื่อทำการตรวจสอบได้โดยปล่อย DI ออกจากภาพโดยสมบูรณ์ หากเหตุผลเดียวที่ฉันสร้างนามธรรมคือการทดสอบคลาสที่ใช้ (คิดว่าการทำงานของระบบไฟล์หรือนาฬิกาใน Java) ดังนั้น DI / IoC จะสร้างความซับซ้อนที่ไม่จำเป็นในการแก้ปัญหา

ที่จริงแล้วมันค่อนข้างง่ายที่จะเขียนโค้ดที่สะอาดและมีขนาดกะทัดรัดด้วย DI (ฉันสงสัยว่ามันจะเป็นแบบpythonic หรือเปล่าแต่อย่างไรก็ตาม :)) ตัวอย่างเช่นฉันเขียนรหัสด้วยวิธีนี้:

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!

ใช่สิ่งนี้สามารถดูได้ในรูปแบบง่ายๆของฟังก์ชั่นการกำหนดพารามิเตอร์ / คลาส แต่ทำงานได้ ดังนั้นบางทีแบตเตอรี่ที่รวมของ Python ก็เพียงพอแล้วเช่นกัน

ป.ล. ผมได้โพสต์ยังเป็นตัวอย่างที่มีขนาดใหญ่ของวิธีการที่ไร้เดียงสานี้ในแบบไดนามิกประเมินตรรกะบูลีนที่เรียบง่ายในหลาม

IoC / DI เป็นแนวคิดการออกแบบ แต่น่าเสียดายที่มันมักจะนำมาเป็นแนวคิดที่ใช้กับบางภาษา (หรือระบบการพิมพ์) ฉันชอบที่จะเห็นภาชนะฉีดขึ้นต่อเนื่องเป็นที่นิยมมากใน Python มีฤดูใบไม้ผลิ แต่นั่นเป็นโครงสร้างที่ยอดเยี่ยมและดูเหมือนจะเป็นพอร์ตโดยตรงของแนวคิดของ Java โดยไม่คำนึงถึง "The Python Way" มากนัก

ป.ร. ให้คำอธิบายประกอบในหลาม 3 ผมตัดสินใจที่จะมีรอยแตกที่เต็มรูปแบบที่โดดเด่น แต่ง่ายภาชนะฉีดพึ่งพา: https://github.com/zsims/dic มันขึ้นอยู่กับแนวคิดบางอย่างจาก. NET container injection (ซึ่ง IMO นั้นยอดเยี่ยมถ้าคุณเคยเล่นในพื้นที่นั้น) แต่กลายพันธุ์ด้วยแนวคิด Python

ฉันคิดว่าเนื่องจากลักษณะแบบไดนามิกของคนงูใหญ่มักไม่เห็นความต้องการกรอบการทำงานแบบไดนามิกอื่น เมื่อคลาสสืบทอดจาก 'object' สไตล์ใหม่คุณสามารถสร้างตัวแปรใหม่แบบไดนามิก ( https://wiki.python.org/moin/NewClassVsClassicClass )

ie ในหลามธรรมดา:

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

อย่างไรก็ตามดูที่https://github.com/noodleflake/pyiocนี่อาจเป็นสิ่งที่คุณกำลังมองหา

เช่นใน pyioc

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": "การใช้งาน Python ของ DI / IoC นั้นมีน้ำหนักเบาจนหายไปอย่างสมบูรณ์"

หากต้องการสำรองข้อความนี้ลองดูตัวอย่างที่มีชื่อเสียงของ Martin Fowler ซึ่งย้ายจาก Java ไปเป็น Python: Python: Design_Patterns: Inversion_of_Control

ดังที่คุณเห็นจากลิงก์ด้านบน "คอนเทนเนอร์" ใน Python สามารถเขียนได้ในรหัส 8 บรรทัด:

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

2cents ของฉันคือว่าในแอปพลิเคชั่น Python ส่วนใหญ่คุณไม่จำเป็นต้องใช้และแม้ว่าคุณจะต้องการโอกาสก็คือผู้เกลียดชัง Java จำนวนมาก (และนักเล่นไวโอลินไร้ความสามารถที่เชื่อว่าเป็นนักพัฒนาซอฟต์แวร์) พิจารณาว่าเป็นสิ่งที่ไม่ดี .

ระบบ IoC นั้นมีประโยชน์จริง ๆ เมื่อคุณมีเครือข่ายที่ซับซ้อนของวัตถุซึ่งแต่ละวัตถุอาจเป็นที่พึ่งของอีกหลายคนและในทางกลับกันมันก็ขึ้นอยู่กับวัตถุอื่น ในกรณีเช่นนี้คุณจะต้องกำหนดวัตถุทั้งหมดเหล่านี้เพียงครั้งเดียวและมีกลไกที่จะรวมวัตถุเหล่านี้เข้าด้วยกันโดยอัตโนมัติ หากคุณมีการกำหนดค่าที่จะถูกกำหนดอย่างง่ายๆโดยผู้ใช้แอปพลิเคชัน / ผู้ดูแลระบบนั่นเป็นเหตุผลเพิ่มเติมที่ต้องการระบบ IoC ที่สามารถอ่านส่วนประกอบของมันจากไฟล์ XML อย่างง่าย (ซึ่งจะเป็นการกำหนดค่า)

แอพพลิเคชั่น Python ทั่วไปนั้นง่ายกว่ามากเพียงแค่สคริปต์โดยไม่ต้องมีสถาปัตยกรรมที่ซับซ้อน โดยส่วนตัวฉันรู้ว่า IoC จริง ๆ แล้วคืออะไร (ตรงกันข้ามกับผู้ที่เขียนคำตอบบางอย่างที่นี่) และฉันไม่เคยรู้สึกว่าจำเป็นต้องใช้ในประสบการณ์ Python ที่ จำกัด ของฉัน (เช่นฉันไม่ได้ใช้สปริงทุกที่ไม่ใช่ข้อดี มันไม่ได้แสดงให้เห็นถึงค่าใช้จ่ายในการพัฒนา)

ที่กล่าวว่ามีสถานการณ์ Python ที่แนวทาง IoC มีประโยชน์จริง ๆ และที่จริงฉันอ่านที่ Django ใช้มัน

เหตุผลเดียวกันข้างต้นสามารถนำไปใช้กับการเขียนโปรแกรม Aspect Oriented ในโลก Java ด้วยความแตกต่างที่จำนวนกรณีที่ AOP คุ้มค่าจริง ๆ มี จำกัด มากขึ้น

การติดตั้ง pytest ทั้งหมดขึ้นอยู่กับ DI ( แหล่งที่มา )

ฉันเห็นด้วยกับ @Jorg ในจุดที่ DI / IoC เป็นไปได้ง่ายขึ้นและสวยงามยิ่งขึ้นใน Python สิ่งที่ขาดหายไปคือเฟรมเวิร์กที่สนับสนุน แต่มีข้อยกเว้นเล็กน้อย วิธีชี้ตัวอย่างสองสามอย่างที่อยู่ในใจของฉัน:

• ความคิดเห็น Django ช่วยให้คุณสามารถโยงคลาสความคิดเห็นของคุณเองด้วยตรรกะและรูปแบบที่กำหนดเองของคุณ [ข้อมูลเพิ่มเติม]

• Django ให้คุณใช้วัตถุโปรไฟล์แบบกำหนดเองเพื่อแนบกับโมเดลผู้ใช้ของคุณ นี่ไม่ใช่ IoC ที่สมบูรณ์ แต่เป็นวิธีการที่ดี โดยส่วนตัวแล้วฉันต้องการแทนที่โมเดลหลุมของผู้ใช้ตามกรอบความคิดเห็น [ข้อมูลเพิ่มเติม]

ในความคิดของฉันสิ่งต่าง ๆ เช่นการฉีดพึ่งพาเป็นอาการของกรอบแข็งและซับซ้อนเกินไป เมื่อเนื้อความหลักของรหัสกลายเป็นเรื่องน้ำหนักเกินกว่าที่จะเปลี่ยนได้อย่างง่ายดายคุณจะพบว่าตัวเองต้องเลือกชิ้นส่วนเล็ก ๆ ของมันกำหนดส่วนต่อประสานสำหรับพวกมันแล้วอนุญาตให้คนเปลี่ยนพฤติกรรมผ่านวัตถุที่เสียบเข้ากับส่วนต่อประสานเหล่านั้น ทุกอย่างดีและดี แต่ควรหลีกเลี่ยงความซับซ้อนแบบนั้นตั้งแต่แรก

นอกจากนี้ยังเป็นอาการของภาษาที่พิมพ์แบบคงที่ เมื่อเครื่องมือเดียวที่คุณต้องแสดงให้เห็นถึงนามธรรมคือสิ่งที่สืบทอดนั่นคือสิ่งที่คุณใช้ทุกที่ ต้องบอกว่า C ++ นั้นค่อนข้างคล้ายกัน แต่ไม่เคยดึงดูดความสนใจกับผู้สร้างและอินเทอร์เฟซทุกที่ที่นักพัฒนา Java ทำ มันง่ายเกินกว่าที่จะอุดมสมบูรณ์ด้วยความฝันที่จะมีความยืดหยุ่นและขยายออกได้ด้วยค่าใช้จ่ายในการเขียนรหัสทั่วไปที่มากเกินไปซึ่งมีประโยชน์น้อยมาก ฉันคิดว่ามันเป็นวัฒนธรรม

โดยทั่วไปแล้วฉันคิดว่าคน Python คุ้นเคยกับการเลือกเครื่องมือที่เหมาะสมสำหรับงานซึ่งเป็นสิ่งที่สอดคล้องกันและเรียบง่ายมากกว่า One True Tool (ด้วย A Thousand Possible Plugins) ที่สามารถทำสิ่งใดก็ได้ . ยังคงมีชิ้นส่วนที่ใช้แทนกันได้ตามความจำเป็น แต่ไม่จำเป็นต้องมีพิธีการใหญ่ในการกำหนดอินเทอร์เฟซคงที่เนื่องจากความยืดหยุ่นของการพิมพ์เป็ดและความเรียบง่ายของภาษา

ไม่เหมือนธรรมชาติที่แข็งแกร่งใน Java พฤติกรรมการพิมพ์เป็ดของงูใหญ่ทำให้ง่ายต่อการส่งผ่านวัตถุไปรอบ ๆ

นักพัฒนา Java กำลังมุ่งเน้นไปที่การสร้างโครงสร้างคลาสและความสัมพันธ์ระหว่างวัตถุในขณะที่ทำให้สิ่งต่าง ๆ มีความยืดหยุ่น IoC มีความสำคัญอย่างยิ่งต่อการบรรลุเป้าหมายนี้

นักพัฒนา Python มุ่งเน้นไปที่การทำให้งานสำเร็จ พวกเขาเพียงวางสายชั้นเมื่อพวกเขาต้องการ พวกเขาไม่ต้องกังวลเกี่ยวกับประเภทของชั้นเรียน ตราบใดที่มันสามารถต้มตุ๋นมันเป็นเป็ด! ลักษณะนี้ทำให้ไม่มีที่ว่างสำหรับ IoC