সার্ভিসলোকেটার কি একটি বিরোধী-নিদর্শন?

Question

সম্প্রতি আমি সার্ভিস লোকেটার বিরোধী- নিদর্শন সম্পর্কে মার্ক সিম্যানের নিবন্ধটি পড়েছি ।

সার্ভিস লোকেটারকে একটি বিরোধী-নিদর্শন বলে দুটি মূল কারণ লেখক নির্দেশ করেছেন:

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

2. রক্ষণাবেক্ষণের সমস্যা (যা আমাকে ধাঁধা দেয়)
   নীচের উদাহরণটি বিবেচনা করুন

আমাদের কাছে একটি ক্লাস 'মাইটাইপ' রয়েছে যা পরিষেবা লোকেটার পদ্ধতির নিয়োগ করে:

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();
    }
}

এখন আমরা ক্লাস 'মাইটাইপ' এর সাথে আরেকটি নির্ভরতা যুক্ত করতে চাই

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

এবং এখানেই আমার ভুল বোঝাবুঝি শুরু হয়। লেখক বলেছেন:

আপনি একটি ব্রেকিং প্রবর্তন করছেন কিনা তা বলা অনেক শক্ত হয়ে যায়। সার্ভিস লোকেটারটি ব্যবহার করা হচ্ছে এমন সম্পূর্ণ অ্যাপ্লিকেশনটি আপনাকে বুঝতে হবে এবং সংকলক আপনাকে সাহায্য করবে না।

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

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

আমি সার্ভিস লোকেটার পদ্ধতির প্রতিরক্ষা করার চেষ্টা করছি না। তবে এই ভুল বোঝাবুঝি আমাকে ভাবায় যে আমি খুব গুরুত্বপূর্ণ কিছু হারাচ্ছি। কেউ কি আমার সন্দেহ দূর করতে পারে?

আপডেট (সংক্ষিপ্ত):

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

এবং এখানে মূল পার্থক্য রয়েছে যা আমার নতুন প্রকল্পগুলির জন্য পরিষেবা লোকেটারটি ব্যবহার না করার জন্য আমাকে নিশ্চিত করেছিল:

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

বিস্তারিত জানার জন্য নীচে দেওয়া দুর্দান্ত উত্তরগুলি পড়ুন।

Comments

"আমাদের কি সেই সমস্ত ক্লাসটি আপডেট করার দরকার নেই যা এই বর্গটি ইনস্ট্যান্ট করছে?" আপনি যদি পরীক্ষাগুলিতে কোনও বিল্ডার ব্যবহার করে থাকেন তবে অগত্যা সত্য। এই ক্ষেত্রে আপনাকে কেবল বিল্ডারকে আপডেট করতে হবে।

— পিটার কার্লসন

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

— জি। লম্বার্ড

নোট করুন যেহেতু এই প্রশ্নটি পোস্ট করা হয়েছে, তাই মার্ক সিম্যানের সার্ভিস লোকেটার সম্পর্কে একটি আপডেট রয়েছে যা বর্ণনা করে যে পরিষেবা লোকেটার কীভাবে এনক্যাপসুলেশন ভেঙে ওওপি লঙ্ঘন করে, এটি এখনও তার সেরা যুক্তি (এবং সমস্ত লক্ষণগুলির অন্তর্নিহিত কারণ) যা তিনি সমস্ত পূর্বের যুক্তিতে ব্যবহার করেছিলেন)। 2015-10-26 আপডেট করুন: পরিষেবা লোকেটারের সাথে মৌলিক সমস্যাটি হ'ল এটি এনকেপসুলেশন লঙ্ঘন করে ।

— নাইটওয়েল 888

Answer 1

আপনি যদি নিদর্শনগুলিকে অ্যান্টি-প্যাটার্ন হিসাবে সংজ্ঞায়িত করেন কারণ কিছু পরিস্থিতি যেখানে এটি মাপসই হয় না, তবে হ্যাঁ এটি একটি বিরোধী নিদর্শন। তবে সেই যুক্তি সহ সমস্ত নিদর্শনগুলিও বিরোধী নিদর্শন হতে পারে।

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

public class MyType
{
    public void MyMethod()
    {
        var dep1 = Locator.Resolve<IDep1>();
        dep1.DoSomething();

        // new dependency
        var dep2 = Locator.Resolve<IDep2>();
        dep2.DoSomething();
    }
}

