নির্ভরতা ইনজেকশন বোঝা


109

আমি নির্ভরতা ইনজেকশন (ডিআই) সম্পর্কে পড়ছি । আমার কাছে এটি করা খুব জটিল জিনিস, কারণ আমি যখন এটি পড়ছিলাম তখন এটি নিয়ন্ত্রণের বিপরীতটি (আইওসি) এরও উল্লেখ করছিল এবং এরকম আমি অনুভব করেছি যে আমি কোনও যাত্রায় যাব।

এটি আমার বোধগম্যতা: ক্লাসে এমন একটি মডেল তৈরি করার পরিবর্তে যা এটি গ্রাস করে, আপনি মডেলটি (ইতিমধ্যে আকর্ষণীয় বৈশিষ্ট্যে পূর্ণ) পাস করে (যেখানে একটি নতুন ক্লাসে এটি প্যারামিটার হিসাবে গ্রহণ করতে পারে) নির্মাণকারী)।

আমার কাছে এটি কেবল একটি যুক্তি পার করছে। আমি নিশ্চয়ই বুঝতে পারছি বিন্দুটি? বড় প্রকল্পগুলির সাথে এটি আরও সুস্পষ্ট হয়ে উঠতে পারে?

আমার বোঝাটি নন-ডিআই (সিউডো কোড ব্যবহার করে):

public void Start()
{
    MyClass class = new MyClass();
}

...

public MyClass()
{
    this.MyInterface = new MyInterface(); 
}

এবং ডিআই হবে

public void Start()
{
    MyInterface myInterface = new MyInterface();
    MyClass class = new MyClass(myInterface);
}

...

public MyClass(MyInterface myInterface)
{
    this.MyInterface = myInterface; 
}

কেউ নিশ্চিত হতে পারে যে আমি এখানে ঝামেলা করছি light


5
মাইআইন্টারফেস এবং মাইক্লাসের ৫ টি থাকার চেষ্টা করুন এবং একাধিক শ্রেণি নির্ভরতা শৃঙ্খলা গঠন করে। সবকিছু সেট আপ করার জন্য এটি বাটে ব্যথা হয়ে ওঠে।
ইউফোরিক

159
" আমার কাছে, এটি কেবল একটি তর্ক বিতর্ক করছে I আমি অবশ্যই এই বিষয়টি ভুল বুঝেছি? " নাহ। তুমি বুঝতে পেরেছ. এটি "নির্ভরতা ইনজেকশন"। এখন দেখুন কী সহজ পাগলের জন্য আপনি কী পাগল হয়ে উঠতে পারেন, মজাদার!
এরিক লিপার্ট

8
মিঃ লিপার্টের মন্তব্যে আমি পর্যাপ্ত পরিমাণে উঠতে পারি না। আমিও যে কোনওভাবে প্রাকৃতিকভাবে যা করছি তার জন্য এটি বিভ্রান্তিকর জার্গন বলে মনে হয়েছিল।
অ্যালেক্স হামফ্রে

16
@ এরিকলিপার্ট: সঠিক হলেও, আমি মনে করি এটি কিছুটা হ্রাসযোগ্য। প্যারামিটার-হিসাবে-ডিআই আপনার গড় আবশ্যক / ওও প্রোগ্রামারটির জন্য তাত্ক্ষণিক সরল ধারণা নয়, যিনি প্রায় ডেটা পাস করার অভ্যস্ত। ডিআই এখানে আপনাকে চারপাশের আচরণটি ছাড়িয়ে দিচ্ছে , যার জন্য একটি মধ্যম প্রোগ্রামারের চেয়ে আরও নমনীয় বিশ্বদর্শন প্রয়োজন requires
ফোশি

14
@ ফোশি: আপনি একটি ভাল বক্তব্য রেখেছেন, তবে কেন আমি সন্দেহ করি যে "নির্ভরতা ইনজেকশন" প্রথম দিকে একটি ভাল ধারণা। আমি যদি এমন কোনও ক্লাস লিখি যা অন্য শ্রেণীর আচরণের উপর তার সঠিকতা এবং পারফরম্যান্সের জন্য নির্ভর করে তবে আমি শেষ কাজটি করতে চাই তা হ'ল শ্রেণীর ব্যবহারকারীকে নির্ভরতা সঠিকভাবে নির্মান এবং কনফিগার করার জন্য দায়বদ্ধ করে তোলা! এটাই আমার কাজ। প্রতিবার আপনি যখন কোনও গ্রাহককে নির্ভরতা ইনজেক্ট করতে দেন আপনি এমন একটি পয়েন্ট তৈরি করেন যেখানে ভোক্তা এটি ভুল করতে পারে।
এরিক লিপার্ট

উত্তর:


106

আচ্ছা হ্যাঁ, আপনি আপনার নির্ভরতা ইনজেক্ট করুন, হয় কোনও নির্মাণকারীর মাধ্যমে বা বৈশিষ্ট্যগুলির মাধ্যমে।
এর অন্যতম কারণ হ'ল মাইক্র্লাসকে মাইআইন্টারফেসের কোনও উদাহরণ কীভাবে তৈরি করা দরকার তার বিশদটি দিয়ে withুকিয়ে দেওয়া নয়। মাইআইন্টারফেস এমন কিছু হতে পারে যা নিজের দ্বারা নির্ভরতার পুরো তালিকা রয়েছে এবং মাইক্লাসের কোডটি খুব দ্রুতই খারাপ হয়ে উঠবে যদি আপনি মাইক্লাসের ভিতরে থাকা সমস্ত মাইন্টারফেস নির্ভরতাগুলি তাত্ক্ষণিকভাবে চালিত করেন।

