বেস ক্লাস হিসাবে একই ফাইলে ইন্টারফেস ঘোষণা, এটি কি একটি ভাল অনুশীলন?


29

বিনিময়যোগ্য এবং টেস্টেবল হওয়ার জন্য, সাধারণত যুক্তির সাথে পরিষেবাদির ইন্টারফেস থাকা প্রয়োজন, যেমন

public class FooService: IFooService 
{ ... }

নকশাকৃত, আমি এটির সাথে একমত, তবে এই পদ্ধতির সাথে আমাকে যে বিষয়গুলি বিরক্ত করে তার মধ্যে একটি হ'ল একটি পরিষেবার জন্য আপনাকে দুটি জিনিস (শ্রেণি এবং ইন্টারফেস) ঘোষণা করতে হবে এবং আমাদের দলে সাধারণত দুটি ফাইল (একটি ক্লাসের জন্য এবং ইন্টারফেসের জন্য একটি)। আর একটি অস্বস্তি নেভিগেশন অসুবিধা কারণ আইডিই (ভিএস 2010) এ "Go to সংজ্ঞা" ব্যবহার করা ইন্টারফেসের দিকে নির্দেশ করবে (যেহেতু অন্যান্য ক্লাসগুলি ইন্টারফেসকে নির্দেশ করে), আসল শ্রেণি নয়।

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


3
যদি আপনার কেবলমাত্র একটি নির্দিষ্ট ইন্টারফেসের একটি প্রয়োগ থাকে তবে ইন্টারফেসের জন্য কোনও আসল যৌক্তিক প্রয়োজন নেই। ক্লাস সরাসরি ব্যবহার করবেন না কেন?
জোরিস টিমারম্যানস

11
আলগা দম্পতি এবং পরীক্ষাযোগ্যতার জন্য @ ম্যাডকিথভি?
লুই রাইস

10
@ ম্যাডকিথভি: আপনি সঠিক বলেছেন। কিন্তু আপনি যখন কোডটি IFooService উপর নির্ভর জন্য ইউনিট পরীক্ষা লিখুন, আপনি সাধারণত একটি MockFooService, যা প্রদান করবে হয় যে ইন্টারফেস একটি দ্বিতীয় বাস্তবায়ন।
ডক ব্রাউন

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

1
স্থূল স্ব-বিজ্ঞাপন: stackoverflow.com/questions/5840219/...
Marjan Venema

উত্তর:


24

এটি নিজস্ব ফাইলে থাকতে হবে না, তবে আপনার দলের উচিত একটি মানদণ্ডের সিদ্ধান্ত নেওয়া এবং এটি বদ্ধ হওয়া।

এছাড়াও, আপনি ঠিক বলেছেন যে "Go to সংজ্ঞা" আপনাকে ইন্টারফেসে নিয়ে যায়, তবে আপনি যদি রিশার্পার ইনস্টল করে থাকেন তবে সেই ইন্টারফেস থেকে উত্পন্ন ক্লাস / ইন্টারফেসের একটি তালিকা খোলার জন্য এটি কেবলমাত্র একটি ক্লিক হয়, সুতরাং এটি কোনও বড় বিষয় নয়। এজন্য আমি ইন্টারফেসটি একটি পৃথক ফাইলে রাখি।

 


5
আমি এই উত্তরের সাথে একমত, সমস্ত আইডিই আমাদের ডিজাইনের সাথে সামঞ্জস্য করা উচিত এবং অন্য উপায়ে নয়, তাই না?
মার্কতানি

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

@ ড্যানিয়েলবি: রিশার্পারে, অল্ট-এন্ড বাস্তবায়নে যায় (বা আপনাকে যেতে সম্ভাব্য বাস্তবায়নের একটি তালিকা উপহার দেয়)।
স্ট্রিপলিং ওয়ারিয়র

@ স্ট্রিপলিং ওয়ারিয়র তখন মনে হয় এটি ভ্যানিলা ভিএসও ঠিক ঠিক তাই করে। এফ 12 = সংজ্ঞায় যান, শিফট + এফ 12 = বাস্তবায়নে যান (আমি দৃ sure়ভাবে নিশ্চিত যে এটি পুনরায় ভাগ ছাড়াই এটি কাজ করে, যদিও আমার এটি ইনস্টল করা আছে, তাই এটি নিশ্চিত করা শক্ত)। এটি সবচেয়ে দরকারী নেভিগেশন শর্টকাটগুলির মধ্যে একটি, আমি কেবল শব্দটি ছড়িয়ে দিচ্ছি।
ড্যানিয়েল বি

