অবশ্যই নির্ভরতা ইঞ্জেকশনটি এনক্যাপসুলেশন ব্যয় করে আসতে হবে?

Question

আমি যদি সঠিকভাবে বুঝতে পারি তবে ডিপেন্ডেন্সি ইনজেকশনের সাধারণ পদ্ধতিটি হয় কোনও শ্রেণীর 'কন্সট্রাক্টরের মাধ্যমে বা শ্রেণীর পাবলিক সম্পত্তি (সদস্য) এর মাধ্যমে ইনজেকশন করা।

এটি নির্ভরতা ইনজেকশনের মাধ্যমে প্রকাশ করে এবং এনক্যাপসুলেশনের ওওপি নীতি লঙ্ঘন করে।

আমি কি এই ট্রেডঅফ সনাক্তকরণে সঠিক? আপনি এই সমস্যাটি কীভাবে মোকাবেলা করবেন?

দয়া করে নীচে আমার নিজের প্রশ্নের উত্তরটি দেখুন।

Comments

এটি একটি খুব স্মার্ট প্রশ্ন

— imho

এই প্রশ্নের উত্তর দেওয়ার জন্য প্রথমে এনক্যাপসুলেশন বলতে কী বোঝায় সে সম্পর্কে একটি যুক্তি প্রয়োজন । ;)

— জেফ স্টার্নাল

ইন্টারফেস দ্বারা এনক্যাপসুলেশন বজায় রাখা হয়। তারা অবজেক্টের প্রয়োজনীয় বৈশিষ্ট্যগুলি প্রকাশ করে এবং নির্ভরতা হিসাবে বিশদগুলি গোপন করে। এটি আমাদের আরও কিছুটা নমনীয় কনফিগারেশন সরবরাহ করতে ক্লাসগুলিকে কিছুটা 'ওপেন-আপ' করতে দেয়।

— লরেন্স ওয়াগারফিল্ড

Answer 1

এই সমস্যাটি দেখার আরও একটি উপায় রয়েছে যা আপনাকে আকর্ষণীয় বলে মনে হতে পারে।

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

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

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

দুর্ভাগ্যক্রমে আমাদের ভাষাগুলি বর্তমানে মোটা-দানাযুক্ত উপাদান-ভিত্তিক ধারণাগুলি থেকে সূক্ষ্ম বর্ণযুক্ত, বস্তু-ভিত্তিক ধারণাগুলি পৃথক করে না, সুতরাং এটি কেবলমাত্র আপনার মনে রাখা উচিত এটি একটি পার্থক্য :)

Comments

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

— রন ইনবার

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

— নিকোলাস ব্লুমহার্ট

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

— নিউট্রিনো

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

— নিউট্রিনো

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

— নিকোলাস ব্লুমহার্ট ২

Answer 2

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

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

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

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

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

Comments

ভাল দিক. আমি বেসরকারী ক্ষেত্রগুলিতে @ অ্যাটওয়ার্ড ব্যবহারের বিরুদ্ধে পরামর্শ দিচ্ছি; যা ক্লাসকে পরীক্ষা করা শক্ত করে তোলে; আপনি কীভাবে মক বা স্টাব ইনজেক্ট করবেন?

— lumpynose

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

— রোগরিও

@ রোজারিও - যুক্তিযুক্ত কোনও ডিআই ফ্রেমওয়ার্ক আপনার বর্ণিত সার্ভিস লোকারের মতো কাজ করে; ক্লায়েন্ট Foo বাস্তবায়ন সম্পর্কে নির্দিষ্ট কিছু জানে না, এবং ডিআই সরঞ্জাম ক্লায়েন্ট সম্পর্কে নির্দিষ্ট কিছু জানে না। এবং এনক্যাপসুলেশন লঙ্ঘনের জন্য "নতুন" ব্যবহার করা আরও খারাপ, কারণ আপনাকে কেবল সঠিক বাস্তবায়ন ক্লাসই জানতে হবে না, তবে প্রয়োজনীয় সমস্ত নির্ভরতার সঠিক ক্লাস এবং উদাহরণগুলিও জানতে হবে।

