ইন্টারফেস বিভাজন মূলনীতিটির দুটি বিপরীত সংজ্ঞা - কোনটি সঠিক?


14

আইএসপি-তে নিবন্ধগুলি পড়ার সময় মনে হয় আইএসপির দুটি বিপরীত সংজ্ঞা রয়েছে:

প্রথম সংজ্ঞা অনুসারে (দেখুন 1 , 2 , 3 ), আইএসপি বলেছে যে ইন্টারফেস প্রয়োগকারী ক্লাসগুলিকে তাদের প্রয়োজন হয় না এমন ক্রিয়াকলাপগুলি প্রয়োগ করতে বাধ্য করা উচিত নয়। সুতরাং, ফ্যাট ইন্টারফেসIFat

interface IFat
{
     void A();
     void B();
     void C();
     void D();
}

class MyClass: IFat
{ ... }

ছোট ইন্টারফেসে বিভক্ত করা উচিত ISmall_1এবংISmall_2

interface ISmall_1
{
     void A();
     void B();
}

interface ISmall_2
{
     void C();
     void D();
}

class MyClass:ISmall_2
{ ... }

এই ভাবে যেহেতু আমার MyClassশুধুমাত্র পদ্ধতি দরকার (বাস্তবায়ন করতে সক্ষম হয় D()এবং C()বাধ্য হচ্ছে এছাড়াও ডামি বাস্তবায়নের প্রদান ছাড়া,) A(), B()এবং C():

তবে দ্বিতীয় সংজ্ঞা অনুযায়ী (দেখুন 1 , 2 , নাজার মেরজার উত্তর ), আইএসপি বলেছে যে MyClientকল করার MyServiceপদ্ধতিগুলির MyServiceযে পদ্ধতিগুলির প্রয়োজন নেই সে সম্পর্কে সচেতন হওয়া উচিত নয় । অন্য কথায়, যদি MyClientশুধুমাত্র কার্যকারিতা প্রয়োজন C()এবং D()তারপর, পরিবর্তে

class MyService 
{
    public void A();
    public void B();
    public void C();
    public void D();
}

/*client code*/      
MyService service = ...;
service.C(); 
service.D();

আমাদের ক্লায়েন্ট-নির্দিষ্ট ইন্টারফেসগুলিতে পৃথক MyService'sপদ্ধতিগুলি করা উচিত :

public interface ISmall_1
{
     void A();
     void B();
}

public interface ISmall_2
{
     void C();
     void D();
}

class MyService:ISmall_1, ISmall_2 
{ ... }

/*client code*/
ISmall_2 service = ...;
service.C(); 
service.D();

এইভাবে পূর্বের সংজ্ঞা সহ, আইএসপিটির লক্ষ্য হ'ল " আইএফএটি ইন্টারফেস প্রয়োগকারী শ্রেণীর জীবনকে সহজ করে তোলা ", তবে পরবর্তীকালের সাথে আইএসপি'র লক্ষ্য হল " মাই সার্ভিসের কলিংয়ের ক্লায়েন্টদের জীবনকে সহজ করা "।

আইএসপি-র দুটি ভিন্ন সংজ্ঞা আসলে কোনটি সঠিক?

@ মারজান ভেনেমা

1।

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

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

সুতরাং, যদি সেখানে প্রচুর ক্লায়েন্ট ছিল যা কেবল কখনও কল করার প্রয়োজন হত CutGreens, তবে এটিও নয় GrillMeat, তবে আইএসপি প্যাটার্নটি মেনে চলার জন্য কেবল আমাদের CutGreensভিতরে shouldোকানো উচিত ICook, তবে তাও নয় GrillMeat, যদিও দুটি পদ্ধতি অত্যন্ত সংহত রয়েছে ?!

2।

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

"এসআরপি অনুসরণ করে না এমন ক্লাসগুলি প্রয়োগ করে" আপনি কি সেই ক্লাসগুলিকে উল্লেখ করছেন যা প্রয়োগ করে IFatবা ক্লাসগুলি প্রয়োগ করে ISmall_1/ ISmall_2? আমি ধরে নিয়েছি আপনি যে ক্লাসগুলি প্রয়োগ করছেন তা উল্লেখ করছেন IFat? যদি তা হয় তবে আপনি কেন ধরে নিচ্ছেন যে তারা ইতিমধ্যে এসআরপি অনুসরণ করে না?