এই শ্রেণীর সাথে রক্ষণাবেক্ষণের দুঃস্বপ্ন হ'ল নির্ভরতাগুলি লুকানো থাকে। আপনি যদি এই শ্রেণিটি তৈরি করেন এবং ব্যবহার করেন:

var myType = new MyType();
myType.MyMethod();

আপনি বুঝতে পারবেন না যে সেবারের অবস্থান ব্যবহার করে যদি তারা লুকানো থাকে তবে এর নির্ভরতা রয়েছে। এখন, যদি আমরা এর পরিবর্তে নির্ভরতা ইনজেকশন ব্যবহার করি:

public class MyType
{
    public MyType(IDep1 dep1, IDep2 dep2)
    {
    }

    public void MyMethod()
    {
        dep1.DoSomething();

        // new dependency
        dep2.DoSomething();
    }
}

আপনি সরাসরি নির্ভরতাগুলি চিহ্নিত করতে পারেন এবং ক্লাসগুলি সন্তুষ্ট করার আগে তাদের ব্যবহার করতে পারবেন না।

ব্যবসায়িক অ্যাপ্লিকেশনটির একটি সাধারণ লাইনে আপনার সেই কারণেই পরিষেবা অবস্থানের ব্যবহার এড়ানো উচিত। অন্য বিকল্প নেই যখন এটি ব্যবহার করার প্যাটার্ন হওয়া উচিত।

নিদর্শন কি একটি বিরোধী-নিদর্শন?

না।

উদাহরণস্বরূপ, নিয়ন্ত্রণ পাত্রে বিপরীতকরণ পরিষেবা অবস্থান ছাড়া কাজ করবে না। এটি সেভাবেই পরিষেবাগুলি অভ্যন্তরীণভাবে সমাধান করে।

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

তোমার প্রশ্নগুলো

তবে এক সেকেন্ড অপেক্ষা করুন, আমরা যদি ডিআই পন্থাটি ব্যবহার করতাম তবে আমরা কনস্ট্রাক্টর (কনস্ট্রাক্টর ইনজেকশনের ক্ষেত্রে) অন্য একটি প্যারামিটারের সাথে নির্ভরতা প্রবর্তন করব। এবং সমস্যা এখনও থাকবে।

আরও দুটি গুরুতর সমস্যা রয়েছে:

1. পরিষেবার অবস্থানের সাথে আপনি আরও একটি নির্ভরতা যুক্ত করছেন: পরিষেবা লোকেটার।
2. কোন আজীবন নির্ভরতা থাকা উচিত এবং কীভাবে / কখন তা পরিষ্কার করা উচিত তা আপনি কীভাবে বলবেন?

কনটেইনার ব্যবহার করে কনস্ট্রাক্টর ইঞ্জেকশন দিয়ে আপনি এটি নিখরচায় পাবেন।

আমরা যদি সার্ভিস লোকেশন সেটআপ করতে ভুলে যেতে পারি, তবে আমরা আমাদের আইওসি ধারকটিতে একটি নতুন ম্যাপিং যুক্ত করতে ভুলে যেতে পারি এবং ডিআই পদ্ধতির একই রানটাইম সমস্যা হতে পারে।

সেটা সত্য. কনস্ট্রাক্টর ইনজেকশন সহ কোন নির্ভরতা অনুপস্থিত তা নির্ধারণ করতে আপনাকে পুরো ক্লাসটি স্ক্যান করতে হবে না।

এবং কিছু ভাল ধারক প্রারম্ভকালে সমস্ত নির্ভরতা বৈধ করে দেয় (সমস্ত নির্মাতা স্ক্যান করে)। সুতরাং সেই ধারকগুলির সাহায্যে আপনি সরাসরি রানটাইম ত্রুটি পাবেন এবং কোনও সাময়িক সময়ে নয়।

এছাড়াও, ইউনিট পরীক্ষার অসুবিধা সম্পর্কে লেখক উল্লেখ করেছেন। কিন্তু, আমাদের ডিআই পদ্ধতির সাথে সমস্যা হবে না?

না। যেমন আপনার কোনও স্থিতিশীল পরিষেবা লোকেটারের উপর নির্ভরতা নেই। আপনি কি স্থির নির্ভরতার সাথে কাজ করে সমান্তরাল পরীক্ষা পাওয়ার চেষ্টা করেছেন? এটা মজা না.

Comments

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

— ডেভিডফ

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

— স্টিভেন

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

— সুমেরে

