ইন্টারফেস কখন ব্যবহার করবেন (ইউনিট টেস্টিং, আইওসি?)

Question

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

আমি মনে করি কিছু মিথ্যাচার থেকে উদ্ভূত প্রতিটি কিছুর জন্য ইন্টারফেস তৈরির এই অনুশীলন:

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

2) আমি প্রাথমিকভাবে ভেবেছিলাম আইওসি ফ্রেমওয়ার্ক (ক্যাসেল উইন্ডসর) সহ কোনও শ্রেণি নিবন্ধ করার জন্য একটি ইন্টারফেসের প্রয়োজন ছিল, যেমন

Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()...

আসলে যখন আমি কেবল নিজের বিরুদ্ধে কংক্রিটের ধরণটি নিবন্ধ করতে পারি:

Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()...

3) ইন্টারফেস ব্যবহার করে, যেমন নির্ভরতা ইনজেকশনের জন্য কনস্ট্রাক্টর পরামিতি, ফলে "আলগা কাপলিং" হয়।

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

সম্পাদনা : - আমি কেবল মকের সাথে একটি নাটক করছি, এবং এটির উপহাস করতে সক্ষম হওয়ার জন্য এটি পাবলিক এবং ভার্চুয়াল হওয়ার জন্য একটি পাবলিক প্যারামিটারলেস কনস্ট্রাক্টর লাগবে seems সুতরাং দেখে মনে হচ্ছে আমি তখন অভ্যন্তরীণ ক্লাস করতে পারি না?

Comments

আমি

— দৃ sure়ভাবে

আপনার ব্যক্তিগত সদস্যদের পরীক্ষা করার কথা নয় । এটি theশ্বর শ্রেণীর অ্যান্টি-প্যাটার্নের সূচক হিসাবে দেখা যেতে পারে। আপনি যদি ব্যক্তিগত কার্যকারিতা পরীক্ষা করার প্রয়োজন বোধ করেন তবে সাধারণত নিজের ক্লাসে সেই কার্যকারিতাটি encapsulate করা ভাল ধারণা।

— Spoike

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

— অ্যান্ড্রু স্টিফেন্স

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

— Spoike

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

— অ্যান্ড্রু স্টিফেনস

Answer 1

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

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

Comments

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

— অ্যান্ড্রু স্টিফেন্স

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

— অ্যান্ড্রু স্টিফেন্স

@ অ্যান্ড্রুস্টেফেনস - বিশ্বের প্রতিটি বিষয়কে উপহাস করার দরকার নেই। যদি ক্লাসগুলি ইন্টারফেসের প্রয়োজন না হয় যথেষ্ট শক্ত (বা দৃ coup়ভাবে সংযুক্ত) হয় তবে তারা ইউনিট পরীক্ষায় কেবলমাত্র ব্যবহারের মতো যথেষ্ট শক্ত। এগুলিতে সময় / জটিলতা moq-ing পরীক্ষার সুবিধার জন্য উপযুক্ত নয়।

— টেলাস্টিন

-1, যেহেতু প্রায়শই আপনি জানেন না আপনি প্রথম কোডটি লেখার সময় আপনাকে কতগুলি প্রয়োগকারী প্রয়োজন। আপনি যদি প্রথম থেকেই কোনও ইন্টারফেস ব্যবহার করেন তবে অতিরিক্ত প্রয়োগকারীদের লেখার সময় আপনাকে ক্লায়েন্ট পরিবর্তন করতে হবে না।

— উইলবার্ট

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

— টেলাস্টিন

Answer 2

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

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

3) এটা কিভাবে মিথ্যা?

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

Answer 3

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

সুতরাং, আপনার আইওসি-ধারক নিবন্ধের প্রথম সংস্করণটি হ'ল সঠিক এবং ভবিষ্যতে আপনার ব্যবহার করা উচিত।

যদি আপনি আপনার ক্লাসগুলি সর্বজনীন বা অভ্যন্তরীণ করেন তবে প্রকৃতপক্ষে সম্পর্কিত নয় এবং কোনওটিই মিক-ইনগিং নয়।

Answer 4

আমি আপনার সত্যিকারের প্রকল্পের প্রতিটি ধরণের সম্পর্কে "উপহাস" করার প্রয়োজনীয়তা অনুভব করেছি বলে সত্যই আমি আরও উদ্বিগ্ন হব।

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

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

ইন্টারফেস সম্পর্কে আরও সুনির্দিষ্টভাবে বলতে গেলে, আমি কয়েকটি গুরুত্বপূর্ণ ক্ষেত্রে এগুলি দরকারী বলে মনে করি:

• যখন আপনাকে পদ্ধতির কলগুলি বিভিন্ন ধরণের প্রেরণের দরকার হয়, যেমন আপনার একাধিক বাস্তবায়ন থাকে (এটি স্পষ্টতই একটি, যেহেতু বেশিরভাগ ভাষায় ইন্টারফেসের সংজ্ঞা কেবল ভার্চুয়াল পদ্ধতিগুলির সংকলন)

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

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

Answer 5

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