আর একটি কারণ পরীক্ষা করার জন্য।
যদি আপনার কোনও ফাইল রিডার ইন্টারফেসের উপর নির্ভরতা থাকে এবং আপনি কোনও কনস্ট্রাক্টারের মাধ্যমে এই নির্ভরতা ইনজেকশন করেন, বলুন, কনজিউমারক্লাস, এর অর্থ এই যে পরীক্ষার সময় আপনি প্রয়োজনীয়তা এড়িয়ে ফাইল কনডম ক্লাসে মেমরি প্রয়োগ করতে পারবেন পরীক্ষার সময় আমি / ও করি


13
এটি দুর্দান্ত, ভালভাবে ব্যাখ্যা করা হয়েছে। দয়া করে একটি কাল্পনিক +1 গ্রহণ করুন যেহেতু আমার প্রতিনিধি এটি এখনও অনুমতি দেয় না!
MyDaftQuestions

11
জটিল নির্মাণ পরিস্থিতি কারখানার প্যাটার্নটি ব্যবহারের জন্য ভাল প্রার্থী। এইভাবে, কারখানাটি অবজেক্টটি নির্মাণের দায়িত্ব নেয়, যাতে ক্লাস নিজেই না হয় এবং আপনি একক দায়িত্বের নীতিতে লেগে থাকেন।
ম্যাট গিবসন

1
@ ম্যাটগিবসন ভাল পয়েন্ট
স্টিফান বিলিয়েট

2
পরীক্ষার জন্য +1, ভাল কাঠামোগত ডিআই আপনার পরীক্ষার শ্রেণীর মধ্যে থাকা ইউনিট পরীক্ষার গতি পরীক্ষা করা এবং তৈরি করা উভয়কেই সহায়তা করবে।
উমুর কনটাসে

52

ডিআই কীভাবে প্রয়োগ করা যায় তা ব্যবহৃত ভাষার উপর নির্ভর করে।

এখানে একটি সাধারণ নন-ডিআই উদাহরণ রয়েছে:

class Foo {
    private Bar bar;
    private Qux qux;

    public Foo() {
        bar = new Bar();
        qux = new Qux();
    }
}

এটি স্তন্যপান করে, উদাহরণস্বরূপ যখন কোনও পরীক্ষার জন্য আমি একটি মক অবজেক্টটি ব্যবহার করতে চাই bar। সুতরাং আমরা এটিকে আরও নমনীয় করে তুলতে পারি এবং দৃষ্টান্তগুলি নির্মাণকারীর মধ্য দিয়ে যেতে পারি:

class Foo {
    private Bar bar;
    private Qux qux;

    public Foo(Bar bar, Qux qux) {
        this.bar = bar;
        this.qux = qux;
    }
}

// in production:
new Foo(new Bar(), new Qux());
// in test:
new Foo(new BarMock(), new Qux());

এটি ইতিমধ্যে নির্ভরতা ইনজেকশনটির সর্বাধিক সাধারণ রূপ। তবে এটি এখনও ব্যর্থ হয় কারণ সবকিছু ম্যানুয়ালি করতে হবে (এছাড়াও, কারণ কলার আমাদের অভ্যন্তরীণ বস্তুগুলির একটি রেফারেন্স ধরে রাখতে পারে এবং আমাদের রাজ্যটিকে অকার্যকর করতে পারে)।

আমরা কারখানাগুলি ব্যবহার করে আরও বিমূর্ততা প্রবর্তন করতে পারি:

  • একটি বিকল্প Fooএকটি বিমূর্ত কারখানা দ্বারা উত্পাদিত হয়

    interface FooFactory {
        public Foo makeFoo();
    }
    
    class ProductionFooFactory implements FooFactory {
        public Foo makeFoo() { return new Foo(new Bar(), new Baz()) }
    }
    
    class TestFooFactory implements FooFactory {
        public Foo makeFoo() { return new Foo(new BarMock(), new Baz()) }
    }
    
    FooFactory fac = ...; // depends on test or production
    Foo foo = fac.makeFoo();
  • অন্য বিকল্পটি হল কারখানাটি নির্মাণকারীর হাতে দেওয়া:

    interface DependencyManager {
        public Bar makeBar();
        public Qux makeQux();
    }
    class ProductionDM implements DependencyManager {
        public Bar makeBar() { return new Bar() }
        public Qux makeQux() { return new Qux() }
    }
    class TestDM implements DependencyManager {
        public Bar makeBar() { return new BarMock() }
        public Qux makeQux() { return new Qux() }
    }
    
    class Foo {
        private Bar bar;
        private Qux qux;
    
        public Foo(DependencyManager dm) {
            bar = dm.makeBar();
            qux = dm.makeQux();
        }
    }

এটির সাথে বাকী সমস্যাগুলি DependencyManagerহ'ল আমাদের প্রতিটি কনফিগারেশনের জন্য একটি নতুন উপক্লাস লিখতে হবে এবং যে নির্ভরতাগুলি পরিচালনা করা যায় তা মোটামুটি সীমাবদ্ধ (প্রতিটি নতুন নির্ভরতার ইন্টারফেসে একটি নতুন পদ্ধতি প্রয়োজন)।

