আপনি কি # # 4.0 এ ওভারলোডগুলি বা alচ্ছিক পরামিতিগুলি ব্যবহার করে পদ্ধতিগুলি ঘোষণা করবেন?

Question

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

উদাহরণস্বরূপ FileStreamশ্রেণীর মতো এমন প্রায় পনেরোটি আলাদা আলাদা কনস্ট্রাক্টর রয়েছে যা যৌক্তিক 'পরিবারগুলিতে বিভক্ত হতে পারে below যেমন নীচে একটি স্ট্রিং থেকে, একটি থেকে IntPtrএবং একটি থেকে একটি SafeFileHandle।

FileStream(string,FileMode);
FileStream(string,FileMode,FileAccess);
FileStream(string,FileMode,FileAccess,FileShare);
FileStream(string,FileMode,FileAccess,FileShare,int);
FileStream(string,FileMode,FileAccess,FileShare,int,bool);

আমার কাছে মনে হয় যে এই ধরণের প্যাটার্নটি পরিবর্তে তিনটি নির্মাণকারী তৈরি করে এবং ডিফল্ট করা যেতে পারে এমনগুলির জন্য alচ্ছিক পরামিতি ব্যবহার করে আরও সহজ করা যেতে পারে, যা নির্মাণকারীর বিভিন্ন পরিবারকে আরও স্বতন্ত্র করে তুলবে [দ্রষ্টব্য: আমি জানি এই পরিবর্তনটি হবে না) ছাত্রলীগে তৈরি, আমি এই ধরণের পরিস্থিতির জন্য অনুমানমূলকভাবে কথা বলছি]।

আপনি কি মনে করেন? সি # ৪.০ থেকে এটি কীভাবে কনস্ট্রাক্টরগুলির সাথে সম্পর্কিত গ্রুপগুলি এবং methodsচ্ছিক প্যারামিটারগুলির সাথে পদ্ধতিগুলির একক পদ্ধতি তৈরি করা আরও বোধগম্য হবে, বা প্রচলিত বহু-ওভারলোড প্রক্রিয়াটির সাথে যুক্ত থাকার কোনও ভাল কারণ আছে?

Answer 1

আমি নিম্নলিখিত বিবেচনা করব:

• Languagesচ্ছিক পরামিতিগুলিকে সমর্থন করে না এমন ভাষাগুলি থেকে আপনার কোড ব্যবহার করা দরকার? যদি তা হয় তবে ওভারলোডগুলি সহ বিবেচনা করুন।
• আপনার দলে কি এমন কোনও সদস্য আছেন যারা alচ্ছিক পরামিতিগুলির সহিংসতার বিরোধিতা করেন? (কখনও কখনও মামলা তর্ক করার চেয়ে আপনার পছন্দ না এমন সিদ্ধান্ত নিয়ে বেঁচে থাকা আরও সহজ))
• আপনি কি নিশ্চিত যে আপনার ডিফল্টগুলি আপনার কোড তৈরির মধ্যে পরিবর্তিত হবে না, বা তারা যদি তা করতে পারে তবে আপনার কলাররা কি এতে ঠিক থাকবে?

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

Comments

বাস্তববাদ বিষয়ে জ্ঞানের জন্য +1: কখনও কখনও মামলাটি তর্ক করার চেয়ে আপনার পছন্দ না এমন সিদ্ধান্ত নিয়ে জীবনযাপন করা সহজ।

— কিংবদন্তি 2k 9

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

— জন স্কিটি

হাই @ জোনস্কিট, আমি জানতে চাই যে আমরা ieচ্ছিক প্যারামিটারের সাথে অর্থাত্ ও উভয়কে ওভারলোডিং দিয়ে কোন পদ্ধতিটি বলা হবে তা ব্যবহার করব কিনা ?? উদাহরণস্বরূপ যোগ করুন (int a, int b) এবং যুক্ত করুন (int a, int b, int c = 0) এবং ফাংশন কল বলুন: যুক্ত করুন (5,10); কোন পদ্ধতিটিকে ওভারলোডেড ফাংশন বা alচ্ছিক পরামিতি ফাংশন বলা হবে? ধন্যবাদ :)