ধন্যবাদ


4
কেন একাধিক সংজ্ঞা থাকতে পারে না যে উভয়ই একই নীতি দ্বারা পরিবেশন করা হয়?
ববসন

5
এই সংজ্ঞাগুলি একে অপরের বিরোধিতা করে না।
মাইক পার্টরিজ

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

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

2
কীভাবে ক্লায়েন্টের অস্তিত্ব থাকবে এবং তাদের কী কী পদ্ধতির প্রয়োজন হবে তা আপনি কীভাবে আগেই জানবেন? আপনি পারবেন না। হাতের আগে আপনি যা জানতে পারবেন তা হ'ল আপনার ইন্টারফেসটি কতটা সম্মিলিত।
তুলাইনস কর্ডোভা

উত্তর:


6

দুটোই সঠিক

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

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

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

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

আমার কাছে দ্বিতীয় সংজ্ঞাটি, ইন্টারফেসের কলার হিসাবে ক্লায়েন্টদের সাথে, লক্ষ্য অর্জনের আরও ভাল উপায়।

Segregating

আপনার প্রশ্নে আপনি বলেছেন:

যেহেতু আমার মাই ক্লাস এ (), বি () এবং সি () এর জন্য ডামি বাস্তবায়ন করতে বাধ্য করা ছাড়া কেবল তার প্রয়োজনীয় পদ্ধতিগুলি (ডি () এবং সি ()) প্রয়োগ করতে সক্ষম হয়েছে:

তবে তা বিশ্বকে উল্টে দিচ্ছে।

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

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

এই ইন্টারফেস বিবেচনা করুন:

interface IEverythingButTheKitchenSink
{
     void DoDishes();
     void CleanSink();
     void CutGreens();
     void GrillMeat();
}

আপনি কোন পদ্ধতিতে রাখবেন ICookএবং কেন? আপনি কি এমন CleanSinkএকসাথে রেখে GrillMeatযাবেন যে আপনার ক্লাসটি ঘটে যা ঠিক যে দুটি কাজ করে এবং অন্যান্য পদ্ধতির মতো কিছুই না? অথবা আপনি এটিকে আরও দুটি সমন্বিত ইন্টারফেসে ভাগ করবেন যেমন:

interface IClean
{
     void DoDishes();
     void CleanSink();
}

interface ICook
{
     void CutGreens();
     void GrillMeat();
}

ইন্টারফেস ঘোষণা নোট

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


1
আমার করা আপডেটটি কি আপনি দেখতে পাচ্ছেন?
এডভ্রুজ

"কলকারী প্রয়োগকারীটির উপর তাত্ক্ষণিক নির্ভরতা পায় " ... কেবলমাত্র যদি আপনি ডিআইপি (নির্ভরতা বিপরীত নীতি) লঙ্ঘন করেন, যদি কলার অভ্যন্তরীণ ভেরিয়েবল, প্যারামিটার, রিটার্ন মানগুলি ইত্যাদি টাইপের ICookপরিবর্তে SomeCookImplementorডিআইপি ম্যান্ডেট থাকে তবে তা তা করবে না নির্ভর করতে হবে না SomeCookImplementor
তুলাইনস কর্ডোভা

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

আমি এই কোড প্রোগ্রামারগুলিতে আপনার কোড উদাহরণগুলি পুনরায় ব্যবহার করেছি ststackexchange.com/a/271142/61852 , এটি ইতিমধ্যে স্বীকৃত হওয়ার পরে এটি উন্নত করে। উদাহরণগুলির জন্য আমি আপনাকে যথাযথ creditণ দিয়েছি।
তুলিনাস কর্ডোভা

শীতল @ ব্যবহারকারী61852 :) (এবং কৃতিত্বের জন্য ধন্যবাদ)
মার্জন ভেনেমা

14