— আন্দ্রেজেজ ডয়েল

একটি সহায়ক শ্রেণি ইনস্ট্যান্ট করতে "নতুন" ব্যবহার করা, যা প্রায়শই প্রকাশ্য হয় না, এনক্যাপসুলেশনকে উত্সাহ দেয়। ডিআই বিকল্প হ'ল সহায়তা সহায়ক শ্রেণিকে সর্বজনীন করা এবং ক্লায়েন্ট শ্রেণিতে একটি পাবলিক কনস্ট্রাক্টর বা সেটটার যুক্ত করা; উভয় পরিবর্তনগুলি আসল সহায়ক শ্রেণীর দ্বারা সরবরাহিত এনক্যাপসুলেশনটি ভেঙে দেবে।

— Rogério

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

— নিউট্রিনো

Answer 3

এটি নির্ভরতা ইনজেকশনের মাধ্যমে প্রকাশ করে এবং এনক্যাপসুলেশনের ওওপি নীতি লঙ্ঘন করে।

ঠিক আছে, খোলামেলাভাবে বলতে গেলে, সবকিছুই এনক্যাপসুলেশন লঙ্ঘন করে। :) এটি এক প্রকারের দরপত্র নীতি যা অবশ্যই ভালভাবে আচরণ করা উচিত।

সুতরাং, কী encapsulation লঙ্ঘন করে?

উত্তরাধিকার আছে ।

"যেহেতু উত্তরাধিকার তার পিতামাতার বাস্তবায়নের বিশদটিতে একটি উপক্লাস প্রকাশ করে, তাই প্রায়শই বলা হয় যে 'উত্তরাধিকার এনক্যাপসুলেশনটি ভেঙে দেয়"। (গ্যাং অফ ফোর 1995: 19)

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

সি ++ বন্ধু ঘোষণা করে ।

রুবির ক্লাস এক্সটেনশন করে । স্ট্রিং ক্লাসটি পুরোপুরি সংজ্ঞায়িত হওয়ার পরে কোথাও একটি স্ট্রিং পদ্ধতি পুনরায় সংজ্ঞায়িত করুন।

ভাল, অনেক জিনিস আছে ।

এনক্যাপসুলেশন একটি ভাল এবং গুরুত্বপূর্ণ নীতি। তবে একমাত্র নয়।

switch (principle)
{
      case encapsulation:
           if (there_is_a_reason)
      break!
}

Comments

"এগুলি আমার নীতি, এবং আপনি যদি সেগুলি পছন্দ না করেন ... ভাল, আমার অন্যও আছে" " (গ্রুপো মার্কস)

— রন ইনবার

আমি মনে করি এটি বিন্দু সাজানোর। এটি নির্ভরশীল ইনজেকশন বনাম এনক্যাপসুলেশন। সুতরাং কেবল নির্ভরশীল ইঞ্জেকশন ব্যবহার করুন যেখানে এটি উল্লেখযোগ্য বেনিফিট দেয়। এটি ডিআইই সর্বত্র যে ডিআই কে একটি খারাপ নাম দেয়

— রিচার্ড টিংল

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

— রোগারিও

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

— নিউট্রিনো

Answer 4

হ্যাঁ, ডিআই এনক্যাপসুলেশন লঙ্ঘন করে ("তথ্য গোপনীয়তা" নামেও পরিচিত)।

তবে আসল সমস্যাটি তখন আসে যখন বিকাশকারীরা এটিকে কেআইএসএস (শর্ট এবং সিম্পল রাখুন) এবং ইয়াগনি (আপনার প্রয়োজন হবে না) নীতিগুলি লঙ্ঘনের অজুহাত হিসাবে ব্যবহার করে।

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

Comments

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

— জ্যাকব

Answer 5

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

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