— শেখর শীট

@ শেখর: আপনি কি চেষ্টা করে দেখেছেন? বিশদের জন্য বিশদটি পড়ুন, তবে মূলত টাই-ব্রেকারে এমন একটি পদ্ধতি যেখানে সংকলকটিকে কোনও alচ্ছিক পরামিতি জিততে হবে না।

— জন স্কিটি

@ জোনস্কিট ঠিক এখনই আমি উপরের সাথে চেষ্টা করেছিলাম ... ফাংশন ওভারলোডিং

— optionচ্ছিক

Answer 2

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

যখন কোনও পদ্ধতি ওভারলোড তার পরামিতিগুলির উপর ভিত্তি করে কোনও ফাংশন সম্পাদন করে তখন ওভারলোডিং ব্যবহার করা অবিরত থাকবে।

আমি আমার ভিবি 6 দিনের মধ্যে backচ্ছিক ফিরে ব্যবহার করেছি এবং এর পরে এটি মিস করেছি, এটি সি # তে প্রচুর এক্সএমএল মন্তব্যের নকলকে হ্রাস করবে।

Answer 3

আমি চিরকালের জন্য alচ্ছিক পরামিতিগুলির সাথে ডেলফি ব্যবহার করছি। আমি পরিবর্তে ওভারলোডগুলি ব্যবহার করতে স্যুইচ করেছি।

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

এবং আমি ধারণাটি পছন্দ করি যে সাধারণত একটি সুপার পদ্ধতি আছে এবং বাকীগুলি প্রায় সহজ সরল মোড়কগুলির কাছাকাছি।

Comments

আমি এটির সাথে অনেকটাই একমত, যদিও এই সাবধানতাটি রয়েছে যে আপনার যখন একাধিক (3+) পরামিতি গ্রহণ করার পদ্ধতি থাকে, তখন প্রকৃতির দ্বারা সমস্ত "alচ্ছিক" (একটি ডিফল্টের সাথে প্রতিস্থাপিত হতে পারে) আপনি অনেকগুলি অনুমতি দিয়ে শেষ করতে পারেন could আর কোন সুবিধা জন্য পদ্ধতি স্বাক্ষর। বিবেচনা করুন Foo(A, B, C)প্রয়োজন Foo(A), Foo(B), Foo(C), Foo(A, B), Foo(A, C), Foo(B, C)।

— ড্যান লগ

Answer 4

আমি অবশ্যই 4.0 এর alচ্ছিক পরামিতি বৈশিষ্ট্যটি ব্যবহার করব। এটি হাস্যকর থেকে মুক্তি পেয়ে যায় ...

public void M1( string foo, string bar )
{
   // do that thang
}

public void M1( string foo )
{
  M1( foo, "bar default" ); // I have always hated this line of code specifically
}

... এবং কলার তাদের দেখতে পাবে এমন মানগুলি ঠিক রাখে ...

public void M1( string foo, string bar = "bar default" )
{
   // do that thang
}

অনেক বেশি সাধারণ এবং ত্রুটিযুক্ত প্রবণ। আমি ওভারলোডের ক্ষেত্রে এটি একটি বাগ হিসাবে দেখেছি ...

public void M1( string foo )
{
   M2( foo, "bar default" );  // oops!  I meant M1!
}

আমি এখনও 4.0 সংস্থাকারীর সাথে খেলিনি, তবে কমপ্লায়ারটি কেবল আপনার জন্য অতিরিক্ত বোঝা নির্গত করে তা জানতে পেরে আমি হতবাক হব না।

Answer 5

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