আমি এটি উল্লেখ করতে চাই না যে এটি একটি সাধারণভাবে ভাল উত্তর, আমি আপনার করা একটি বিভ্রান্তিমূলক বিষয় নিয়ে কেবল মন্তব্য করেছি।

— সুমেরে

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

— মিররফেট

Answer 2

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

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

Comments

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

— স্টিভেন

পুনরায়: "আপনি যখন উত্তরাধিকারের কোডটি নিয়ে কাজ করছেন, তখন আপনাকে সেই জগাখিচুড়ি থেকে বের করে আনার জন্য সবকিছুই ন্যায়সঙ্গত হয়" কখনও কখনও আমি ভাবতে পারি যে কেবলমাত্র লিগ্যাসি কোডের অল্প অস্তিত্ব আছে কি না, তবে কারণ আমরা এটিকে ঠিক করার জন্য কোনও কিছুকে ন্যায়সঙ্গত করতে পারি আমরা কোনওরকমে কখনই এটি করতে পরিচালিত হয়নি।

— ড্রিউ ডেলাানো

Answer 3

পরীক্ষার দৃষ্টিকোণ থেকে, পরিষেবা লোকেটারটি খারাপ। মিসকো হেভির গুগল টেকের কোড উদাহরণগুলির সাথে দুর্দান্ত ব্যাখ্যা দেখুন http://youtu.be/RlfLCWKxHJ0 মিনিট 8:45 মিনিটে শুরু। আমি তার সাদৃশ্যটি পছন্দ করেছি: আপনার যদি 25 ডলার দরকার হয় তবে আপনার ওয়ালেট যেখান থেকে নেওয়া হবে তা দেওয়ার চেয়ে সরাসরি অর্থের জন্য জিজ্ঞাসা করুন। তিনি সার্ভিস লোকেটারকে একটি খড়খড়ির সাথেও তুলনা করেছেন যাতে আপনার প্রয়োজনীয় সুই রয়েছে এবং কীভাবে এটি পুনরুদ্ধার করতে হবে তা জানেন। পরিষেবা লোকেটার ব্যবহার করে ক্লাসগুলির কারণে এটি পুনরায় ব্যবহার করা শক্ত।

Comments

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

— 8bitjunkie

Answer 4

রক্ষণাবেক্ষণের সমস্যা (যা আমাকে ধাঁধা দেয়)

এই ক্ষেত্রে পরিষেবা লোকেটার ব্যবহার খারাপ হওয়ার দুটি ভিন্ন কারণ রয়েছে।

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

সরল এবং সরল: এর মধ্যে একটি সার্ভিস লোকেটার সহ একটি শ্রেণীর যেটি তার নির্মাণকারীর মাধ্যমে তার নির্ভরতা গ্রহণ করে এমন একের চেয়ে পুনরায় ব্যবহার করা আরও বেশি কঠিন ।

কেস তুমি কোথা থেকে একটি সেবা ব্যবহার করতে হবে বিবেচনা করুন LibraryAসংশ্লিষ্ট লেখক ব্যবহার করেন যে সিদ্ধান্ত নিয়েছে ServiceLocatorAথেকে একটি সেবা LibraryBযার লেখক ব্যবহার করেন সিদ্ধান্ত নিয়েছে ServiceLocatorB। আমাদের প্রকল্পে 2 টি পৃথক পরিষেবা লোকেটার ব্যবহার করা ছাড়া আমাদের আর কোনও বিকল্প নেই। আমাদের যদি ভাল ডকুমেন্টেশন, সোর্স কোড বা স্পিড ডায়ালটিতে লেখক না থাকে তবে কতটা নির্ভরশীলতা কনফিগার করতে হবে তা অনুমান করার গেম। এই বিকল্পগুলি ব্যর্থ করে, আমাদের কেবল একটি ডিকম্পিলার ব্যবহার করতে হবেনির্ভরতা কি তা নির্ধারণ করা। আমাদের দুটি সম্পূর্ণ ভিন্ন পরিষেবা লোকেটার এপিআইগুলি কনফিগার করতে হবে এবং ডিজাইনের উপর নির্ভর করে কেবল আপনার বিদ্যমান ডিআই কনটেইনারটি মোড়ানো সম্ভব নয় not দুটি গ্রন্থাগারের মধ্যে নির্ভরতার একটি উদাহরণ ভাগ করে নেওয়া মোটেও সম্ভব নয়। প্রকল্পের জটিলতা আরও জটিল হতে পারে যদি সার্ভিস লোকেটারগুলি আমাদের প্রয়োজনীয় পরিষেবাগুলির মতো একই লাইব্রেরিতে থাকতে না পারে - আমরা স্পষ্টভাবে আমাদের প্রকল্পে অতিরিক্ত গ্রন্থাগার উল্লেখগুলি টেনে নিচ্ছি।