@ ড্যানিয়েলবি: শিফট-এফ 12 এর ডিফল্ট হ'ল "ব্যবহারগুলি সন্ধান করুন।" jetbrains.com/resharper/webhelp/…
স্ট্রিপলিং

15

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


10

সলিডের মতে, আপনি কেবল ইন্টারফেসটি তৈরি করতে পারবেন না, এবং এটি কেবল অন্য কোনও ফাইলে থাকা উচিত নয়, এটি একটি পৃথক সমাবেশেও হওয়া উচিত।

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

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

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


8

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

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


6

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

ব্যক্তিগতভাবে আমি একই ফাইলটিতে ইন্টারফেস এবং ক্লাস রাখতে পছন্দ করি যখন কেবলমাত্র একটি শ্রেণি থাকে যা ইন্টারফেস প্রয়োগ করে, যেমন আপনার ক্ষেত্রে।

ন্যাভিগেশন নিয়ে আপনার যে সমস্যা রয়েছে সে সম্পর্কে আমি পুনঃশিকারকে সুপারিশ করতে পারি । এটিতে একটি নির্দিষ্ট ইন্টারফেস পদ্ধতি প্রয়োগকারী পদ্ধতিতে সরাসরি জাম্পিংয়ের জন্য কয়েকটি অত্যন্ত দরকারী শর্টকাট রয়েছে।


3
দলটির অনুশীলনগুলি ফাইলের কাঠামো নির্ধারণ করতে এবং আদর্শ পদ্ধতির বিপরীতে থাকার জন্য +1 দেখানোর জন্য 1

3

এমন অনেক সময় রয়েছে যেখানে আপনি চান যে আপনার ইন্টারফেসটি কেবল শ্রেণীর কাছে পৃথক ফাইলে নয়, এমনকি সম্পূর্ণ পৃথক সমাবেশে থাকতে হবে

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


2

এটি খুব কমই, যদি কখনও হয় তবে একটি ইন্টারফেস 1 এর একক বাস্তবায়নটি বোঝায় । যদি আপনি একটি সর্বজনীন ইন্টারফেস এবং সেই একই ইন্টারফেসটিকে একই ফাইলে প্রয়োগ করে এমন একটি সার্বজনীন শ্রেণি রাখেন তবে ভাল সম্ভাবনা হ'ল আপনাকে কোনও ইন্টারফেসের প্রয়োজন হবে না।

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

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


1 একটি উল্লেখযোগ্য ব্যতিক্রম হ'ল যখন আপনার পরীক্ষার উদ্দেশ্যে ইন্টারফেসের প্রয়োজন হয় কারণ আপনার বিদ্রূপের কাঠামোর পছন্দটি আপনার কোডটিতে এই অতিরিক্ত প্রয়োজনীয়তা রেখেছিল requirement


3
প্রকৃতপক্ষে .NET এ এক শ্রেণির জন্য একটি ইন্টারফেস রাখা একেবারে স্বাভাবিক প্যাটার্ন, কারণ এটি ইউনিট পরীক্ষাগুলিগুলিকে মক, স্টাবস, স্পাই বা অন্যান্য পরীক্ষার দ্বিগুণের সাথে নির্ভরশীলতার বিকল্প তৈরি করতে দেয়।
পিট

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

2
@ কিথস একটি ইন্টারফেস ব্যতীত একটি শ্রেণি কেবল তখনই আপনার ডিজাইনে থাকতে হবে যখন আপনি মৃত-নির্দিষ্ট হন যে এটি সাবক্লাস করার কোনও মানে হয় না এবং আপনি সেই শ্রেণি তৈরি করেন sealed। আপনি যদি সন্দেহ করেন যে আপনি ভবিষ্যতে কোনও সময় দ্বিতীয় সাবক্লাস যুক্ত করতে পারেন, আপনি এখনই একটি ইন্টারফেস রেখেছেন। পিএস একটি শালীন মানের রিফ্যাক্টরিং সহকারী আপনার একক রিশার্প্পার লাইসেন্সের দামের মাঝারি দামে হতে পারে :)
ড্যাসব্লিংকনলাইট

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