আমি এটি এইভাবে ভাবব: নির্ভরতা ইনজেকশন ধারক / সিস্টেম এনক্যাপসুলেশন লঙ্ঘন করে তবে আপনার কোডটি তা করে না। আসলে, আপনার কোডটি তখন থেকে বেশি "এনক্যাপসুলেটেড"।

Comments

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

— রোগরিও

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

— নিউট্রিনো

Answer 6

জেফ স্টার্নাল যেমন প্রশ্নের একটি মন্তব্যে নির্দেশ করেছেন, উত্তরটি কীভাবে আপনি encapsulation সংজ্ঞায়িত করেন তার উপর পুরোপুরি নির্ভর করে ।

এনক্যাপসুলেশন বলতে কী বোঝায় তার প্রধান দুটি শিবির রয়েছে:

1. বস্তুর সাথে সম্পর্কিত সমস্ত কিছুই কোনও বস্তুর একটি পদ্ধতি। সুতরাং, একটি Fileবস্তু পদ্ধতি থাকতে পারে Save, Print, Display, ModifyText, ইত্যাদি
2. একটি বস্তু তার নিজস্ব ছোট্ট বিশ্ব, এবং বাইরের আচরণের উপর নির্ভর করে না।

এই দুটি সংজ্ঞা একে অপরের প্রত্যক্ষ দ্বন্দ্ব। যদি কোনও Fileবস্তু নিজেই মুদ্রণ করতে পারে তবে এটি প্রিন্টারের আচরণের উপর নির্ভর করবে। অন্যদিকে, যদি এটা নিছক জানে এমন কিছু বলে (একটি জন্য মুদ্রণ করতে পারেন সম্পর্কে IFilePrinterবা কিছু যেমন ইন্টারফেস), তারপর Fileবস্তু সম্পর্কে মুদ্রণ এবং তাই এটি নিয়ে কাজ বস্তুর মধ্যে কম নির্ভরতা আনব কিছু জানতে নেই।

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

অন্যদিকে, যদি আপনি এনক্যাপসুলেশনের দ্বিতীয় সংজ্ঞা ব্যবহার করেন তবে নির্ভরতা ইঞ্জেকশনটি প্রায় বাধ্যতামূলক ।

Comments

আমি অবশ্যই প্রথম সংজ্ঞা সম্পর্কে আপনার সাথে একমত। এটি এসওসি লঙ্ঘন করে যা তত যুক্তিযুক্ত প্রোগ্রামিংয়ের অন্যতম প্রধান পাপ এবং এটি স্কেল না করার কারণগুলির মধ্যে সম্ভবত একটি।

— মার্কাস স্টেডে

Answer 7

এটি এনক্যাপসুলেশন লঙ্ঘন করে না। আপনি কোনও সহযোগী সরবরাহ করছেন তবে শ্রেণিটি কীভাবে এটি ব্যবহার করা হবে তা সিদ্ধান্ত নেবে। যতক্ষণ আপনি অনুসরণ করুন বলুন যতক্ষণ না সবকিছু ঠিক থাকে না ask আমি কনস্ট্রাক্টর ইনজেকশনকে পছন্দনীয় মনে করি তবে সেটারগুলি স্মার্ট হওয়ার সাথে সাথে সেগুলি ভাল হতে পারে fine এটি হ'ল ক্লাসের প্রতিনিধিত্বকারী আক্রমণকারীদের বজায় রাখতে তাদের যুক্তি রয়েছে।

Comments

কারণ ... তাই না? আপনার যদি একটি লগার থাকে এবং আপনার একটি ক্লাস থাকে যার জন্য লগার দরকার হয় the শ্রেণিতে লগারটি পাস করা এনক্যাপসুলেশন লঙ্ঘন করে না। এবং এটি সমস্ত নির্ভরতা ইনজেকশন হয়।

— jrockway