প্রতিবিম্ব এবং গতিশীল বর্গ লোডিংয়ের মতো বৈশিষ্ট্যগুলি সহ আমরা এটিকে অবরুদ্ধ করতে পারি। তবে এটি ব্যবহৃত ভাষার উপর নির্ভর করে। পার্লে, ক্লাসগুলি তাদের নামে উল্লেখ করা যেতে পারে, এবং আমি ঠিক করতে পারতাম could

package Foo {
    use signatures;

    sub new($class, $dm) {
        return bless {
            bar => $dm->{bar}->new,
            qux => $dm->{qux}->new,
        } => $class;
    }
}

my $prod = { bar => 'My::Bar', qux => 'My::Qux' };
my $test = { bar => 'BarMock', qux => 'QuxMock' };
$test->{bar} = 'OtherBarMock';  # change conf at runtime

my $foo = Foo->new(rand > 0.5 ? $prod : $test);

জাভা এর মতো ভাষায়, আমি নির্ভরতা পরিচালককে এর মতো আচরণ করতে পারি Map<Class, Object>:

Bar bar = dm.make(Bar.class);

কোন প্রকৃত শ্রেণীর Bar.classকাছে সমাধানটি রানটাইম সময়ে কনফিগার করা যায়, উদাহরণস্বরূপ Map<Class, Class>যা বাস্তবায়নের ক্ষেত্রে কোন মানচিত্রের ইন্টারফেসগুলি বজায় রেখে ।

Map<Class, Class> dependencies = ...;

public <T> T make(Class<T> c) throws ... {
    // plus a lot more error checking...
    return dependencies.get(c).newInstance();
}

নির্মাণকারীর লেখার সাথে জড়িত এখনও একটি ম্যানুয়াল উপাদান রয়েছে। তবে আমরা কনস্ট্রাক্টরটিকে সম্পূর্ণ অপ্রয়োজনীয় করতে পারি, যেমন টীকা দিয়ে ডিআই চালিয়ে:

class Foo {
    @Inject(Bar.class)
    private Bar bar;

    @Inject(Qux.class)
    private Qux qux;

    ...
}

dm.make(Foo.class);  // takes care of initializing "bar" and "qux"

এখানে একটি ক্ষুদ্র (এবং খুব সীমাবদ্ধ) ডিআই ফ্রেমওয়ার্কের একটি বাস্তবায়ন উদাহরণ রয়েছে: http://ideone.com/b2ubuF , যদিও এই বাস্তবায়ন অপরিবর্তনীয় বস্তুর জন্য সম্পূর্ণ অপ্রয়োজনীয় (এই নিষ্পাপ বাস্তবায়ন কনস্ট্রাক্টরের কোনও পরামিতি নিতে পারে না)।


7
এটি দুর্দান্ত উদাহরণ সহকারে দুর্দান্ত, যদিও এটি হজম করার জন্য এটি পড়তে আমার কয়েকবার সময় লাগবে, তবে এত সময় দেওয়ার জন্য ধন্যবাদ।
MyDaftQuestions

33

48

স্ট্যাক ওভারফ্লোতে থাকা আমাদের বন্ধুদের কাছে এটির একটি দুর্দান্ত উত্তর রয়েছে । আমার প্রিয় উক্তি সহ দ্বিতীয় উত্তর is

"নির্ভরতা ইনজেকশন" একটি 5-শতাংশ ধারণার জন্য 25 ডলার শব্দ। (...) নির্ভরতা ইনজেকশন মানে কোনও বস্তুকে এর উদাহরণ ভেরিয়েবল দেওয়া। (...)।

থেকে জেমস শোর এর ব্লগ । অবশ্যই, এর উপরে আরও জটিল সংস্করণ / নিদর্শনগুলি স্তরযুক্ত রয়েছে তবে মূলত কী চলছে তা বোঝার জন্য এটি যথেষ্ট। কোনও অবজেক্ট তার নিজস্ব ভেরিয়েবল তৈরি করার পরিবর্তে সেগুলি বাইরে থেকে পাস করা হয়।


10
আমি এটি পড়েছিলাম ... এবং এখন অবধি এটি কোনও অর্থবহ হয়নি ... এখন, এটি বোঝা যায়। নির্ভরতা আসলে বুঝতে এটি এত বড় একটি ধারণা নয় (এটি যত শক্তিশালীই হোক না কেন) তবে এর সাথে একটি বড় নাম এবং এর সাথে প্রচুর ইন্টারনেট শব্দের যুক্ত রয়েছে!
MyDaftQuestions

18

ধরা যাক আপনি আপনার বসার ঘরে অভ্যন্তর নকশা করছেন: আপনি আপনার সিলিংয়ে একটি অভিনব ঝাড়বাতি ইনস্টল করেন এবং একটি উত্কৃষ্ট মেলানো ফ্লোর ল্যাম্পে প্লাগ করুন। এক বছর পরে আপনার সুন্দরী স্ত্রী সিদ্ধান্ত নেন যে তিনি ঘরটি কিছুটা কম আনুষ্ঠানিক চাই। কোন আলোর রাজধানী পরিবর্তন করা সহজ হতে চলেছে?