কল সাইটে alচ্ছিক প্যারামিটারগুলির বাইন্ডিংয়ের একটি উল্লেখযোগ্য পরিণতি হ'ল সংকলকটির জন্য উপলভ্য লক্ষ্য কোডের সংস্করণের উপর ভিত্তি করে তাদের মান নির্ধারণ করা হবে। যদি কোনও অ্যাসেমব্লির 5 টি ডিফল্ট মান সহ Fooএকটি পদ্ধতি থাকে Boo(int)এবং Barঅ্যাসেমব্লিতে একটি কল থাকে Foo.Boo(), সংকলক এটি হিসাবে এটি প্রক্রিয়া করবে Foo.Boo(5)। যদি ডিফল্ট মানটি 6 এ পরিবর্তিত হয় এবং এসেম্বলিকে Fooপুনরায় সংযুক্ত করা হয় তবে এটির নতুন সংস্করণটি পুনরায় সংযুক্ত না করা অবধি Barকল করা চালিয়ে যাবে । পরিবর্তিত হতে পারে এমন জিনিসগুলির জন্য Oneচ্ছিক পরামিতিগুলি ব্যবহার করা উচিত।Foo.Boo(5)Foo

Comments

পুনরায়: "যেহেতু পরিবর্তিত হতে পারে সেগুলির জন্য Oneচ্ছিক পরামিতিগুলি ব্যবহার করা উচিত" " আমি সম্মত হই যে ক্লায়েন্ট কোডের দ্বারা পরিবর্তনটি নজরে না এলে এটি সমস্যাযুক্ত হতে পারে। যাইহোক, একই সমস্যা বিদ্যমান যখন ডিফল্ট মান একটি পদ্ধতি জমিদার ভিতরে লুকানো হয়: void Foo(int value) … void Foo() { Foo(42); }। বাইরে থেকে, কলকারী জানেন না যে ডিফল্ট মানটি ব্যবহৃত হয়, না কখন তা পরিবর্তিত হতে পারে; তার জন্য একটি লিখিত ডকুমেন্টেশন পর্যবেক্ষণ করতে হবে। Alচ্ছিক পরামিতিগুলির জন্য ডিফল্ট মানগুলি ঠিক সেভাবেই দেখা যায়: ডিফল্ট মানটি কী তা ডকুমেন্টেশন-ইন-কোড।

— স্টাকেক্স

@ স্টাকেক্স: যদি কোনও প্যারামিটারহীন ওভারলোডকে প্যারামিটারের সাথে একটি ওভারলোডে চেইন করে, সেই প্যারামিটারটির "ডিফল্ট" মান পরিবর্তন করে ওভারলোডের সংজ্ঞাটি পুনরায় সংশ্লেষ করা কলিং কোডটি পুনরায় সংযুক্ত না করা হলেও এটির মানটি পরিবর্তিত করে ।

— সুপারক্যাট

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

— স্টাকেক্স -

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

— স্টাকেক্স -

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

— সুপারক্যাট

Answer 6

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

Namedচ্ছিক আর্গুমেন্টগুলি, যখন নামযুক্ত আর্গুমেন্টের সাথে সংমিশ্রণে ব্যবহৃত হয়, সিওএম কলের সমস্ত দীর্ঘ-যুক্তি-তালিকা-সমস্ত-বিকল্পগুলির সাথে মিলিত হয়ে অত্যন্ত কার্যকর হয়।

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

Answer 7

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

public Rectangle (Point start = Point.Zero, int width, int height)
{
    Start = start;
    Width = width;
    Height = height;
}

এর পরিবর্তে:

public Rectangle (Point start, int width, int height)
{
    Start = start;
    Width = width;
    Height = height;
}

public Rectangle (int width, int height) :
    this (Point.Zero, width, height)
{
}

স্পষ্টতই এই উদাহরণটি সত্যই সহজ তবে ওপিতে 5 টি ওভারলোডের সাথে জিনিসগুলি সত্যই দ্রুত ভিড় করতে পারে।

Comments

শুনেছি alচ্ছিক প্যারামিটারগুলি শেষ হওয়া উচিত, তাই না?

— Ilya Ryzhenkov 22

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

— রবার্ট পি

তারা আলাপে যা বলেছিল সেগুলি থেকে paraচ্ছিক প্যারামিটারগুলি প্রয়োজনীয় পরামিতিগুলির পরে হওয়া আবশ্যক।

— গ্রেগ বিচ

