উপাদানগুলি নির্ভরতা বনাম ডাগর 2 উপ-উপাদানগুলি

Question

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

কোন পরিস্থিতিতে উপ- উপাদান নির্ভরতার পরিবর্তে কোনও উপাদান নির্ভরতা ব্যবহার করা উপকারী হবে এবং কেন?

Answer 1

উপাদান নির্ভরতা - আপনি যখন দুটি উপাদান স্বাধীন রাখতে চান তখন এটি ব্যবহার করুন।

উপ-উপাদানগুলি - আপনি দুটি উপাদান একত্রে রাখতে চাইলে এটি ব্যবহার করুন।

---

কম্পোনেন্ট নির্ভরতা এবং উপ- উপাদানগুলি ব্যাখ্যা করার জন্য আমি নীচের উদাহরণটি ব্যবহার করব । উদাহরণটি লক্ষ্য করার মতো কয়েকটি বিষয় হ'ল:

• SomeClassA1কোনও নির্ভরতা ছাড়াই তৈরি করা যায়। পদ্ধতির মাধ্যমে ModuleAউদাহরণ সরবরাহ SomeClassA1করে provideSomeClassA1()।
• SomeClassB1ছাড়া তৈরি করা যায় না SomeClassA1। পদ্ধতির আর্গুমেন্ট হিসাবে কোনও উদাহরণ পাস করা হলে কেবল তার ModuleBউদাহরণ সরবরাহ করতে পারে ।SomeClassB1SomeClassA1provideSomeClassB1()

@Module
public class ModuleA {
    @Provides
    public SomeClassA1 provideSomeClassA1() {
        return new SomeClassA1();
    }
}

@Module
public class ModuleB {
    @Provides
    public SomeClassB1 provideSomeClassB1(SomeClassA1 someClassA1) {
        return new SomeClassB1(someClassA1);
    }
}

public class SomeClassA1 {
    public SomeClassA1() {}
}

public class SomeClassB1 {
    private SomeClassA1 someClassA1;

    public SomeClassB1(SomeClassA1 someClassA1) {
        this.someClassA1 = someClassA1;
    }
}

যখনই কম্পোনেন্ট / সাবকম্পোনেন্ট ঘোষণা ঘোষণা শুরু করা হবে তখন ড্যাগার পদ্ধতির SomeClassA1আর্গুমেন্ট হিসাবে উদাহরণটি পাস করার যত্ন নেবে । নির্ভরতা কীভাবে পূরণ করতে হয় তা আমাদের ডাগরকে নির্দেশ দিতে হবে। কম্পোনেন্ট নির্ভরতা বা উপ- কম্পোনেন্ট ব্যবহার করে এটি করা যেতে পারে ।provideSomeClassB1()ModuleBModuleB

উপাদান নির্ভরতা

নীচে উপাদান নির্ভরতা উদাহরণে নিম্নলিখিত পয়েন্টগুলি নোট করুন:

• ComponentBটিকা রোধের dependenciesপদ্ধতির মাধ্যমে নির্ভরতা নির্ধারণ করতে হবে @Component।
• ComponentAঘোষণা করার দরকার নেই ModuleB। এটি দুটি উপাদানকে স্বাধীন রাখে।

public class ComponentDependency {
    @Component(modules = ModuleA.class)
    public interface ComponentA {
        SomeClassA1 someClassA1();
    }

    @Component(modules = ModuleB.class, dependencies = ComponentA.class)
    public interface ComponentB {
        SomeClassB1 someClassB1();
    }

    public static void main(String[] args) {
        ModuleA moduleA = new ModuleA();
        ComponentA componentA = DaggerComponentDependency_ComponentA.builder()
                .moduleA(moduleA)
                .build();

        ModuleB moduleB = new ModuleB();
        ComponentB componentB = DaggerComponentDependency_ComponentB.builder()
                .moduleB(moduleB)
                .componentA(componentA)
                .build();
    }
}

SubComponent

সাবকম্পোন্ট উদাহরণে নিম্নলিখিত পয়েন্টগুলি নোট করুন:

• যেমন ComponentBনির্ভরতা নির্ধারণ করে নি ModuleA, এটি স্বাধীনভাবে বাঁচতে পারে না। এটি উপাদান সরবরাহ করবে যা সরবরাহ করবে ModuleA। অতএব এটি একটি @Subcomponentটিকা আছে।
• ComponentAModuleBইন্টারফেস পদ্ধতি মাধ্যমে ঘোষণা করেছে componentB()। এটি দুটি উপাদান একত্রিত করে। আসলে, ComponentBশুধুমাত্র মাধ্যমে সূচনা করা যেতে পারে ComponentA।