ডিআই এর পিছনে ধারণাটি হ'ল সর্বত্র "প্লাগ-ইন" ​​পদ্ধতির ব্যবহার আপনি যদি কোনও ড্রইওয়াল না রেখে এবং সমস্ত বৈদ্যুতিক তারের সংস্পর্শ ছাড়াই একটি সাধারণ ঝোপঝাড়ে বাস করেন তবে এটি কোনও বড় চুক্তির মতো বলে মনে হচ্ছে না। (আপনি একজন হস্তশিল্পী - আপনি যে কোনও কিছু পরিবর্তন করতে পারেন!) এবং একইভাবে, একটি ছোট এবং সাধারণ অ্যাপ্লিকেশনটিতে, ডিআই এটির চেয়ে বেশি জটিলতা যুক্ত করতে পারে।

তবে একটি বৃহত এবং জটিল প্রয়োগের জন্য, ডিআই দীর্ঘমেয়াদী রক্ষণাবেক্ষণের জন্য অপরিহার্য । এটি আপনাকে আপনার কোড (উদাহরণস্বরূপ, ডাটাবেস ব্যাকএন্ড) থেকে পুরো মডিউলগুলিকে "আনপ্লাগ" করতে এবং একই জিনিস সম্পাদন করে এমন একটি পৃথক মডিউলগুলির সাথে বিনিময় করতে সহায়তা করে যা সম্পূর্ণ ভিন্ন উপায়ে করে (উদাহরণস্বরূপ একটি ক্লাউড স্টোরেজ সিস্টেম)।

বিটিডাব্লু, ডিআই-এর আলোচনা মার্ক সিমেন দ্বারা .NET- র নির্ভরতা ইনজেকশনের প্রস্তাব ছাড়াই অসম্পূর্ণ হবে । যদি আপনি .NET এর সাথে পরিচিত হন এবং আপনি কখনও বৃহত্তর স্কেল ডাব্লু বিকাশের সাথে জড়িত থাকতে চান তবে এটি একটি আবশ্যক পঠন। তিনি ধারণাটি আমার চেয়ে অনেক ভাল ব্যাখ্যা করেছেন।

আমি আপনাকে ডিআই এর একটি সর্বশেষ অত্যাবশ্যকীয় বৈশিষ্ট্য রেখে যাই যা আপনার কোড উদাহরণটিকে উপেক্ষা করে। ডিআই আপনাকে নমনীয়তার বিশাল সম্ভাবনাটি ব্যবহারের অনুমতি দেয় যা " প্রোগ্রাম ইন্টারফেসে প্রোগ্রাম " প্রবন্ধে আবদ্ধ থাকে । আপনার উদাহরণটি সামান্য পরিবর্তন করতে:

public void Main()
{
    ILightFixture fixture = new ClassyChandelier();
    MyRoom room = new MyRoom (fixture);
}
...
public MyRoom(ILightFixture fixture)
{
    this.MyLightFixture = fixture ; 
}