2
@ কিথস: আপনার একটি বাস্তবায়ন দুটি হয়ে গেলে কী হবে? আপনার বাস্তবায়নের পরিবর্তন যখন একই; আপনি এই পরিবর্তনটি প্রতিবিম্বিত করতে কোড পরিবর্তন করেন। YAGNI এখানে প্রযোজ্য। ভবিষ্যতে কী পরিবর্তন হতে চলেছে তা আপনি কখনই জানতে পারবেন না, তাই সম্ভব সবচেয়ে সহজ জিনিসটি করুন। (দুর্ভাগ্যক্রমে এই
ম্যাক্সিমের

2

ইন্টারফেসগুলি তাদের ক্লায়েন্টদের সাথে তাদের বাস্তবায়নের নয়, যেমন রবার্ট সি মার্টিনের Agile নীতি, অনুশীলন এবং প্যাটার্নগুলিতে সংজ্ঞায়িত। সুতরাং, একই জায়গায় ইন্টারফেস এবং প্রয়োগের সংমিশ্রণ এটি নীতিবিরোধী।

ক্লায়েন্ট কোড ইন্টারফেসের উপর নির্ভর করে। এটি প্রয়োগ না করে ক্লায়েন্ট কোড এবং ইন্টারফেস সংকলন এবং স্থাপনের সম্ভাবনাটিকে অনুমতি দেয় । ক্লায়েন্ট কোডে প্লাগইনগুলির মতো আপনি বিভিন্ন বাস্তবায়ন করতে পারেন ।

আপডেট: এটি এখানে একটি চতুর-নীতি নয়। গ্যাং অফ ফোর ইন ডিজাইন প্যাটার্নস, '94-এ, ইতোমধ্যে ইন্টারফেসগুলিতে মেনে চলার ক্লায়েন্টদের এবং ইন্টারফেসগুলিতে প্রোগ্রামিংয়ের কথা বলছে। তাদের মতামতও একই রকম।


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

1
হ্যাঁ, তবে ইন্টারফেসটি এখনও ক্লায়েন্টেরই এবং বাস্তবায়নের নয়, আমরা চটজলদি কথা বলছি বা না তা নির্বিশেষে।
প্যাটকোস সিএসবা

আমি এই নিয়ে আপনার সাথে আছি
মার্জন ভেনেমা

0

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


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

Iইন্টারফেস দিয়ে শুরু করা কেবল দুটি ফাইলে বিচ্ছেদ সম্পর্কে আমার যুক্তিগুলির পরিচয় ছিল। কোডটি আরও ভাল পঠনযোগ্য এবং এটি নির্ভরতাগুলির বিপরীতটিকে আরও স্পষ্ট করে তোলে।
অলিনস

4
এটি পছন্দ করুন বা না করুন, ইন্টারফেসের নামের সামনে 'আমি' ব্যবহার করা। NET এ ডি-ফ্যাক্টো স্ট্যান্ডার্ড। একটি নেট প্রকল্পের মান অনুসরণ না করা আমার দৃষ্টিতে 'অন্তত বিস্ময়ের নীতি' লঙ্ঘন হতে পারে।
পিট

আমার মূল কথাটি: দুটি ফাইলে আলাদা। একটি বিমূর্তনের জন্য এবং একটি বাস্তবায়নের জন্য। Iআপনার পরিবেশে যদি এর ব্যবহারটি স্বাভাবিক হয়: এটি ব্যবহার করুন! (তবে আমি এটি পছন্দ করি না :))
অলিনস

এবং পি.এস.ই. এর ক্ষেত্রে, একটি ইন্টারফেসের সামনে আমি উপসর্গটি করা আরও স্পষ্ট করে তোলে যে পোস্টারটি একটি ইন্টারফেসের বিষয়ে কথা বলছে, অন্য শ্রেণির উত্তরাধিকার সূত্রে নয়।

0

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


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

0

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

অবশ্যই, কেউ তর্ক করতে পারে যে একই ফাইলটিতে দু'জনের থাকার কারণে তারা অচেতনাকে তাদের সত্যিকারের তুলনায় আরও প্রোগ্রামিকভাবে মিলিত হিসাবে বিবেচনা করতে পারে, যা ঝুঁকিপূর্ণ is

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


এটি কেবল একটি "সাংগঠনিক সুবিধার্থে" নয় ... এটি ঝুঁকি ব্যবস্থাপনার, স্থাপনা মিলিগ্রেট, কোড ট্রেসিবিলিটি, পরিবর্তন নিয়ন্ত্রণ, উত্স নিয়ন্ত্রণের শব্দ, সুরক্ষা মিলিগ্রামের বিষয়ও। এই প্রশ্নের অনেকগুলি কোণ রয়েছে।
টিএসমিথ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.