ডিজাইন নীতিগুলি যা টেস্টেবল কোড প্রচার করে? (পরীক্ষার মাধ্যমে ড্রাইভিং ডিজাইন বনাম টেস্টেবল কোড ডিজাইন করা)


54

আমি যে প্রকল্পগুলিতে কাজ করি সেগুলির বেশিরভাগগুলি বিকাশ এবং ইউনিট টেস্টিংকে বিচ্ছিন্নতার বিষয়ে বিবেচনা করে যা পরবর্তী সময়ে লেখার ইউনিট পরীক্ষা করে তোলে একটি দুঃস্বপ্ন ma আমার উদ্দেশ্যটি হ'ল উচ্চ স্তরের এবং নিম্ন স্তরের নকশা পর্যায়ক্রমে পরীক্ষাটি মাথায় রাখা।

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

আমি পড়েছি যে সলিড নামে পরিচিত কিছু আছে। আমি বুঝতে চাই যে যদি সলাইডের নীতিগুলি অনুসরণ করে অপ্রত্যক্ষভাবে কোডটি পাওয়া যায় যা সহজেই পরীক্ষাযোগ্য হয়? যদি তা না হয় তবে টেস্টেবল কোডকে প্রচার করার মতো কোনও সু-সংজ্ঞায়িত ডিজাইনের নীতি রয়েছে?

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

এই বিষয় সম্পর্কিত আরও একটি প্রশ্ন হ'ল প্রতিটি মডিউলের জন্য ইউনিট পরীক্ষার কেস লিখতে সক্ষম হওয়ার উদ্দেশ্যে কোনও বিদ্যমান পণ্য / প্রকল্পটিকে পুনরায় ফ্যাক্টর করা এবং কোড এবং ডিজাইনে পরিবর্তন করা ঠিক আছে কিনা?



ধন্যবাদ. আমি কেবল নিবন্ধটি পড়া শুরু করেছি এবং এটি ইতিমধ্যে বোঝা যায়।

1
এটি আমার সাক্ষাত্কারের প্রশ্নগুলির মধ্যে একটি ("কীভাবে সহজেই ইউনিট পরীক্ষার জন্য আপনি কোডটি ডিজাইন করেন?")। তারা ইউনিট টেস্টিং, উপহাস / স্টাব্বিং, ওওডি এবং সম্ভাব্য টিডিডি বুঝতে পারলে এটি এককভাবে আমাকে দেখায়। দুঃখের বিষয়, উত্তরগুলি সাধারণত "পরীক্ষার ডাটাবেস তৈরি করুন" এর মতো কিছু।
ক্রিস পিটম্যান

উত্তর:


56

হ্যাঁ, সলিড কোড ডিজাইনের খুব ভাল উপায় যা সহজেই পরীক্ষা করা যায়। একটি সংক্ষিপ্ত প্রাইমার হিসাবে:

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

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

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

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

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

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

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

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

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

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


16

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

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

আমার অভিজ্ঞতা থেকে, সোলিডের 2 টি নীতি পরীক্ষামূলক কোড ডিজাইনে বড় ভূমিকা পালন করে:

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

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

(...) কোনও বিদ্যমান পণ্য / প্রকল্পকে নতুন করে ফ্যাক্টর করা এবং প্রতিটি মডিউলের জন্য ইউনিট পরীক্ষার কেস লিখতে সক্ষম হওয়ার উদ্দেশ্যে কোড এবং ডিজাইনে পরিবর্তন করা ঠিক আছে কিনা?

বিদ্যমান ইউনিট পরীক্ষা না করে, এটিকে সহজভাবে বলা হয় - ঝামেলা জিজ্ঞাসা করা। ইউনিট টেস্ট হ'ল আপনার কোডটি যে কাজ করে তা আপনার গ্যারান্টি । আপনার যদি যথাযথ পরীক্ষার কভারেজ থাকে তবে ব্রেকিং পরিবর্তনের সাথে সাথেই চিহ্নিত করা হবে ted

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

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


উচ্চ সংহতি এবং কম সংশ্লেষ
জে কে।

8

আপনার প্রথম প্রশ্ন:

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

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

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

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


4

অন্যান্য উত্তরের পাশাপাশি, যা আলগা দম্পতি অর্জনে দৃষ্টি নিবদ্ধ করে, আমি জটিল যুক্তি পরীক্ষা করার বিষয়ে একটি শব্দ বলতে চাই।

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

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

রাজ্যগুলি সুস্পষ্ট ছিল এই বিষয়টি কোডের সমস্ত সম্ভাব্য পাথগুলি (রাষ্ট্রীয় রূপান্তরগুলি) গণনা করা সহজতর করেছিল এবং এভাবে প্রত্যেকটির জন্য একটি ইউনিট-পরীক্ষা লিখতে সক্ষম হয়েছিল।

অবশ্যই, প্রতিটি জটিল যুক্তি রাষ্ট্রীয় মেশিন হিসাবে মডেল করা যায় না।


3

সলাইড একটি দুর্দান্ত শুরু, আমার অভিজ্ঞতায় সলাইডের চারটি দিকই ইউনিট পরীক্ষার সাথে সত্যিই ভাল কাজ করে।

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

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

public interface ISomeInterface
{
    int GetValue();
}  

public class SomeClass : ISomeInterface
{
    public int GetValue()
    {
         return 1;
    }
}

public interface ISomeOtherInterface
{
    bool IsSuccess();
}

public class SomeOtherClass : ISomeOtherInterface
{
     private ISomeInterface m_SomeInterface;

     public SomeOtherClass(ISomeInterface someInterface)
     {
          m_SomeInterface = someInterface;
     }

     public bool IsSuccess()
     {
          return m_SomeInterface.GetValue() == 1;
     }
}

public class SomeFactory
{
     public virtual ISomeInterface GetSomeInterface()
     {
          return new SomeClass();
     }

     public virtual ISomeOtherInterface GetSomeOtherInterface()
     {
          ISomeInterface someInterface = GetSomeInterface();

          return new SomeOtherClass(someInterface);
     }
}

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

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


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