তবে এখনই, কারণ MyRoomILightFixture ইন্টারফেসের জন্য ডিজাইন করা হয়েছে , আমি সহজেই পরের বছর যেতে পারি এবং মেইন ফাংশনে একটি লাইন পরিবর্তন করতে পারি ("ইনজেকশন" একটি "আলাদা" নির্ভরতা "), এবং আমি তাত্ক্ষণিকভাবে মাইরুমে নতুন কার্যকারিতা পাই (ছাড়াই) মাইরামকে পুনর্নির্মাণ করুন বা পুনরায় চালনা করুন, যদি এটি আলাদা লাইব্রেরিতে ঘটে থাকে This অবশ্যই এটি ধরে নেওয়া হয় যে আপনার সমস্ত আইলাইটফিশার বাস্তবায়ন লিসকভ সাবস্টিটিউশনকে মাথায় রেখে তৈরি করা হয়েছে)। কেবলমাত্র একটি সাধারণ পরিবর্তন সহ:

public void Main()
{
    ILightFixture fixture = new MuchLessFormalLightFixture();
    MyRoom room = new MyRoom (fixture);
}

প্লাস, আমি এখন ইউনিট পরীক্ষা করতে পারেন MyRoom(যদি আপনি আছে ইউনিট টেস্টিং, ঠিক আছে?) এবং একটি "উপহাস" আলো চোকান, যা আমাকে পরীক্ষা করতে পারবেন ব্যবহার MyRoomসম্পূর্ণভাবে স্বাধীনClassyChandelier.

অবশ্যই আরও অনেক সুবিধা রয়েছে তবে এগুলি আমার কাছে এই ধারণাটি বিক্রি হয়েছিল।


আমি ধন্যবাদ বলতে চাই, এটি আমার পক্ষে সহায়ক ছিল, তবে তারা আপনাকে এটি করতে চান না, বরং উন্নতির পরামর্শ দেওয়ার জন্য মন্তব্যগুলি ব্যবহার করুন, সুতরাং, যদি আপনি এটির মতো অনুভব করেন তবে আপনি উল্লিখিত অন্যান্য সুবিধাগুলির মধ্যে একটি যোগ করতে পারেন। তবে অন্যথায়, ধন্যবাদ, এটি আমার পক্ষে সহায়ক ছিল।
স্টিভ

2
আপনি যে বইটি উল্লেখ করেছেন সে সম্পর্কেও আমি আগ্রহী, তবে আমি উদ্বেগজনক বলে মনে করি যে এই বিষয়ে একটি 584 পৃষ্ঠার বই রয়েছে।
স্টিভ

4

নির্ভরতা ইনজেকশনটি কেবলমাত্র একটি প্যারামিটারটি পার করছে, তবে এটি এখনও কিছু সমস্যার দিকে নিয়ে যায় এবং নামটি উদ্দেশ্য করে কেন কোনও বস্তু তৈরির মধ্যে একটি পার্থক্য তৈরি করার মধ্যে পার্থক্য গুরুত্বপূর্ণ তা নিয়ে কিছুটা কেন্দ্রীভূত করা উচিত।

এটি গুরুত্বপূর্ণ কারণ (বেশ স্পষ্টতই) যে কোনও সময় অবজেক্ট A কল টাইপ করে বি, এ কীভাবে কাজ করে তার উপর নির্ভরশীল। যার অর্থ হ'ল এ যদি নির্দিষ্টভাবে কোন কংক্রিট ধরণের বি ব্যবহার করবে তা সিদ্ধান্ত নেয়, তবে এটিকে কোনও পরিবর্তন না করে বাইরের শ্রেণি দ্বারা কীভাবে এ ব্যবহার করা যেতে পারে তার মধ্যে অনেক নমনীয়তা নষ্ট হয়ে গেছে।

আমি এটি উল্লেখ করেছি কারণ আপনি নির্ভরতা ইনজেকশনের "পয়েন্টটি মিসিং" সম্পর্কে কথা বলছেন এবং লোকেরা কেন এটি করতে পছন্দ করে এটি এটির অনেক বিষয়। এটি কেবলমাত্র প্যারামিটারটি পাস করার অর্থ হতে পারে তবে আপনি এটি করেন কিনা তা গুরুত্বপূর্ণ be

এছাড়াও, ডিআই বাস্তবায়নে কিছু অসুবিধা বড় প্রকল্পগুলিতে আরও ভাল দেখায়। আপনি কোন কংক্রিট শ্রেণীর উপরের দিকে সমস্ত দিক ব্যবহার করবেন তার প্রকৃত সিদ্ধান্তটি সাধারণত সরিয়ে নিয়ে যাবেন, যাতে আপনার শুরুর পদ্ধতিটি দেখতে দেখতে দেখতে পারে:

public void Start()
{
    MySubSubInterfaceA mySubSubInterfaceA = new mySubSubInterfaceA();
    MySubSubInterfaceB mySubSubInterfaceB = new mySubSubInterfaceB();     
    MySubInterface mySubInterface = new MySubInterface(mySubSubInterfaceA,mySubSubInterfaceB);
    MyInterface myInterface = new MyInterface(MySubInterface);
    MyClass class = new MyClass(myInterface);
}

তবে এই জাতীয় riveting কোডের আরও 400 লাইন রয়েছে। আপনি যদি ধারণা করেন যে সময়ের সাথে সাথে ডিআই কন্টেনারগুলির আবেদন আরও স্পষ্ট হয়।

এছাড়াও, এমন কোনও শ্রেণীর কল্পনা করুন যা বলে, IDisposable কার্যকর করে। এটি যে ক্লাসগুলি ব্যবহার করে সেগুলি যদি সেগুলি নিজের তৈরি করার পরিবর্তে ইঞ্জেকশনের মাধ্যমে পায় তবে তারা কীভাবে জানতে পারবে কখন ডিসপোজ () কল করতে হবে? (কোন ডিআই কন্টেইনার অন্য একটি বিষয় যা নিয়ে কাজ করে))

সুতরাং, নিশ্চিত, নির্ভরতা ইনজেকশনটি কেবল একটি প্যারামিটারটি পার করছে, তবে সত্যিকার অর্থে যখন লোকেরা নির্ভর করে ইনজেকশন বলতে তারা বোঝায় যে "আপনার বস্তুর কাছে একটি প্যারামিটার বনাম বনাম আপনার বস্তুটি নিজেই কিছুটা ইনস্ট্যান্টিয়েট করার বিকল্প", এবং এর অসুবিধাগুলির সমস্ত সুবিধা নিয়ে কাজ করে dealing সম্ভবত একটি ডিআই কনটেইনার সাহায্যে এই জাতীয় একটি পদ্ধতি।


এটাই প্রচুর সাবস এবং ইন্টারফেস! আপনি কি ক্লাসের পরিবর্তে একটি ইন্টারফেস নতুন করে বোঝাতে চান যা ইন্টারফেসটি প্রয়োগ করে? ভুল মনে হচ্ছে।
জেবিআরউইলকিনসন

@ জবিআরওয়িলকিনসন আমার অর্থ এমন একটি শ্রেণি যা ইন্টারফেস প্রয়োগ করে। আমার এই পরিষ্কার করা উচিত। যাইহোক, মুল বক্তব্যটি হ'ল একটি বড় অ্যাপ্লিকেশনটির সাথে নির্ভরশীলতাগুলির সাথে ক্লাসগুলি থাকে যার পরিবর্তে নির্ভরতা থাকে যা ঘুরে ফিরে নির্ভরতা হয় ... মূল পদ্ধতিতে ম্যানুয়ালি এগুলি সেট করা হ'ল প্রচুর কনস্ট্রাক্টর ইনজেকশন দেওয়ার ফলাফল।
PSr

4

ক্লাস পর্যায়ে, এটি সহজ।

'নির্ভরতা ইনজেকশন' সহজেই "আমি কীভাবে আমার সহযোগীদের খুঁজে পাব" এই প্রশ্নের উত্তর দেয় "তারা আপনার দিকে ধাক্কা খায় - আপনাকে যেতে হবে এবং সেগুলি নিজেই নিতে হবে না"। (এটি একইরকম - তবে একই নয় - 'ইনভার্শন অফ কন্ট্রোল' যেখানে "আমি কীভাবে আমার ইনপুটগুলির উপর আমার ক্রিয়াকলাপকে অর্ডার করব?") প্রশ্নের একইরকম উত্তর রয়েছে)।

