ইন্টারফেস ব্যবহার না করা কি খারাপ অভ্যাস? [বন্ধ]


40

আমি ইন্টারফেসগুলি খুব কমই ব্যবহার করি এবং এগুলি অন্যের কোডে সাধারণ দেখতে পাই।

এছাড়াও আমি সাব এবং সুপার ক্লাস তৈরি করি (নিজের ক্লাস তৈরি করার সময়) আমার কোডে খুব কমই।

  • এটি একটি খারাপ জিনিস?
  • আপনি এই স্টাইল পরিবর্তন করার পরামর্শ দিতে চান?
  • এই স্টাইলের কোনও পার্শ্ব প্রতিক্রিয়া আছে কি?
  • এটি কি কারণ আমি কোনও বড় প্রকল্পে কাজ করি নি?

10
এটা কোন ভাষা?

2
কোন ভাষা ছাড়াও এটি কী দৃষ্টান্ত?
আরমান্ডো

1
"ইন্টারফেস" ভাষাটি কী অতিক্রম করে? জাভা অন্তর্নির্মিত ইন্টারফেস টাইপ আছে, কিন্তু সি ++ বিকাশকারীরা প্রায়শই খুব ইন্টারফেস তৈরি করে (I এর সাথে পূর্ববর্তী করে) এবং তারা সকলেই একই উদ্দেশ্যে কাজ করে।
রিকিট

4
@ রিকিট: না, সত্যই নয়। সমস্যাটি হ'ল সি ++ একাধিক শ্রেণীর উত্তরাধিকার দেয়। সি ++ তে একটি "ইন্টারফেস" অনেক বেশি ধারণাগত এবং বাস্তবে আমরা বেশিরভাগই তারা বিমূর্ত বেস শ্রেণি হিসাবে সংজ্ঞায়িত করব তা ব্যবহার করি # #
ডেড এমএমজি

2
@ রিকিট নং, বিশেষত যদি আপনি পদ্ধতিগত বা ওওপি-র পরিবর্তে কার্যকরী ভাষায় কাজ করছেন।
বিকল্প

উত্তর:


36

আপনি ইন্টারফেস ব্যবহার করতে পারেন এমন বিভিন্ন কারণ রয়েছে:

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

http://msdn.microsoft.com/en-us/library/3b5b8ezk(v=vs.80).aspx

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


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

2
এই উত্তরটি C # বলে মনে হচ্ছে তবে আপনি জাভাটি সম্পর্কিতও যদি আপনি # 4 বের করেন তবে কেবলমাত্র C ++ এ প্রকার প্রযোজ্য কারণ অবশ্যই C ++ এ একাধিক উত্তরাধিকার অনুমোদিত allowed
রিকিট

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

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

17

উভয় শ্রেণীর উত্তরাধিকার এবং ইন্টারফেস উভয়েরই তাদের স্থান রয়েছে। উত্তরাধিকার অর্থ "একটি" যখন একটি ইন্টারফেস এমন একটি চুক্তি সরবরাহ করে যা "কিছু" কেমন আচরণ করে "তা সংজ্ঞায়িত করে।

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

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

বিল ওয়াগনার্স বইয়ের কয়েকটা উদ্ধৃতি ...

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

"কোডিং ইন্টারফেসগুলি অন্যান্য বিকাশকারীদের বেস বর্গের ধরণের কোডিংয়ের চেয়ে আরও নমনীয়তা সরবরাহ করে।"

"কোনও শ্রেণীর জন্য API গুলি সংজ্ঞায়িত করতে ইন্টারফেস ব্যবহার করা আরও নমনীয়তা সরবরাহ করে।"

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

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


2
ঠিক আছে, আমি এটি পড়েছি এবং ভেবেছিলাম এটি একটি ভাল উত্তর।
এরিক কিং

1
@ এমসি 10 সমস্যা কী তা নিশ্চিত নয়। তিনি একটি বই উল্লেখ করেছেন এবং তার উত্তরের নীচের অর্ধেকটি কেবলমাত্র সেই বইয়ের উদ্ধৃতি যা তিনি আপনার সময় নষ্ট করতে না চান সে ক্ষেত্রে তিনি আপনাকে পরিষ্কারভাবে জানাতে পারেন।
পিট

@ পেট আমি বলিনি যে উত্তরটি খারাপ, তবে কেবল এটি কিছুটা দীর্ঘ ছিল। আমি সন্দেহ করি যে আপনার মাঝে মাঝে মাঝে পুরো উক্তিটি প্রয়োজন ছিল।
কেভিনজি

3
হাহা, যদি এটি টিএল; ডাঃ, আমি নিশ্চিত না আপনি এই পুরো স্ট্যাকএক্সচেঞ্জ-উচ্চ-মানের-উত্তর জিনিসটি পছন্দ করতে চলেছেন।
নিক

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

8

একটা জিনিষ যে উল্লেখ করা হয় নি পরীক্ষা করছে: সব C # এর বিদ্রূপকারী-গ্রন্থাগারে, পাশাপাশি জাভা জন্য কিছু যেমন, ক্লাস করতে পারবে না যদি না তারা একটি ইন্টারফেস বাস্তবায়ন ব্যঙ্গ করা হবে। এটি প্রতিটি শ্রেণিকে তার নিজস্ব ইন্টারফেস দেওয়ার জন্য Agile / TDD অনুশীলন অনুসরণ করে অনেক প্রকল্পের নেতৃত্ব দেয় ।