আমি মনে করি আপনি encapsulation ভুল বুঝে। উদাহরণস্বরূপ, একটি নিষ্পাপ তারিখের ক্লাস নিন। অভ্যন্তরীণভাবে এটিতে দিন, মাস এবং বছরের উদাহরণ ভেরিয়েবল থাকতে পারে। এগুলি যদি কোনও যুক্তিবিহীন সাধারণ সেটটার হিসাবে প্রকাশ করা হয় তবে এটি এনক্যাপসুলেশনটি ভেঙে দেবে, যেহেতু আমি নির্ধারিত মাস 2 থেকে দিন এবং 31 থেকে 31 করার মতো কিছু করতে পারি the অন্যদিকে, যদি সেটারগুলি স্মার্ট হয় এবং আক্রমণকারীদের পরীক্ষা করে, তবে জিনিসগুলি ঠিক আছে । এছাড়াও লক্ষ করুন যে পরবর্তী সংস্করণে, আমি স্টোরেজটি 1/1/1970 সাল থেকে কিছুদিনের মধ্যে পরিবর্তন করতে পারতাম এবং ইন্টারফেসটি ব্যবহার করে এমন কোনও কিছুইই এই বিষয়ে সচেতন হওয়ার প্রয়োজন ছিল না যদি আমি যথাযথভাবে দিন / মাস / বছরের পদ্ধতিগুলি পুনরায় লিখি।

— জেসন ওয়াটকিন্স

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

— রোগারিও

আমার কাছে একটি দৃ concrete় উদাহরণ রয়েছে যেখানে আমি মনে করি ডিআই দ্বারা এনক্যাপসুলেশন আপোস করা হয়েছে। আমার কাছে একটি FooProvider আছে যা ডিবি থেকে "foo ডেটা" পায় এবং একটি FooManager যা এটিকে ক্যাশে করে এবং সরবরাহকারীর উপরে স্টাফ গণনা করে। আমার কোডের গ্রাহকরা ভুল করে ডেটা পেতে ফোপ্রোভাইডারে যাচ্ছিলেন, যেখানে আমি বরং এটি সজ্জিত করে ফেলতাম যাতে তারা কেবলমাত্র ফু ম্যানেজার সম্পর্কে অবগত থাকে। এটি মূলত আমার মূল প্রশ্নের জন্য ট্রিগার।

— urig

@ রোজারিও: আমি যুক্তি দেব যে নির্মাতা পাবলিক ইন্টারফেসের অংশ নয় , কারণ এটি কেবলমাত্র রচনার রুটেই ব্যবহৃত হয়। সুতরাং, নির্ভরতা রচনা মূল দ্বারা কেবল "দেখা" হয়। কম্পোজিশনের মূলটির একক দায়িত্ব এই নির্ভরতাগুলি একসাথে তারের করা wire সুতরাং কনস্ট্রাক্টর ইঞ্জেকশন ব্যবহার করে কোনও এনক্যাপসুলেশন ভাঙবে না।

— জে সুলিভান

Answer 8

এটি উর্ধ্বমুখী উত্তরের অনুরূপ তবে আমি উচ্চস্বরে চিন্তা করতে চাই - সম্ভবত অন্যরাও বিষয়টিকে এইভাবে দেখেন।

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

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

তাত্ত্বিক উদাহরণ:

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

বলুন ফু এর এই বিশেষ প্রয়োগের কাজটি করার জন্য আইডাব্ল্যাজেটের দরকারও পড়তে পারে। এই নির্ভরতার কনস্ট্রাক্টর ইঞ্জেকশনটি আমাদের মতো একটি কনস্ট্রাক্টর তৈরি করতে চাইবে ফু এর (ইনট সাইজ, আই উইজেট উইজেট)

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

আকারের প্যারামিটার কোনও নির্ভরতা নয় - এটি প্রতি-প্রতিশির আরম্ভের মানটি সহজ। আইওসি বাহ্যিক নির্ভরতা (উইজেটের মতো) জন্য ড্যান্ডি তবে অভ্যন্তরীণ অবস্থার সূচনার জন্য নয়।