শুধুমাত্র উপকার আপনার সহযোগীদের থাকার তোমার দিকে ধাক্কা যে একটি বস্তু গ্রাফ যা মামলা তার বর্তমান প্রয়োজন রচনা করতে আপনার বর্গ ব্যবহার করতে ক্লায়েন্ট কোড সক্ষম করে ... তুমি ইচ্ছামত না গোপনে সিদ্ধান্ত দ্বারা আকৃতি এবং গ্রাফ পরিবর্তনশীলতা পূর্বনির্ধারিত আপনার সহযোগীদের কংক্রিটের ধরণ এবং জীবনচক্র।

(অন্যান্য সমস্ত সুবিধাগুলি, পরীক্ষারযোগ্যতা, আলগা কাপলিং ইত্যাদির অনেকাংশে ইন্টারফেসের ব্যবহার থেকে অনুসরণ করে এবং নির্ভরতা-ইনজেকশন-নেস থেকে এতটা নয়, যদিও ডিআই স্বাভাবিকভাবে ইন্টারফেসের ব্যবহারকে প্রচার করে না))

উল্লেখ্য যে, আপনি যদি আপনার নিজের সহযোগীদের শুরু করতে গিয়ে এড়াতে না, আপনার বর্গ আবশ্যক মূল্য অতএব (এই আধুনিক বিকল্প প্রায়ই উপেক্ষিত হয় প্রণালী দ্বারা তার সহযোগীদের একটি কন্সট্রাকটর, একটি সম্পত্তি, অথবা একটি পদ্ধতি-যুক্তি থেকে পেতে ... এটা আছে কোনও শ্রেণি'র সহযোগীদের তার 'রাজ্যের' অংশ হতে সর্বদা বোধগম্য নয়)।

এবং এটি একটি ভাল জিনিস।

আবেদন স্তরে ...

জিনিসগুলির প্রতি শ্রেণি দর্শনের জন্য এত বেশি। আসুন ধরা যাক আপনার কাছে অনেকগুলি ক্লাস রয়েছে যা "নিজের সহযোগীদের ইনস্ট্যান্ট করবেন না" নিয়মটি অনুসরণ করে এবং সেগুলি থেকে একটি আবেদন করতে চান। সবচেয়ে সহজ কাজটি হ'ল আপনার পুরানো কোডটি (যাঁর কনস্ট্রাক্টর, বৈশিষ্ট্য এবং পদ্ধতিগুলি চাওয়ার জন্য সত্যই কার্যকর সরঞ্জাম!) আপনি চান সেই অবজেক্টের গ্রাফটি রচনা করতে এবং এটিতে কিছু ইনপুট নিক্ষেপ করা। (হ্যাঁ, আপনার গ্রাফের objects অবজেক্টগুলির মধ্যে কিছু হ'ল তারা নিজেরাই বস্তু-কারখানা হবে, যা গ্রাফের অন্যান্য দীর্ঘজীবী অবজেক্টগুলির সহযোগী হিসাবে গৃহীত হয়েছে, পরিষেবার জন্য প্রস্তুত ... আপনি প্রতিটি বস্তুর প্রাক-নির্মাণ করতে পারবেন না! )।

... আপনার অ্যাপ্লিকেশনটির অবজেক্ট-গ্রাফকে 'নমনীয়ভাবে' কনফিগার করতে হবে ...

আপনার অন্যান্য (নন-কোড সম্পর্কিত) উদ্দেশ্যগুলির উপর নির্ভর করে আপনি শেষ ব্যবহারকারীকে এভাবে স্থাপন করা বস্তুর গ্রাফের উপর কিছুটা নিয়ন্ত্রণ দিতে চাইতে পারেন। এটি আপনাকে কোনও নাম বা মান জোড়া, একটি এক্সএমএল ফাইল, একটি কাস্টম ডিএসএল, একটি ঘোষিত গ্রাফ-বিবরণ ভাষা যেমন আপনার নিজস্ব ডিজাইনের একটি টেক্সট ফাইল হোক না কেন এটি এক ধরণের বা অন্য ধরণের কনফিগারেশন স্কিমের দিকে নিয়ে যায় ওয়াইএএমএল, জাভাস্ক্রিপ্টের মতো একটি আবশ্যকীয় স্ক্রিপ্টিং ভাষা বা হাতের কাজটির জন্য উপযুক্ত কিছু। আপনার ব্যবহারকারীদের প্রয়োজন মেটাতে এমনভাবে বৈধ অবজেক্ট গ্রাফটি রচনা করতে যা-ই লাগে না।

... একটি গুরুত্বপূর্ণ নকশা শক্তি হতে পারে।

