কোড চুক্তি / দৃser়তা: সদৃশ চেকগুলি কী?

Question

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

উদাহরণ পরিস্থিতি: আমি প্রথমে নিম্নলিখিত ফাংশনটি লিখি

void DoSomething( object obj )
{
  Contract.Requires<ArgumentNullException>( obj != null );
  //code using obj
}

তারপরে কয়েক ঘন্টা পরে আমি অন্য একটি ফাংশন লিখি যা প্রথমটিকে কল করে। স্মৃতিতে এখনও সবকিছু সতেজ হওয়ায় আমি চুক্তিটির নকল না করার সিদ্ধান্ত নিয়েছি, যেহেতু আমি জানি যে DoSomethingইতোমধ্যে নাল বস্তুর জন্য চেক করা উচিত:

void DoSomethingElse( object obj )
{
  //no Requires here: DoSomething will do that already
  DoSomething( obj );
  //code using obj
}

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

void DoSomethingElse( object obj )
{
  Contract.Requires<ArgumentNullException>( obj != null );
  DoSomething( obj );
  //code using obj
}

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

এ জাতীয় পরিস্থিতির জন্য সবচেয়ে সাধারণ অনুশীলন কোনটি?

Comments

ArgumentBullException? এটি একটি নতুন :)

— একটি সিভিএন

LOL @ আমার টাইপিং দক্ষতা ... আমি এটি সম্পাদনা করব।

— stijn

Answer 1

ব্যক্তিগতভাবে আমি কোনও ফাংশনে নাল পরীক্ষা করে যা ব্যর্থ হবে যদি এটি নাল হয়ে যায়, এবং এমন কোনও ফাংশনে নয় যা না করে।

সুতরাং উপরোক্ত আপনার উদাহরণে, যদি doSomethingElse () অবজেক্ট অবলম্বন করার প্রয়োজন না হয় তবে আমি সেখানে শূন্যতার জন্য আপত্তিটি পরীক্ষা করব না।

যদি ডোসোমথিং () ডেরিফারেন্স আপত্তি করে তবে তা নালার জন্য পরীক্ষা করা উচিত।

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

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

Comments

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

— একটি সিভিএন

Answer 2

গ্রেট! আমি দেখতে পেয়েছি আপনি .NET এর জন্য কোড চুক্তিগুলি সম্পর্কে সন্ধান পেয়েছি । কোড চুক্তিগুলি আপনার গড় উত্সের চেয়ে অনেক বেশি এগিয়ে যায়, যার মধ্যে স্ট্যাটিক চেকার সেরা উদাহরণ। আপনার যদি ভিজ্যুয়াল স্টুডিও প্রিমিয়াম বা উচ্চতর ইনস্টল না হয় তবে এটি আপনার জন্য উপলভ্য নাও হতে পারে তবে আপনি কোড চুক্তি ব্যবহার করতে চলেছেন তবে এর পিছনের উদ্দেশ্যটি বোঝা গুরুত্বপূর্ণ।

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

আপনার প্রদত্ত উদাহরণে, DoSomethingElse()ফাংশনটি উল্লিখিত চুক্তি অনুসারে বাঁচবে না DoSomething()যেমন নালটি পাস হতে পারে, এবং স্থির পরীক্ষক এই সমস্যাটি নির্দেশ করবে। এটির সমাধানের উপায় হ'ল একই চুক্তিটি যুক্ত করে DoSomethingElse()।

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

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

Comments

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

— stijn

(1) "পরে আবিষ্কার করুন যে কিছু যুক্তি অন্য কোথাও নকল হয়েছে" । এজন্য আমি সহজেই ফাংশনগুলি বিভক্ত করার চেয়ে সর্বদা "একটি এপিআইয়ের দিকে বিকাশ" করা আরও গুরুত্বপূর্ণ মনে করি। কেবল বর্তমান শ্রেণীর মধ্যেই নয়, পুনরায় ব্যবহার সম্পর্কে ক্রমাগত চিন্তা করুন। (২) "বা এক বছর পরে আবার এটি পড়ুন এবং এটি অপঠনযোগ্য খুঁজে পান" কারণ ফাংশনগুলির নাম রয়েছে এটি আরও ভাল? আপনি যদি আমার ব্লগে একজন মন্তব্যকারীকে "কোড অনুচ্ছেদে" হিসাবে বর্ণিত ব্যবহার করেন তবে আপনি আরও পড়ার যোগ্যতা অর্জন করতে পারেন । (3) "বিভক্ত ফাংশন = এফ 10 কী তে কম ঝাঁকুনি" ... কেন তা আমি দেখছি না।

— স্টিভেন জিউরিস

(1) একমত (২) পঠনযোগ্যতা ব্যক্তিগত অগ্রাধিকার তাই এটি আমার পক্ষে আসলে আলোচনার অধীনে কিছু নয় .. (3) 20 লাইনের কোনও ক্রিয়াকলাপটি পেরোনোর ​​জন্য 20 বার F10 আঘাত করা দরকার। একটি বিভক্ত ফাংশনটিতে সেই লাইনগুলির মধ্যে 10 টি রয়েছে এমন একটি ক্রিয়াকলাপটি অতিক্রম করতে আমার কেবল 11 বার এফ 10 হিট করার পছন্দ দেয়। হ্যাঁ, প্রথম ক্ষেত্রে আমি ব্রেকপয়েন্টগুলি রাখতে পারি বা 'কার্সার থেকে জাম্প' নির্বাচন করতে পারি তবে এটি এখনও দ্বিতীয় ক্ষেত্রেটির চেয়ে বেশি প্রচেষ্টা।

— stijn

@ স্টিজন: (২) সম্মত হয়েছে; পি (৩) স্পষ্ট করার জন্য ধন্যবাদ!

— স্টিভেন জিউরিস