আরও খারাপ, উইজেটটি এই শ্রেণীর 4 টি পদ্ধতির মধ্যে কেবল 2 টির জন্য প্রয়োজনীয় যদি হয়; আমি উইজেটের জন্য ইনস্ট্যান্টেশন ওভারহেড বহন করতে পারে যদিও এটি ব্যবহৃত নাও হতে পারে!

এটি কীভাবে আপস / মিলন করবেন?

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

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

এই ডিআই বিশ্বে আমি গ্যারান্টেড ইনিশিয়েশন কীভাবে অর্জন করব, যখন ইনিশিয়েশন কেবলমাত্র বাহ্যিক নির্ভরতার চেয়ে বেশি?

Comments

আপডেট: আমি সবেমাত্র লক্ষ্য করেছি যে ইউনিটি ২.০ কনস্ট্রাক্টর প্যারামিটারগুলির (যেমন স্টেট ইনিশিয়ালাইজারদের) মান সরবরাহ করতে সমর্থন করে, যখন এখনও সমাধানের সময় () এর সময় নির্ভরতা আইওসি-র জন্য সাধারণ প্রক্রিয়া ব্যবহার করে। সম্ভবত অন্যান্য পাত্রেও কি এটি সমর্থন করে? যা এক কন্সট্রাক্টরে রাজ্য আর ডি এবং ডিআইয়ের মিশ্রণের প্রযুক্তিগত অসুবিধা সমাধান করে, তবে এটি এখনও এনক্যাপসুলেশন লঙ্ঘন করে!

— 5। 06

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

— urig

Answer 9

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

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

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

Answer 10

নির্ভরতা সত্যিকার অর্থে বাস্তবায়নের বিশদ বা ক্লায়েন্টটি কোনওভাবে বা অন্য কোনওভাবে জানতে বা প্রয়োজন জানতে চাইলে এটি নির্ভর করে। একটি বিষয় যা প্রাসঙ্গিক তা হল ক্লাসটি কী স্তরের বিমূর্ততা লক্ষ্য করে ing এখানে কিছু উদাহরন:

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

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

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

Answer 11

আমি সরলতায় বিশ্বাস করি। ডোমেন ক্লাসে আইওসি / ডিপেন্ডেসি ইনজেকশন প্রয়োগ করা কোনও সম্পর্ককে বর্ণনা করে এমন বাহ্যিক এক্সএমএল ফাইল রাখার মাধ্যমে কোডটিকে আরও বেশি শক্ত করে তোলা ছাড়া কোনও উন্নতি হয় না। EJB 1.0 / 2.0 এবং struts 1.1 এর মতো অনেক প্রযুক্তি এক্সএমএল-তে রাখা জিনিসগুলি হ্রাস করে বিপরীত হয়ে পড়েছে এবং এটিকে বিরক্তি হিসাবে কোডে রাখার চেষ্টা করছে So সুতরাং আপনার বিকাশকৃত সমস্ত শ্রেণীর জন্য আইওসি প্রয়োগ করা কোডটিকে অজ্ঞান করে তুলবে।

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

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

Answer 12

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

আমি যখন আমার পুরাতন একাত্তরের কুম্বি চালাচ্ছিলাম তখন আমি ত্বরণকারীটি টিপতে পারি এবং এটি (সামান্য) দ্রুত চলে যায়। কেন আমার জানা দরকার ছিল না, তবে কারখানায় কম্বি তৈরি করা ছেলেরা ঠিক কী কারণে তা জানত।

তবে কোডিংয়ে ফিরে আসুন। এনক্যাপসুলেশনটি "সেই বাস্তবায়নটি ব্যবহার করে কোনও কিছু থেকে প্রয়োগের বিশদটি গোপন করে।" এনক্যাপসুলেশন একটি ভাল জিনিস কারণ শ্রেণীর ব্যবহারকারী না জেনে বাস্তবায়নের বিশদ পরিবর্তন হতে পারে।

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