এই ধরণের সবচেয়ে চরম পরিস্থিতিতে আপনি খুব সাধারণ পন্থা গ্রহণ করতে এবং শেষ ব্যবহারকারীদের তাদের পছন্দসই বস্তু-গ্রাফকে 'ওয়্যারিং আপ' করার জন্য একটি সাধারণ পদ্ধতি দিতে এবং এমনকি তাদের ইন্টারফেসের কংক্রিট উপলব্ধি প্রদানের অনুমতিও দিতে পারেন could রানটাইম! (আপনার ডকুমেন্টেশনগুলি একটি দৃষ্টিনন্দন রত্ন, আপনার ব্যবহারকারীরা খুব স্মার্ট, আপনার অ্যাপ্লিকেশনটির অবজেক্ট গ্রাফের কমপক্ষে মোটা রূপরেখার সাথে পরিচিত, তবে সংকলকটি সহজে ব্যবহারযোগ্য হবে না)। এই দৃশ্যটি তাত্ত্বিকভাবে কিছু 'এন্টারপ্রাইজ' পরিস্থিতিতে ঘটতে পারে।

সেক্ষেত্রে, আপনার কাছে সম্ভবত একটি ঘোষিত ভাষা রয়েছে যা আপনার ব্যবহারকারীদের যে কোনও প্রকারের প্রকাশ করতে দেয়, এই জাতীয় ধরণের অবজেক্ট গ্রাফের সংমিশ্রণ এবং ইন্টারফেসগুলির একটি প্যালেট যা পৌরাণিক শেষ-ব্যবহারকারী মিশ্রিত করতে পারে এবং মেলাতে পারে। আপনার ব্যবহারকারীদের উপর জ্ঞানীয় বোঝা হ্রাস করতে, আপনি একটি 'কনভেনশন বাই কনফিগারেশন' পদ্ধতির পছন্দ করেন, যাতে তাদের কেবল পুরো জিনিসটির সাথে কুস্তি করার পরিবর্তে আগ্রহের অবজেক্ট-গ্রাফ-টুকরোটিতে পদক্ষেপ এবং অতিরিক্ত যাত্রা করতে হবে।

বেচারা সোড!

যেহেতু আপনি নিজেরাই সব লেখার অভিনবতা করেন নি (তবে গুরুত্বের সাথে নিজের ভাষার জন্য একটি ওয়াইএএমএল বাইন্ডিং পরীক্ষা করে দেখুন), আপনি কোনও ধরনের ডিআই ফ্রেমওয়ার্ক ব্যবহার করছেন।

সেই কাঠামোর পরিপক্কতার উপর নির্ভর করে আপনার কাছে কন্সট্রাক্টর-ইনজেকশন ব্যবহার করার বিকল্প নাও থাকতে পারে, যখন তা বোধগম্য হয় (কোনও সহযোগী কোনও বস্তুর আজীবন পরিবর্তিত হয় না), ফলে আপনাকে সেটার ইঞ্জেকশন ব্যবহার করতে বাধ্য করা হয় (এমনকি যখন সহযোগীরা কোনও সামগ্রীর আজীবন পরিবর্তিত হয় না এবং এমনকি যখন কোনও ইন্টারফেসের সমস্ত কংক্রিট বাস্তবায়নের ক্ষেত্রে কোনও নির্দিষ্ট ধরণের সহযোগী থাকা আবশ্যক কোনও যৌক্তিক কারণ নাও রয়েছে )। যদি তা হয় তবে আপনার কোড-বেস জুড়ে অধ্যবসায়ের সাথে 'ব্যবহৃত ইন্টারফেস' থাকা সত্ত্বেও আপনি বর্তমানে দৃ strong়-সংযোগকারী জাহান্নামে রয়েছেন - হরর!

আশা করি যদিও আপনি একটি ডিআই ফ্রেমওয়ার্ক ব্যবহার করেছেন যা আপনাকে কনস্ট্রাক্টর ইনজেকশনের বিকল্প দেয় এবং আপনার ব্যবহারকারীরা আপনাকে প্রয়োজনীয় কিছু নির্দিষ্ট বিষয়গুলির বিষয়ে চিন্তা না করে এবং একটি ইউআইকে কাজের জন্য আরও উপযুক্ত করে দেওয়ার জন্য বেশি সময় ব্যয় না করার জন্য আপনাকে কেবল কিছুটা খারাপ বলে মনে করেন হাতে. (যদিও ন্যায়সঙ্গত হতে পারে, আপনি সম্ভবত কোনও উপায় চিন্তা করার চেষ্টা করেছিলেন, তবে জাভাইই আপনাকে হতাশ করেছিল এবং আপনাকে এই ভয়ঙ্কর হ্যাকটি অবলম্বন করতে হয়েছিল)।

Bootnote

আপনি কখনই গুগল গুইস ব্যবহার করছেন না, যা কোডারকে কোড সহ কোনও অবজেক্ট-গ্রাফ রচনা করার কাজটি দিয়ে কোডারকে সরবরাহ করার একটি উপায় দেয় । আহা!


0

অনেক লোক এখানে বলেছিল যে ডিআই হ'ল একটি উদাহরণের পরিবর্তনশীলগুলির সূচনা আউট-উত্সের জন্য একটি প্রক্রিয়া mechanism

সুস্পষ্ট এবং সাধারণ উদাহরণগুলির জন্য আপনার সত্যিকারের "নির্ভরতা ইনজেকশন" লাগবে না। আপনি প্রশ্নে উল্লিখিত হিসাবে আপনি এটি কনস্ট্রাক্টরের কাছে সরল একটি পরামিতি দ্বারা করতে পারেন।

তবে, আমি মনে করি যে আপনি যখন অ্যাপ্লিকেশন-স্তরের সংস্থানগুলির বিষয়ে কথা বলবেন তখন একটি উত্সর্গীকৃত "নির্ভরতা ইনজেকশন" প্রক্রিয়া কার্যকর হয় যেখানে কলার এবং কলি উভয়ই এই সংস্থানগুলি সম্পর্কে কিছুই জানেন না (এবং জানতে চান না!)।