public class SubComponent {
    @Component(modules = ModuleA.class)
    public interface ComponentA {
        ComponentB componentB(ModuleB moduleB);
    }

    @Subcomponent(modules = ModuleB.class)
    public interface ComponentB {
        SomeClassB1 someClassB1();
    }

    public static void main(String[] args) {
        ModuleA moduleA = new ModuleA();
        ComponentA componentA = DaggerSubComponent_ComponentA.builder()
                .moduleA(moduleA)
                .build();

        ModuleB moduleB = new ModuleB();
        ComponentB componentB = componentA.componentB(moduleB);
    }
}

Comments

আমার একটি উপ-কম্পোনেন্ট সেটআপ রয়েছে যা মডিউল বি কমপোনেন্টএ-তে যোগ করে না, তারপরে এর অর্থ হল কম্পোনেন্টএ বিল্ডারের মডিউলবিয়ের প্রয়োজন নেই need অ্যাপ্লিকেশন শুরু হওয়ার পরে কম্পোনেন্টএ তৈরির অনুমতি এবং তারপরে এমটি ইনস্ট্যান্ট করার জন্য আমি যেভাবে প্রত্যাশা করছিলাম এটি কাজ করে বলে মনে হচ্ছে

— বন্ধুত্বপূর্ণ

@ মাইকএন - আপনি কীভাবে কম্পোনেন্টএ-তে মডিউলবি থেকে মুক্তি পেতে পারেন তা হাইলাইট করতে পারবেন? আমি কেবলমাত্র কম্পোনেন্টএ এবং কম্পোনেন্টবিতে বিভিন্ন স্কোপ সরবরাহ করলেই আমি মডিউলবি থেকে মুক্তি পেতে পারি।

— প্রবীর গুপ্ত

আপনি ঠিক বলেছেন আমার সেটআপ কাজ করে কারণ তারা বিভিন্ন স্কোপে রয়েছে। ক্ষমাপ্রার্থী।

— বন্ধুত্বপূর্ণ

" SomeClassB1উপর নির্ভরশীল SomeClassA1। ComponentAস্পষ্টভাবে নির্ভরতা সংজ্ঞায়িত করতে রয়েছে।" ==> আপনি " ComponentBস্পষ্টভাবে নির্ভরতা নির্ধারণ করতে হবে " বোঝাতে চেয়েছেন ?

— Tar থেকে

কি @Tar উল্লেখ করতে একইভাবে, আমি বুঝতে মধ্যে "যে SomeClassB1উপর নির্ভরশীল SomeClassA1। ComponentAস্পষ্টভাবে নির্ভরতা সংজ্ঞায়িত করার প্রয়োজন নেই।" আপনার অর্থ " ComponentBস্পষ্টভাবে নির্ভরতা নির্ধারণ করার দরকার নেই " meant

— সেবাস এলজি

Answer 2

ডকুমেন্টেশন অনুযায়ী :

Component Dependencyউপাদান নির্ভরতাগুলির মাধ্যমে বিধান পদ্ধতি হিসাবে উদ্ভাসিত বাইন্ডিংগুলিতে আপনাকে অ্যাক্সেস দেয়, অর্থাত পিতামাতার মধ্যে ঘোষিত কেবলমাত্র আপনার কাছেই অ্যাক্সেস রয়েছে Component।

SubComponentএটি ঘোষণার সাথে সাথে আপনাকে তার পিতা-মাতার কাছ থেকে পুরো বাঁধাই গ্রাফটিতে অ্যাক্সেস দেয় , অর্থাত্ এর Moduleএর মধ্যে ঘোষিত সমস্ত অবজেক্টে আপনার অ্যাক্সেস রয়েছে ।

আসুন বলুন, আপনার আছে একটি ApplicationComponentসব ধারণকারী Androidসংশ্লিষ্ট কাপড় ( LocationService, Resources, SharedPreference, ইত্যাদি)। আপনি DataComponentযেখানে WebServiceAPI গুলি মোকাবেলার পাশাপাশি অধ্যবসায়ের জন্য জিনিস পরিচালনা করেন সেখানেও আপনার থাকতে চান । কেবলমাত্র যেটির মধ্যে আপনি অভাব বোধ করেন DataComponentতা হ'ল Application Contextযা থাকে ApplicationComponent। সহজ উপায় একটি পেতে Contextথেকে DataComponentউপর নির্ভরতা হবে ApplicationComponent। আপনার নিশ্চিত হওয়া দরকার যে আপনার একটি Contextস্পষ্টভাবে ঘোষণা করেছেন ApplicationComponentকারণ আপনার কাছে কেবল ঘোষিত স্টাফগুলিতে অ্যাক্সেস রয়েছে। এই ক্ষেত্রে, কোনও ম্যানুয়াল কাজ নেই, অর্থাত আপনাকে Submodulesপিতামাতার মধ্যে নির্দিষ্ট করার দরকার নেই Componentএবং স্পষ্টভাবে আপনার সাব-মডিউলটিকে প্যারেন্ট মডিউলে যুক্ত করতে হবে যেমন:

MySubcomponent mySubcomponent = myComponent.plus(new ChildGraphModule("child!")); // No need!

এখন যে ক্ষেত্রে যেখানে আপনি উদ্বুদ্ধ করতে চান বিবেচনা WebServiceথেকে DataComponentএবং LocationServiceথেকে ApplicationComponentআপনার মধ্যে Fragmentব্যবহার যা বেঁধে @Submodule plusউপরে বৈশিষ্ট্য। এখানে দুর্দান্ত জিনিস হ'ল আপনি যে উপাদানটি ( ApplicationComponent) এ আবদ্ধ করছেন তা প্রকাশ করার দরকার নেই WebServiceবা LocationServiceআপনার সরাসরি গ্রাফটিতে এখনই অ্যাক্সেস নেই বলে।

Comments

আমি যদি সঠিকভাবে বুঝতে পারি তবে কোনও ইন্টারফেস বলা হবে না @Submodule। এটা কি টাইপো?

— ইসলাম সালাহ

আমি পছন্দ করি কীভাবে এটি পার্থক্যটি প্রদর্শন করতে বাস্তব জীবনের উদাহরণ ব্যবহার করে। তবে এটি ডক্স পড়ার চেয়ে বিভ্রান্তিকর। classesসঠিক পয়েন্টটি বর্ণনা করার জন্য উদাহরণের তুলনায় কম ছবি এবং আরও ছবি রাখতে সহায়তা করবে।

— সুডোকোডার

Answer 3

কম্পোনেন্ট এবং সাবকমম্পোনেন্টের আরও বোঝার জন্য এখানে স্ক্রিনশট সহ কোড উদাহরণ রয়েছে:

উপাদান:

1. অ্যাপকোম্পোন্টে দুটি ঘোষণা রয়েছে।
2. অ্যাপকোম্পোন্ট অ্যাপ্লিকেশন ক্লাসে আরম্ভ করে।
3. হোমঅ্যাক্টিভিটি কম্পোনেন্ট অ্যাপকম্পোন্টের উপর নির্ভরশীল।
4. ডাগারহোমঅ্যাক্টিভিটি কম্পোনেন্টের সূচনাতে হোমঅ্যাক্টিভিটিতে, আমি একটি কম্পোজিশন হিসাবে অ্যাপকোম্পোন্ট অবজেক্ট দিচ্ছি।

SubComponent:

1. অ্যাপকোম্পোন্টে উপকোম্পোনেন্ট বা উপ-উপাদান রয়েছে।
2. অ্যাপকোম্পোন্ট অ্যাপ্লিকেশন ক্লাসে আরম্ভ করে।
3. সাবকম্পোনেন্ট তার প্যারেন্টকম্পোন্টেন্ট সম্পর্কে জানে না। এটি কেবলমাত্র মডিউল অন্তর্ভুক্ত করে তার নিজস্ব নির্ভরতা সরবরাহ করে।
4. হোমঅ্যাক্টিভিটিতে আমি সাব-কম্পোনেন্টটিকে তার মূল উপাদান ব্যবহার করে ইনজেকশন দিচ্ছি।

এবং চিত্রের ডায়াগ্রাম:

সূত্র: লিংক

Comments

উপ-সংযোজনটি অ্যাপকোম্পোনটিটি বন্ধ করে দিলে চিত্রটি কী আরও বোঝাতে পারবে না?

— ফ্লোরিয়ান ওয়ালথার

Answer 4

আর একটি জিনিস যা আমি এখনও অবধি বুঝতে পারি নি তা হ'ল:

• একটি @Subcomponentউদাহরণে ঠিক একটি প্যারেন্ট উপাদান রয়েছে (যদিও বিভিন্ন উপাদান সেগুলি ইনস্ট্যান্ট করতে @Subcomponentপারে এবং সেই উদাহরণের পিতামাতা হতে পারে)
• A এর @Componentশূন্য, এক, বা অনেকগুলি "পিতামাতার" উপাদানগুলি উপাদান নির্ভরতার মাধ্যমে ঘোষিত হতে পারে

Comments

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

— ডেমক্সি

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

— arekolek