কন্সট্রাকটর যখন বর্গ প্রাথমিকভাবে তৈরি করা হচ্ছে প্রাসঙ্গিক। এটি আপনার ডিআই কন্টেইনার (বা কারখানা) সমস্ত পরিষেবা অবজেক্টগুলি একসাথে তারের তৈরি করার সময় নির্মাণের পর্যায়ে ঘটে happens ডিআই কনটেইনার কেবল প্রয়োগের বিশদ সম্পর্কে জানে। এটি বাস্তবায়ন সম্পর্কিত সমস্ত বিবরণ যেমন কুম্বি কারখানার ছেলেরা স্পার্ক প্লাগগুলি সম্পর্কে জানেন knows

রান-টাইমে, যে সার্ভিস অবজেক্টটি তৈরি হয়েছিল তাকে কিছু বাস্তব কাজ করার জন্য অ্যাপন বলা হয়। এই মুহুর্তে, অবজেক্টের কলার বাস্তবায়ন বিশদগুলির কিছুই জানে না।

এটাই আমার কোম্বিকে সৈকতে চালাচ্ছে।

এখন, encapsulation ফিরে। যদি বাস্তবায়নের বিশদ পরিবর্তন হয়, তবে রান-টাইমে সেই প্রয়োগটি ব্যবহার করে ক্লাস পরিবর্তন করার দরকার নেই। এনক্যাপসুলেশন ভাঙা হয় না।

আমি আমার নতুন গাড়িটি সৈকতেও চালাতে পারি। এনক্যাপসুলেশন ভাঙা হয় না।

যদি প্রয়োগের বিশদ পরিবর্তন হয় তবে ডিআই কনটেইনার (বা কারখানা) পরিবর্তন করা দরকার। আপনি কারখানার কাছ থেকে প্রয়োগের বিশদটি প্রথম স্থানে আড়াল করার চেষ্টা করছিলেন না।

Comments

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

— রডরিগো রুইজ

Answer 13

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

ডিআই কেন এনক্যাপসুলেশন লঙ্ঘন করে তার ক্ষেত্রে বিষয়টি পরিষ্কার হয়ে যায় যখন আপনি যে উপাদানটিতে কাজ করছেন তা কোনও "বাহ্যিক" পক্ষের কাছে সরবরাহ করা হবে (গ্রাহকের জন্য একটি গ্রন্থাগার লেখার কথা ভাবেন)।

যখন আমার উপাদানটির জন্য উপ-উপাদানগুলি কনস্ট্রাক্টর (বা সর্বজনীন সম্পত্তি) এর মাধ্যমে ইনজেকশনের প্রয়োজন হয় তখন এর কোনও গ্যারান্টি নেই

"ব্যবহারকারীকে উপাদানটির অভ্যন্তরীণ ডেটাটিকে একটি অবৈধ বা বেমানান অবস্থায় সেট করতে বাধা দিচ্ছে"।

একই সাথে এটিও বলা যায় না

"উপাদানটির (সফ্টওয়্যারটির অন্যান্য অংশ) ব্যবহারকারীদের কেবল উপাদানটি কী করে তা জানতে হবে এবং এটি কীভাবে এটি করে তার বিশদটির উপর নিজেকে নির্ভর করতে পারে না" ।

উভয় উদ্ধৃতি উইকিপিডিয়া থেকে ।

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

সাধারণত আমি সমস্ত ডিআই এর জন্য আছি। এই বিশেষ (চরম) উদাহরণে, এটি আমাকে বিপজ্জনক হিসাবে আঘাত করে।

Answer 14

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

ডিআই-র অ্যাডভোকেটরা যুক্তি দেখান যে কোনও বস্তুর নতুন অপারেটর ব্যবহার করা উচিত নয়। এই "পিউরিস্ট" পদ্ধতিটি কেবল এনক্যাপসুলেশনকে লঙ্ঘন করে না তবে যে কেউ বস্তুটি তৈরি করছে তার পক্ষে লিসকো সাবস্টিটিউশন নীতিও লঙ্ঘন করে।

Answer 15

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