Answer 8

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

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

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

অবশ্যই, এটি এমন কোনও উত্তর নয় যা সমস্ত দিক পরিচালনা করে তবে আমি মনে করি এটি এমন একটি যুক্ত করেছে যা এখনও পর্যন্ত আচ্ছাদন করা হয়নি।

Answer 9

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

Placeচ্ছিক পরামিতিগুলি প্রথম স্থানে সি # 4 এ প্রবর্তনের কারণ ছিল সিওএম ইন্টারপ সমর্থন করা। এটাই. এবং এখন, আমরা এই সত্যটির সম্পূর্ণ প্রভাব সম্পর্কে শিখছি। Youচ্ছিক প্যারামিটারগুলির সাথে যদি আপনার কোনও পদ্ধতি থাকে তবে আপনি কখনই একটি সঙ্কলন-সময় ব্রেকিংয়ের ভয়ে অতিরিক্ত additionalচ্ছিক পরামিতিগুলির সাথে কোনও ওভারলোড যুক্ত করতে পারবেন না। এবং আপনি কখনই কোনও বিদ্যমান ওভারলোড অপসারণ করতে পারবেন না, কারণ এটি সর্বদা রানটাইম ব্রেকিং পরিবর্তন। আপনার ইন্টারফেসের মতো আচরণ করার দরকার রয়েছে। এই ক্ষেত্রে আপনার একমাত্র অবলম্বন হল একটি নতুন নাম সহ একটি নতুন পদ্ধতি লিখুন। সুতরাং আপনি যদি আপনার API এ alচ্ছিক যুক্তিগুলি ব্যবহার করার পরিকল্পনা করেন তবে এটি সম্পর্কে সচেতন হন।

Answer 10

Alচ্ছিক প্যারামিটারগুলির একটি সতর্কতা সংস্করণ, যেখানে একটি রিফ্যাক্টর অনিচ্ছাকৃত পরিণতি ঘটায়। একটি উদাহরণ:

প্রাথমিক কোড

public string HandleError(string message, bool silent=true, bool isCritical=true)
{
  ...
}

ধরে নিন যে এটি উপরোক্ত পদ্ধতির অনেক কলার মধ্যে একটি:

HandleError("Disk is full", false);

এখানে ইভেন্টটি নিরব নয় এবং সমালোচিত হিসাবে বিবেচিত হবে।

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

রিফ্যাক্টর পরে

পূর্ববর্তী কলটি এখনও সংকলন করে, এবং আসুন আমরা এটি অপরিবর্তিত রিফ্যাক্টরের মাধ্যমে পিছলে যায়:

public string HandleError(string message, /*bool silent=true,*/ bool isCritical=true)
{
  ...
}

...

// Some other distant code file:
HandleError("Disk is full", false);

এখন falseএকটি অনিচ্ছাকৃত প্রভাব ফেলবে, ইভেন্টটিকে আর সমালোচনা হিসাবে বিবেচনা করা হবে না।

এই সূক্ষ্ম খুঁত হতে পারে, যেহেতু সেখানে কোন কম্পাইল বা (যেমন optionals কিছু অন্যান্য আদেশ সহকারে, অসদৃশ রানটাইম এরর হতে হবে এই বা এই )।

মনে রাখবেন যে এই একই সমস্যার অনেক রূপ রয়েছে। অন্য একটি ফর্ম এখানে রূপরেখা আছে ।

এছাড়াও মনে রাখবেন কঠোরভাবে নামে পরামিতি ব্যবহার যখন যেমন ভালো হিসেবে কলিং পদ্ধতি ইস্যু এড়াতে হবে: HandleError("Disk is full", silent:false)। তবে, অন্যান্য সমস্ত বিকাশকারী (বা কোনও পাবলিক এপিআই এর ব্যবহারকারীরা) এটি করবে তা ধরে নেওয়া व्यावहारिक হতে পারে না।

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

Answer 11

উভয় ptionচ্ছিক প্যারামিটার, পদ্ধতির ওভারলোডের নিজস্ব সুবিধা বা অসুবিধা রয়েছে it এগুলির মধ্যে নির্বাচন করার জন্য আপনার পছন্দের উপর নির্ভর করে।