কনস্ট্রাক্টর ইনজেকশন দিয়ে তৈরি একই দুটি পরিষেবা বিবেচনা করুন। একটি রেফারেন্স যোগ করুন LibraryA। একটি রেফারেন্স যোগ করুন LibraryB। আপনার ডিআই কনফিগারেশনে নির্ভরতা সরবরাহ করুন (ইন্টেলিসেন্সের মাধ্যমে কী প্রয়োজন তা বিশ্লেষণ করে)। সম্পন্ন.

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

Answer 5

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

সি # এর মাধ্যমে অ্যাডেটিভ কোডের একটি অনুচ্ছেদ এখানে রয়েছে :

"দুর্ভাগ্যক্রমে, সার্ভিস লোকেটারটি কখনও কখনও একটি অপরিবর্তনীয় অ্যান্টি-প্যাটার্ন হয় some মোটেও নির্ভরতা ইনজেকশন না করাই ভাল ( এবং অনুরূপ সুবিধা। "

- হল, গ্যারি ম্যাকলিন সি # এর মাধ্যমে অভিযোজিত কোড: ডিজাইনের নিদর্শন এবং সোলিড নীতিগুলি (বিকাশকারী রেফারেন্স) (পৃষ্ঠা 309) সহ চৌকস কোডিং। পিয়ারসন শিক্ষা.

Answer 6

লেখকের কারণ যে "সংকলক আপনাকে সাহায্য করবে না" - এবং এটি সত্য। আপনি যখন কোনও শ্রেণীর নাম লেখেন, আপনি এটির মতো স্বাধীন হিসাবে গড়ে তুলতে অন্যান্য লক্ষ্যগুলির মধ্যে - এটি যথাযথরূপে তার ইন্টারফেসটি বেছে নিতে চাইবেন - এটি যতটা বোধগম্য।

ক্লায়েন্টকে স্পষ্ট ইন্টারফেসের মাধ্যমে কোনও পরিষেবার (কোনও নির্ভরতার কাছে) রেফারেন্স গ্রহণ করার মাধ্যমে, আপনি

• স্পষ্টতই চেকিং পান, সুতরাং সংকলক "সহায়তা" করে।
• আপনি ক্লায়েন্টকে "লোকেটার" বা অনুরূপ প্রক্রিয়া সম্পর্কে কিছু জানার প্রয়োজনীয়তাও সরিয়ে দিচ্ছেন, তাই ক্লায়েন্ট আসলে আরও স্বতন্ত্র।

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

Comments

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

— ডেভিডফ

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

— মঙ্গলবার

বাস্তবায়ন / কোডিং এবং মানের নিশ্চয়তা সম্পর্কে চিন্তাভাবনা - কোডের পাঠযোগ্যতা অত্যন্ত গুরুত্বপূর্ণ - বিশেষত ইন্টারফেস সংজ্ঞার জন্য। আপনি যদি স্বয়ংক্রিয়ভাবে সংকলনের সময় যাচাই না করে করতে পারেন এবং আপনি যদি আপনার ইন্টারফেসের পর্যাপ্ত মন্তব্য / ডকুমেন্ট করেন তবে আমি অনুমান করি যে আপনি সহজেই দৃশ্যমান / প্রত্যাশিত বিষয়বস্তু সহ একধরনের বৈশ্বিক চলকের উপর লুকানো নির্ভরতার অসুবিধাগুলি কমপক্ষে আংশিকভাবে প্রতিকার করতে পারেন। আমি বলব যে এই প্যাটার্নটি ব্যবহার করতে আপনার এই কারণগুলির পক্ষে আরও বেশি কারণের দরকার।

— জেরিন 18

Answer 7

হ্যাঁ, সার্ভিস লোকেটারটি একটি অ্যান্টি-প্যাটার্ন যা এটি এনক্যাপসুলেশন এবং কঠিন লঙ্ঘন করে ।

Comments

আমি কী বোঝাতে চাইছি তা বুঝতে পেরেছি তবে এটি আরও বিশদ যুক্ত করতে সহায়ক হবে, উদাহরণস্বরূপ কেন এটি সলিড লঙ্ঘন করে

— রেগেইগুইটার