বাস্তবে এটি আরও উন্নত হয় - কারখানা এবং সংগ্রহস্থলগুলিতে ফোকাস করে আমাকে ডিআই তে জড়িত তাও জানতে হবে না! এটি আমার কাছে encাকনাটি এনক্যাপসুলেশনে ফিরিয়ে দেয়। রক্ষে!

Comments

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

— urig

Answer 16

পুনশ্চ. প্রদান করার মাধ্যমে নির্ভরতা ইনজেকশন আপনি অগত্যা না বিরতি encapsulation । উদাহরণ:

obj.inject_dependency(  factory.get_instance_of_unknown_class(x)  );

ক্লায়েন্ট কোডটি এখনও বাস্তবায়ন বিশদ জানে না।

Comments

আপনার উদাহরণে কীভাবে কোনও ইঞ্জেকশন দেওয়া হয়? (আপনার সেটার ফাংশনের নামকরণ ছাড়া)

— foo বিন্যাস

Answer 17

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

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

Comments

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

— foo বিন্যাস

Answer 18

আমি মনে করি এটি স্বতঃস্ফূর্ত যে খুব কমপক্ষে ডিআই খুব ভালভাবে এনক্যাপসুলেশনকে দুর্বল করে ens অতিরিক্ত হিসাবে ডিআইয়ের আরও কিছু ডাউনসাইডগুলি বিবেচনা করতে হবে।

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

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

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

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

যেখানে নির্ভরতা প্রকৃতপক্ষে বাহ্যিকভাবে সরবরাহ করা প্রয়োজন, সেখানে সাধারণত পরামর্শ দেয় যে বস্তুর মধ্যে সম্পর্কটি একটি অভ্যন্তরীণ নির্ভরতার পরিবর্তে একটি সহযোগিতা, যার ক্ষেত্রে যথাযথ লক্ষ্যটি তখন এনক্যাপসুলেশন হয় অন্য শ্রেণীর অভ্যন্তরের এক শ্রেণির সজ্জিতকরণের পরিবর্তে প্রতিটি শ্রেণির ।

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

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

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

Answer 19

আমি সম্মত হই যে চূড়ান্তভাবে নেওয়া, ডিআই encapsulation লঙ্ঘন করতে পারে। সাধারণত ডিআই নির্ভরতা প্রকাশ করে যা সত্যই কখনই আবৃত ছিল না। মিকো হেভেরির সিঙ্গলটনের কাছ থেকে নেওয়া একটি সরল উদাহরণ এখানে প্যাথোলজিকাল লায়ার্স :

আপনি ক্রেডিটকার্ড পরীক্ষা দিয়ে শুরু করেন এবং একটি সাধারণ ইউনিট পরীক্ষা লেখেন।

@Test
public void creditCard_Charge()
{
    CreditCard c = new CreditCard("1234 5678 9012 3456", 5, 2008);
    c.charge(100);
}

পরের মাসে আপনি 100 ডলারে একটি বিল পান। আপনি কেন চার্জ নিলেন? ইউনিট পরীক্ষা একটি উত্পাদন ডাটাবেস প্রভাবিত। অভ্যন্তরীণভাবে, ক্রেডিটকার্ড কল করে Database.getInstance()। রিফ্যাক্টরিং ক্রেডিটকার্ড যাতে DatabaseInterfaceএটির একটি নির্মাণকারী গ্রহণ করে তা নির্ভর করে যে সত্যতা প্রকাশ করে। তবে আমি যুক্তি দিয়ে বলব যে নির্ভরতা কখনই শুরু হয় না কারণ ক্রেডিটকার্ড শ্রেণীর বাহ্যিকভাবে দৃশ্যমান পার্শ্ব প্রতিক্রিয়া ঘটে। আপনি যদি রিফ্যাক্টরিং ছাড়াই ক্রেডিটকার্ড পরীক্ষা করতে চান, আপনি অবশ্যই নির্ভরতা পর্যবেক্ষণ করতে পারেন।