.চ্ছিক প্যারামিটার: কেবল নেট 4.0 এ উপলব্ধ। codeচ্ছিক পরামিতি আপনার কোডের আকার হ্রাস করে। আপনি প্যারামিটার সংজ্ঞা এবং রেফারেন্স করতে পারবেন না

অতিরিক্ত লোড পদ্ধতি: আপনি প্যারামিটারগুলি সংজ্ঞা এবং সংজ্ঞা দিতে পারেন। কোডের আকার বাড়বে তবে ওভারলোডেড পদ্ধতিগুলি বোঝা সহজ।

Answer 12

বেশিরভাগ ক্ষেত্রে executionচ্ছিক পরামিতিগুলি কার্যকরভাবে পরিবর্তন করতে ব্যবহৃত হয়। উদাহরণ স্বরূপ:

decimal GetPrice(string productName, decimal discountPercentage = 0)
{

    decimal basePrice = CalculateBasePrice(productName);

    if (discountPercentage > 0)
        return basePrice * (1 - discountPercentage / 100);
    else
        return basePrice;
}

এখানে ছাড় প্যারামিটার যদি-তবে-অন্য বিবৃতিটি ফিড করতে ব্যবহৃত হয়। এমন বহুবর্ষ আছে যা স্বীকৃত ছিল না এবং তারপরে এটি যদি অন্যথায় বিবৃতি হিসাবে কার্যকর করা হয়। এই ক্ষেত্রে দুটি নিয়ন্ত্রণ প্রবাহকে দুটি স্বতন্ত্র পদ্ধতিতে বিভক্ত করা আরও ভাল:

decimal GetPrice(string productName)
{
    decimal basePrice = CalculateBasePrice(productName);
    return basePrice;
}

decimal GetPrice(string productName, decimal discountPercentage)
{

    if (discountPercentage <= 0)
        throw new ArgumentException();

    decimal basePrice = GetPrice(productName);

    decimal discountedPrice = basePrice * (1 - discountPercentage / 100);

    return discountedPrice;

}

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

এর মতো ক্ষেত্রে, আমি optionচ্ছিক পরামিতিগুলি না রাখাই পছন্দ করি, তবে কলারকে তার বর্তমান পরিস্থিতি অনুসারে কার্যকরভাবে সম্পাদন পরিস্থিতি নির্বাচন করতে বাধ্য করতে বাধ্য করা।

পরিস্থিতি প্যারামিটারগুলির সাথে খুব মিল, যা নাল হতে পারে। বাস্তবায়নের মতো বিবৃতিতে ফোটার সময় এটি একইভাবে খারাপ ধারণা if (x == null)।

আপনি এই লিঙ্কগুলিতে বিশদ বিশ্লেষণ পেতে পারেন: alচ্ছিক পরামিতিগুলি এড়ানো এবং নাল প্যারামিটারগুলি এড়ানো

Answer 13

বিকল্পগুলির পরিবর্তে যখন ওভারলোড ব্যবহার করবেন তখন কোনও নন-ব্রেইনার যুক্ত করতে:

যখনই আপনার কাছে এমন অনেকগুলি পরামিতি রয়েছে যা কেবল একসাথে বোঝায়, সেগুলিতে বিকল্পগুলি প্রবর্তন করবেন না।

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

উদাহরণ:

enum Match {
    Regex,
    Wildcard,
    ContainsString,
}

// Don't: This way, Enumerate() can be called in a way
//         which does not make sense:
IEnumerable<string> Enumerate(string searchPattern = null,
                              Match match = Match.Regex,
                              SearchOption searchOption = SearchOption.TopDirectoryOnly);

// Better: Provide only overloads which cannot be mis-used:
IEnumerable<string> Enumerate(SearchOption searchOption = SearchOption.TopDirectoryOnly);
IEnumerable<string> Enumerate(string searchPattern, Match match,
                              SearchOption searchOption = SearchOption.TopDirectoryOnly);