উদাহরণস্বরূপ: ডাটাবেস সংযোগ, সুরক্ষা প্রসঙ্গ, লগিং সুবিধা, কনফিগারেশন ফাইল ইত্যাদি

তদুপরি, সাধারণভাবে প্রতিটি সিঙ্গলটনই ডিআই-র পক্ষে ভাল প্রার্থী। আপনার যত বেশি পরিমাণে ব্যবহার এবং ব্যবহার করবেন আপনার ডিআইআই হওয়ার সম্ভাবনা তত বেশি।

এই ধরণের সংস্থানগুলির জন্য এটি পুরোপুরি স্পষ্ট যে প্যারামিটার তালিকার মাধ্যমে তাদের চারদিকে স্থানান্তরিত করার কোনও মানে হয় না এবং তাই ডিআই আবিষ্কার হয়েছিল।

শেষ নোট, আপনার একটি ডিআই কনটেইনারও দরকার, যা প্রকৃত ইনজেকশনটি করবে ... (আবার, কলার এবং কলি উভয়কে বাস্তবায়নের বিশদ থেকে মুক্তি দিতে)।


-2

আপনি যদি কোনও বিমূর্ত রেফারেন্স প্রকারে পাস করেন তবে কলিং কোড যে কোনও অবজেক্টে বিমূর্ত প্রকারটি প্রসারিত / প্রয়োগ করে pass ভবিষ্যতে বস্তুটি ব্যবহার করে এমন শ্রেণি একটি নতুন অবজেক্ট ব্যবহার করতে পারে যা এর কোডটি কখনও পরিবর্তন না করে তৈরি করা হয়েছে।


-4

এটি আমনের উত্তর ছাড়াও অন্য একটি বিকল্প

নির্মাতারা ব্যবহার করুন:

ক্লাস ফু {
    প্রাইভেট বার বার;
    বেসরকারী Qux Qux;

    বেসরকারী ফু () {
    }

    পাবলিক ফু (বিল্ডার নির্মাতা) {
        this.bar = builder.bar;
        this.qux = builder.qux;
    }

    পাবলিক স্ট্যাটিক ক্লাস বিল্ডার {
        প্রাইভেট বার বার;
        বেসরকারী Qux Qux;
        পাবলিক বুয়েডার সেটবার (বার বার) {
            this.bar = বার;
            এটি ফেরত দিন;
        }
        পাবলিক বিল্ডার সেটকুইক্স (কুইক্স কোয়াক্স) {
            this.qux = qux;
            এটি ফেরত দিন;
        }
        পাবলিক ফু বিল্ড () {
            ফেরত নতুন ফু (এই);
        }
    }
}

// উৎপাদন:
ফু ফু = নতুন ফু-বিল্ডার ()
    .setBar (নতুন বার ())
    .setQux (নতুন Qux ())
    .build ();

// পরীক্ষায়:
ফু টেস্টফু = নতুন Foo.Builder ()
    .setBar (নতুন বারমক ())
    .setQux (নতুন Qux ())
    .build ();

নির্ভরতাগুলির জন্য এটিই আমি ব্যবহার করি। আমি কোনও ডিআই ফ্রেমওয়ার্ক ব্যবহার করি না। তারা পথে পেতে।


4
এটি এক বছর আগে থেকে অন্যান্য উত্তরগুলিতে খুব বেশি যোগ করে না এবং কোনও বিল্ডার কেন অনুরোধকারীকে নির্ভরতা ইনজেকশন বুঝতে সহায়তা করতে পারে তার কোনও ব্যাখ্যা দেয় না

@ স্নোমান এটি ডিআই-র পরিবর্তে অন্য কোনও বিকল্প। আমি দুঃখিত আপনি এটি সেভাবে দেখতে পাচ্ছেন না। ডাউন ভোটের জন্য ধন্যবাদ
ব্যবহারকারী3155341

1
প্রশ্নকর্তা বুঝতে চেয়েছিলেন যে ডিআই সত্যই প্যারামিটারটি পাস করার মতো সহজ, তিনি ডিআই-র বিকল্প চাইছেন না।

1
ওপির উদাহরণগুলি খুব ভাল। আপনার উদাহরণগুলি এমন একটি সাধারণ ধারণা যা আরও জটিলতার জোগান। তারা প্রশ্নের বিষয়টি চিত্রিত করে না।
অ্যাডাম জুকারম্যান

কনস্ট্রাক্টর ডিআই একটি প্যারামিটার দিয়ে যাচ্ছে। আপনি একটি কংক্রিট শ্রেণীর অবজেক্টের চেয়ে ইন্টারফেস অবজেক্টটি পাস করছেন। এটি কংক্রিট বাস্তবায়নের উপর এই 'নির্ভরতা' যা ডিআই এর মাধ্যমে সমাধান করা হয়। কনস্ট্রাক্টর জানেন না যে এটি প্রবাহিত হচ্ছে, না এটি যত্ন করে না, এটি কেবল জানে যে এটি এমন একটি প্রকার গ্রহণ করছে যা একটি ইন্টারফেস প্রয়োগ করে। আমি PluralSight পরামর্শ দিচ্ছি, এটিতে দুর্দান্ত ডিআই / আইওসি কোর্স রয়েছে।
হার্ডগ্রাফ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.