@Before
public void setUp()
{
    Database.setInstance(new MockDatabase());
}

@After
public void tearDown()
{
    Database.resetInstance();
}

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

Comments

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

— kizzx2

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

— ক্রেগ পি। মোটলিন

@ ক্রেইগ পি। মোটলিন কীভাবে CreditCardকোনও ওয়েবএপিআই থেকে পেপ্যাল-এ পরিবর্তন করতে পারে, ক্লাসের বাহ্যিক কিছু বাদ না দিয়ে পরিবর্তন করতে পারে?

— আয়ান

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

— ক্রেগ পি। মোটলিন

@ kizzx2 অন্য কথায়, ক্রেডিট কার্ডের পেপাল ব্যবহার করা উচিত বলে আজেবাজে কথা। তারা বাস্তব জীবনে বিকল্প।

— ক্রেগ পি। মোটলিন

Answer 20

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

1. শ্রেণি যেমন : আপনি যেটি encapsulating করছেন তা হচ্ছে শ্রেণীর একমাত্র দায়বদ্ধতা। এটি কীভাবে করতে হয় তা জানে। উদাহরণস্বরূপ, বাছাই করা। যদি আপনি অর্ডার দেওয়ার জন্য কোনও তুলনাকারী ইনজেক্ট করেন তবে আসুন, ক্লায়েন্টরা, এটি এনক্যাপসুলড জিনিসটির অংশ নয়: কুইকোর্ট ort

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

আপনি যখন ক্লাসিং প্রোগ্রামিং করছেন, এটি হ'ল ক্লাসে একক দায়িত্ব প্রয়োগ করে, আপনি বিকল্প 1 ব্যবহার করছেন।

আপনি যখন অ্যাপ্লিকেশন প্রোগ্রামিং করছেন, এটি এমন কিছু তৈরি যা কিছু কার্যকর কংক্রিট কাজ শুরু করে তখন আপনি পুনরাবৃত্তি সহ বিকল্প 2 ব্যবহার করছেন।

এটি কনফিগার করা উদাহরণটির বাস্তবায়ন:

<bean id="clientSorter" class="QuickSort">
   <property name="comparator">
      <bean class="ClientComparator"/>
   </property>
</bean>

এটি অন্য কোনও ক্লায়েন্ট কোড এটি ব্যবহার করে:

<bean id="clientService" class"...">
   <property name="sorter" ref="clientSorter"/>
</bean>

এটি এনক্যাপসুলেটেড কারণ আপনি যদি প্রয়োগটি পরিবর্তন করেন (আপনি clientSorterশিমের সংজ্ঞা পরিবর্তন করেন) এটি ক্লায়েন্টের ব্যবহার ভঙ্গ করে না। হতে পারে, আপনি যেমন একসাথে লিখিত সমস্ত xML ফাইল ব্যবহার করেন আপনি সমস্ত বিবরণটি দেখছেন। তবে বিশ্বাস করুন, ক্লায়েন্ট কোড ( ClientService) এর বাছাইকারী সম্পর্কে কিছুই জানে না।

Answer 21

এটি সম্ভবত উল্লেখযোগ্য যে Encapsulationএটি কিছুটা নির্ভরশীল।

public class A { 
    private B b;

    public A() {
        this.b = new B();
    }
}


public class A { 
    private B b;

    public A(B b) {
        this.b = b;
    }
}

Aক্লাসে কারও কাজ করা দৃষ্টিকোণ থেকে দ্বিতীয় উদাহরণে A এর প্রকৃতি সম্পর্কে অনেক কম জানেthis.b

যেখানে ডিআই ছাড়াই

new A()

বনাম

new A(new B())

এই কোডটির দিকে তাকানো ব্যক্তি এর প্রকৃতি সম্পর্কে আরও জানেন A দ্বিতীয় উদাহরণে ।

ডিআই সহ, কমপক্ষে সমস্ত ফাঁস হওয়া জ্ঞান এক জায়গায়।