গ্যাং অফ ফোর নথিগুলিতে কোনও পরিষেবার গ্রাহক হিসাবে "ক্লায়েন্ট" হিসাবে ব্যবহৃত হিসাবে আপনি "ক্লায়েন্ট" শব্দটি বিভ্রান্ত করেন।

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

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

নীতিটির চেতনাটি হল "ক্লায়েন্ট" (ইন্টারফেস বাস্তবায়নকারী শ্রেণি) পুরো ইন্টারফেসটি মেনে চলার জন্য ডামি পদ্ধতিগুলি প্রয়োগ করতে হবে যখন এটি কেবলমাত্র সম্পর্কিত পদ্ধতির একটি সেট সম্পর্কে চিন্তা করে।

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

ইন্টারফেসটি যখন খুব বেশি করে এবং কেবল একটির পরিবর্তে কয়েকটি ইন্টারফেসে বিভক্ত হওয়া এমন পদ্ধতি থাকে তখন সমস্যাগুলি দেখা দেয়।

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

আপনার দেওয়া তিনটি লিঙ্কে বর্ণিত ধারণাগুলিতে আমি কোনও বৈপরীত্য খুঁজে পাই না।

সলড আলোচনায় কেবল "ক্লায়েন্ট" বাস্তবায়নকারী তা পরিষ্কার রাখুন ।


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

1
@ এডভ্রুজজ আমার উত্তরটি অবজেক্ট মেন্টর (বব মার্টিন এন্টারপ্রাইজ) ওয়েবসাইটে থাকা নথির উপর ভিত্তি করে, মার্টিন নিজেই লিখেছিলেন যখন তিনি বিখ্যাত গ্যাং অফ ফোরে ছিলেন। আপনি জানেন যে চারটি গানাগ ছিলেন মার্টিন সহ একটি সফটওয়্যার ইঞ্জিনিয়ার, যা নলগুলি সংজ্ঞায়িত করে, নীতিগুলি চিহ্নিত করে এবং নথিভুক্ত করে। docs.google.com/a/cleancoder.com/file/d/…
তুলিনাস কর্ডোভা

সুতরাং আপনি @ পিডিআর এর সাথে একমত নন এবং সুতরাং আপনি আইএসপির প্রথম সংজ্ঞাটি (আমার মূল পোস্টটি দেখুন) আরও সম্মত হন?
এডভ্রুজ

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

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

5

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

প্রথম সংজ্ঞাটি আরও বেশি শক্তভাবে এলএসপির সাথে যুক্ত linked


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

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

1
@ এডভ্রুজ: আপনি যদি এখানে আপনার ইন্টারফেসের সংজ্ঞাটি পুনর্বিবেচনা করেন তবে এটি সাহায্য করতে পারে। এটি সর্বদা সি # / জাভা পদগুলিতে কোনও ইন্টারফেস নয়। আপনার চারপাশে বেশ কয়েকটি সাধারণ ক্লাসগুলি মোড়ানো একটি জটিল পরিষেবা থাকতে পারে যেমন ক্লায়েন্ট এ সার্ভিস এক্সের সাথে "ইন্টারফেস" করতে র‌্যাপার ক্লাস এএক্স ব্যবহার করে Thus সুতরাং, আপনি যখন এক্স এবং এএক্সকে প্রভাবিত করে এমনভাবে এক্স পরিবর্তন করেন, আপনি নন বিএক্স এবং বি প্রভাবিত করতে বাধ্য
পিডিআর

1
@ এডভিউরুজ: এটি বলা আরও সঠিক হবে যে তারা এবং এক্স উভয়ই এক্স কল করছে বা একজন ওয়াই এবং অন্য জেডকে কল করছে care এটি আইএসপির মূল বিষয় if সুতরাং আপনি কোন প্রয়োগের জন্য যাচ্ছেন তা চয়ন করতে পারেন এবং সহজেই আপনার মনটি পরে পরিবর্তন করতে পারেন। আইএসপি একটি রুট বা অন্যটির পক্ষে নয়, তবে এলএসপি এবং এসআরপি সম্ভবত।
পিডিআর

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