কিছু লোক এই সর্বোত্তম অনুশীলনটিকে বিবেচনা করে, কারণ এটি "সংযুক্তিকে হ্রাস করে", তবে আমি একমত নই - আমি মনে করি এটি ভাষার অভাবের পক্ষে কেবল একটি কাজ।


আমার মনে হয় আপনি যখন দুটি বা ততোধিক ক্লাস রাখেন তখন ইন্টারফেসগুলি সর্বোত্তমভাবে ব্যবহৃত হয় যা বিমূর্তভাবে "একই জিনিস" করে তবে বিভিন্ন উপায়ে।

উদাহরণস্বরূপ, .NET Framework যে দোকান তালিকা একাধিক শ্রেণীর হয়েছে কাপড় , কিন্তু তারা সব দোকান যে বিভিন্ন উপায়ে স্টাফ। সুতরাং, এটি একটি বিমূর্ত IList<T>ইন্টারফেস আছে, যা বিভিন্ন পদ্ধতি ব্যবহার করে প্রয়োগ করা যেতে পারে বোঝা তোলে ।

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


5

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


4

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

সমস্যাটি হ'ল দুর্বল সংকলন-সময় জেনেরিকগুলির সাথে সি # এবং জাভার মতো ভাষায় আপনি ডিআরওয়াই লঙ্ঘন করতে পারেন কারণ এমন একটি পদ্ধতি লেখার উপায় নেই যা সমস্ত বর্গ একই ভিত্তির উত্তরাধিকারী না হলে একাধিক শ্রেণীর সাথে কাজ করতে পারে। যদিও সি # 4 এর সাথে এটি মোকাবেলা dynamic করতে পারে

জিনিসটি হ'ল উত্তরাধিকার বৈশ্বিক চলকের মতো is একবার আপনি এটি যুক্ত করেন এবং আপনার কোড এটির উপর নির্ভর করে Godশ্বর আপনাকে এটিকে দূরে সরিয়ে নিতে সহায়তা করেন। তবে আপনি যে কোনও সময় এটি যুক্ত করতে পারেন এবং আপনি এমনকি কোনও ধরণের মোড়ক ব্যবহার করে বেস শ্রেণিটি পরিবর্তন না করে এটি যুক্ত করতে পারেন।


1
ডাউনভোটের কারণ?
ডেডজিমি

নিশ্চিত নয়, একটি উত্তোলন আছে। এটি একটি ভাল উত্তর ছিল।
ব্রায়ান বোয়েচার

3

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


3

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

সুতরাং, সত্যিই, আপনার প্রশ্নটি দৃষ্টান্ত-নির্ভর (এই ক্ষেত্রে ওওপি) এবং আরও, সত্যিই বেশ ভাষা-নির্ভর (ইন্টারফেস ছাড়া ওওপি ভাষা রয়েছে)।


2

আপনি যদি জাভা ব্যবহারের কথা বলছেন, ইন্টারফেসগুলি ব্যবহারের একটি কারণ হ'ল তারা কোড উত্পন্ন লাইব্রেরি ছাড়াই প্রক্সি অবজেক্টের ব্যবহার সক্ষম করে। আপনি যখন স্প্রিংয়ের মতো জটিল কাঠামো নিয়ে কাজ করছেন তখন এটি যথেষ্ট সুবিধা হতে পারে। তদুপরি, কিছু কার্যকারিতার ইন্টারফেসের প্রয়োজন : আরএমআই এটির সর্বোত্তম উদাহরণ, কারণ আপনি ইন্টারফেসের ক্ষেত্রে যে কার্যকারিতা সরবরাহ করছেন (যা উত্তরাধিকার সূত্রে প্রাপ্ত হয় java.rmi.Remote) তবে আপনি সেগুলি প্রয়োগ করতে যাচ্ছেন।


1

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

আইএমও আপনার কেবল ইন্টারফেসের সাথে কাজ করা উচিত, বা যেখানেই সম্ভব পুরোপুরি বোবা ডিএও'র সাথে কাজ করা উচিত। একবার আপনি এই মানসিকতায় getুকে পড়লে এবং আপনি এমন একটি লাইব্রেরি ব্যবহার শুরু করেন যা ইন্টারফেসের মাধ্যমে নিজেকে প্রকাশ করে না এবং কংক্রিটের মাধ্যমে সমস্ত কিছু করে যা আমি সৎ হতে পারি, এটি সমস্ত কিছুটা বিশৃঙ্খল বোধ করে।


0

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

খারাপ:

class B; // forward declaration
class A
{
  B* b;
};

class B
{
  A* a;
}

খারাপ না:

class PartOfClassB_AccessedByA
{
};

class A
{
  PartOfClassB_AccessedByA* b;
};

class B : public PartOfClassB_AccessedByA
{
  A* a;
}

সাধারণত A, B, PartOfClassB_AcecessedByA পৃথক ফাইল সহ প্রয়োগ করা হয়।


0

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

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.