পার্শ্ব প্রতিক্রিয়াগুলি ফাংশনাল প্রোগ্রামিংয়ে মন্দ হিসাবে বিবেচিত হয়?


69

আমি মনে করি যে পার্শ্ব প্রতিক্রিয়াগুলি একটি প্রাকৃতিক ঘটনা। তবে এটি কার্যকরী ভাষায় নিষিদ্ধের মতো কিছু। এর কারণ কী?

আমার প্রশ্নটি কার্যকরী প্রোগ্রামিং শৈলীর সাথে নির্দিষ্ট। সমস্ত প্রোগ্রামিং ভাষা / দৃষ্টান্ত নয় para


6
পার্শ্ব প্রতিক্রিয়াবিহীন একটি প্রোগ্রাম অকেজো, সুতরাং পার্শ্ব প্রতিক্রিয়া দুষ্ট বা নিষিদ্ধ নয়। তবে এফপি কোডগুলি সীমান্তের পার্শ্ব প্রতিক্রিয়ার সাথে সীমাবদ্ধ করে, সুতরাং কোডের যতটা সম্ভব একটি অংশ পার্শ্ব-প্রতিক্রিয়া মুক্ত ফাংশন। এটি উত্সাহিত করা হয়েছে কারণ পার্শ্ব-প্রভাব মুক্ত ফাংশন এবং সাবসিস্টেমগুলি বোঝা সহজ, বিশ্লেষণ করা সহজ, পরীক্ষা করা সহজ এবং অনুকূলিতকরণ সহজ easier
জ্যাকবিবি

@ জ্যাক্কসবি তাদের বোঝার জন্য কেন সহজ, বিশ্লেষণ করা সহজ, পরীক্ষার পক্ষে সহজ এবং অনুকূলিতকরণ সহজতর কেন তা বোঝানোর জন্য এটি একটি উত্তরের উত্তর দেবে।
সিভড ving

উত্তর:


72

পার্শ্ব প্রতিক্রিয়া ছাড়াই আপনার ফাংশন / পদ্ধতিগুলি লেখার - যাতে এগুলি খাঁটি ফাংশন - আপনার প্রোগ্রামের সঠিকতার বিষয়ে যুক্তি করা সহজ করে তোলে।

এটি নতুন আচরণ তৈরি করার জন্য এই ফাংশনগুলি রচনা করা সহজ করে তোলে।

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

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

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


4
আপনার উত্তরে সম্মতি সম্পর্কে কিছু যুক্তি বিবেচনা করতে পারেন?
বেঞ্জল

5
পার্শ্ব-প্রতিক্রিয়া মুক্ত ফাংশনগুলি পরীক্ষা করা এবং পুনঃব্যবহার করা সহজ।
লেনি প্রোগ্রামাররা

@ লেনি 222: ফাংশন রচনা সম্পর্কে কথা বলার মাধ্যমে আমি আবার ইশারা দিচ্ছিলাম।
ফ্রাঙ্ক শায়ারার

@ ফ্র্যাঙ্ক: আহ, ঠিক আছে, খুব অগভীর ব্রাউজিং। :)
লেনি প্রোগ্রামাররা

@ লেনি 222: ঠিক আছে; এটি বানান করা সম্ভবত ভাল জিনিস।
ফ্র্যাঙ্ক শায়ারার

23

ফাংশনাল প্রোগ্রামিং সম্পর্কে একটি নিবন্ধ থেকে :

অনুশীলনে, অ্যাপ্লিকেশনগুলির কিছু পার্শ্ব প্রতিক্রিয়া হওয়া দরকার। কার্যনির্বাহী প্রোগ্রামিং ভাষা হাস্কেলের প্রধান অবদানকারী সাইমন পাইটন-জোনস নিম্নলিখিত কথা বলেছিলেন: "শেষ পর্যন্ত, যে কোনও প্রোগ্রামের অবশ্যই রাষ্ট্রের চালচলন করা উচিত A এমন একটি প্রোগ্রামের কোনও পার্শ্ব প্রতিক্রিয়া নেই যা একধরণের ব্ল্যাক বক্স is আপনি যা বলতে পারেন তা হ'ল বাক্সটি গরম হয়ে যায়। ( http://oscon.blip.tv/file/324976 ) মূলত পার্শ্ব প্রতিক্রিয়া সীমাবদ্ধ করা, তাদের পরিষ্কারভাবে চিহ্নিত করা এবং কোড জুড়ে এগুলি ছড়িয়ে দেওয়া এড়ানো গুরুত্বপূর্ণ key


2
oscon.blip.tv/file/324976 youtube.com/watch?v=iSmkqocn0oQ&t=3m20s দ্বারা প্রতিস্থাপিত হয়েছে ।
গৌরব

23

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

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


এ কারণেই তারা "নিষিদ্ধের মতো কিছু" - এফপিএলগুলি আপনাকে পার্শ্ব প্রতিক্রিয়া সীমাবদ্ধ করতে উত্সাহ দেয়।
ফ্রাঙ্ক শায়ারার

পদ্ধতির জন্য +1। পার্শ্ব প্রতিক্রিয়া এখনও বিদ্যমান। প্রকৃতপক্ষে, এগুলি সীমাবদ্ধ
বেলুন

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

@ গুলশান - কারণ পার্শ্ব প্রতিক্রিয়াগুলি প্রোগ্রামগুলি বুঝতে এবং অনুকূল করতে আরও শক্ত করে to
কেওসপ্যান্ডিয়ন

হাস্কেলের ক্ষেত্রে মূল কথাটি "পার্শ্ব প্রতিক্রিয়া সীমাবদ্ধ করা" নয়। পার্শ্ব প্রতিক্রিয়াগুলি ভাষাতে প্রকাশ করা অসম্ভব। ক্রিয়াকলাপগুলি যেমন readFileকরায় তা ক্রিয়াকলাপের ক্রম নির্ধারণ করে। এই ক্রমটি কার্যত খাঁটি এবং একধরণের বিমূর্ত গাছের মতো যা বর্ণনা করা হয়। আসল নোংরা পার্শ্ব প্রতিক্রিয়াগুলি তখন রানটাইম দ্বারা চালিত হয়।
সারা

13

কয়েকটি নোট:

  • পার্শ্ব প্রতিক্রিয়াবিহীন ক্রিয়াকলাপগুলিকে তুচ্ছ ঘটনাটি সমান্তরালে সম্পাদন করা যেতে পারে, তবে পার্শ্ব প্রতিক্রিয়াযুক্ত ফাংশনগুলিতে সাধারণত কিছু ধরণের সিঙ্ক্রোনাইজেশন প্রয়োজন হয়।

  • পার্শ্ব প্রতিক্রিয়াবিহীন ক্রিয়াকলাপগুলি আরও আক্রমণাত্মক অপ্টিমাইজেশনের অনুমতি দেয় (উদাহরণস্বরূপ, ফলাফলের ক্যাশে ব্যবহার করে), কারণ যতক্ষণ আমরা সঠিক ফল পাই, ততক্ষণ কার্যত কার্য সম্পাদন হয়েছে কি না তা এমনকি তাতে কিছু আসে যায় না doesn't


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

1
@ নয়েল উইডমার এর মতো কিছু ইতিমধ্যে বিদ্যমান। ওরাকল এর পিএল / এসকিউএল deterministicপার্শ্ব প্রতিক্রিয়া ছাড়াই ফাংশনগুলির জন্য একটি ধারা সরবরাহ করে, যাতে তারা প্রয়োজনের চেয়ে প্রায়শই কার্যকর হয় না।
ব্যবহারকারী 281377

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

deterministicদফা শুধু একটি শব্দ যে কম্পাইলার এই একটি নির্ণায়ক ফাংশন, কিভাবে তুলনা করা যায় যে বলে হয় finalজাভা শব্দ কম্পাইলার যে পরিবর্তনশীল পরিবর্তন করতে পারবেন না বলে।
ব্যবহারকারী 281377

11

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

এই সহজ উদাহরণ বিবেচনা করুন:

val foo = 42
// Several lines of code you don't really care about, but that contain a
// lot of function calls that use foo and may or may not change its value
// by side effect.

// Code you are troubleshooting
// What's the expected value of foo here?

একটি কার্মিক ভাষা, আমি জানি যে fooএখনো 42. আমি এমনকি হবে না হয় দেখুন , মাঝে কোড এ অনেক কম এটা বুঝতে, বা ফাংশন এটা কল বাস্তবায়নের দিকে তাকাও।

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


6

কোনও ভাষায় অল্পই পার্শ্ব প্রতিক্রিয়া সৃষ্টি করা অসম্ভব করে তোলে। যে ভাষাগুলি সম্পূর্ণ পার্শ্ব-প্রতিক্রিয়ামুক্ত ছিল সেগুলি খুব সীমিত ক্ষমতা ব্যতীত নিষিদ্ধভাবে ব্যবহার করা কঠিন (অসম্ভবের কাছে) ছিল be

পার্শ্ব প্রতিক্রিয়াগুলি কেন মন্দ হিসাবে বিবেচিত হয়?

কারণ তারা কোনও প্রোগ্রামটি ঠিক কী করে তা নিয়ে যুক্তি তৈরি করা এবং আপনি যা প্রত্যাশা করেছেন তা এটি করে তা প্রমাণ করা আরও বেশি কঠিন করে তোলে।

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

উপকারিতা

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

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

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


1
অ্যাডা পার্শ্ব প্রতিক্রিয়া সৃষ্টি করা খুব কঠিন করে তোলে। যদিও এটি অসম্ভব নয়, তবে আপনি তখন কী করবেন তা আপনি পরিষ্কারভাবে জানেন।
mouviciel

@ মউভিচিয়েল: আমি মনে করি সেখানে কমপক্ষে কয়েকটি দরকারী ভাষা রয়েছে যা পার্শ্ব-প্রতিক্রিয়াগুলি খুব কঠিন করে তোলে এবং এগুলি মনোদের কাছে ছেড়ে দেওয়ার চেষ্টা করে।
মের্লিন মরগান-গ্রাহাম

4

পার্শ্ব প্রতিক্রিয়াগুলি আপনার কোডে "ফুটো" এর মতো যা পরে বা আপনার দ্বারা পরিচালিত বা অনিচ্ছুক সহকর্মী দ্বারা পরিচালনা করা দরকার।

কার্যক্ষম ভাষাগুলি কোডকে কম প্রসঙ্গে নির্ভরশীল এবং আরও মডুলার তৈরির উপায় হিসাবে রাষ্ট্র পরিবর্তনশীল এবং পরিবর্তনীয় ডেটা এড়ায়। পরিমিতিটি নিশ্চিত করে যে একটি বিকাশকারীর কাজ অন্যের কাজকে প্রভাবিত / ক্ষতিগ্রস্থ করে না।

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


+1 - "বা কোনও সন্দেহহীন সহকর্মী"
মার্লিন মরগান-গ্রাহাম

1
পার্শ্ব প্রতিক্রিয়া হওয়ার জন্য -1 "লিকগুলি পরিচালনা করা দরকার।" "পার্শ্ব প্রতিক্রিয়া" (অ-খাঁটি-কার্যকরী কোড) তৈরি করা কোনও তুচ্ছ কম্পিউটার প্রোগ্রাম লেখার সম্পূর্ণ উদ্দেশ্য entire
ম্যাসন হুইলার

এই মন্তব্যটি ছয় বছর পরে আসে তবে এর পার্শ্ব প্রতিক্রিয়া রয়েছে এবং তারপরে পার্শ্ব প্রতিক্রিয়া রয়েছে। কাঙ্ক্ষিত ধরণের পার্শ্ব প্রতিক্রিয়াগুলি, I / O ইত্যাদি করা, যে কোনও প্রোগ্রামের পক্ষে সত্যই প্রয়োজনীয়, কারণ আপনার ফলাফলটি কোনওভাবে ব্যবহারকারীকে দেওয়া দরকার - তবে অন্য ধরণের পার্শ্ব প্রতিক্রিয়া যেখানে আপনার কোডটি ভাল ছাড়াই রাষ্ট্র পরিবর্তন করে changes আই / ও করার মতো কারণগুলি আসলে একটি "ফুটো" যা পরে হ্যান্ডেল করা প্রয়োজন। মূল ধারণাটি হ'ল কমান্ড-ক্যোয়ারী বিভাজন : একটি ফাংশন যা কোনও মান দেয় তার পার্শ্ব প্রতিক্রিয়া হওয়া উচিত নয়।
রম্মান

4

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

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

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

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

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


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

@ ইলান: এটি কিছু কার্যকরী ভাষার ক্ষেত্রেও সত্য এবং এটি গ্রহণযোগ্য একটি শৈলী।
back2dos

"কার্যকরী প্রোগ্রামিং অনেক বেশি র‌্যাডিকাল পদ্ধতির গ্রহণ করে, যেখানে অ্যাপ্লিকেশন রাষ্ট্র প্রোগ্রামারের দৃষ্টিকোণ থেকে কেবল অপরিবর্তনীয়। এটি একটি দুর্দান্ত ধারণা, তবে ভাষাটি নিজেরাই অকেজো করে দেয় Why কেন? কারণ কোনও আই / ও-অপারেশন রয়েছে ইফেক্টস ": এফপি পার্শ্ব-প্রতিক্রিয়া নিষিদ্ধ করে না, এটি যখন প্রয়োজন হয় না তখন বরং এটিগুলিকে সীমাবদ্ধ করে। যেমন (1) আই / ও -> পার্শ্ব প্রতিক্রিয়াগুলি প্রয়োজনীয়; (২) মানগুলির ক্রম থেকে একটি সামগ্রিক ফাংশন গণনা -> পার্শ্ব প্রতিক্রিয়া (যেমন সংগ্রহকারী ভেরিয়েবলের সাথে লুপের জন্য) প্রয়োজনীয় নয়।
জর্জিও

2

যে কোনও পার্শ্ব-প্রতিক্রিয়া অতিরিক্ত ইনপুট / আউটপুট পরামিতিগুলি প্রবর্তন করে যা পরীক্ষার সময় অবশ্যই গ্রহণ করা উচিত।

এটি কোডের বৈধতাটিকে আরও জটিল করে তোলে কারণ পরিবেশটি কেবলমাত্র কোডটি বৈধ হওয়াতে সীমাবদ্ধ হতে পারে না তবে আশেপাশের কিছু বা সমস্ত পরিবেশ আনতে হবে (বিশ্বব্যাপী সেই কোডটিতে জীবন আপডেট হওয়া আছে, যা পরিবর্তিত তার উপর নির্ভর করে কোড, যা পুরো জাভা ইই সার্ভারের অভ্যন্তরে বসবাসের উপর নির্ভর করে ....)

পার্শ্ব প্রতিক্রিয়া এড়ানোর চেষ্টা করে আপনি কোড চালানোর জন্য প্রয়োজনীয় বাহ্যিকতার পরিমাণ সীমাবদ্ধ করে দেন।


1

আমার অভিজ্ঞতায় অবজেক্ট ওরিয়েন্টেট প্রোগ্রামিংয়ে ভাল ডিজাইনটি এমন ফাংশনগুলির ব্যবহারের আদেশ দেয় যার পার্শ্ব প্রতিক্রিয়া রয়েছে।

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

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

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


1
আপনার অবজেক্ট যে বার্তা / ইভেন্টগুলি প্রেরণ করে সেগুলিতে সাবস্ক্রাইব করে পর্যবেক্ষকদের (ইউআই সহ) সংশোধনগুলি সম্পর্কে সন্ধান করা উচিত। এটি কোনও পার্শ্ব প্রতিক্রিয়া নয় যতক্ষণ না অবজেক্টটি সরাসরি পর্যবেক্ষককে সংশোধন করে - যা খারাপ নকশা হবে।
ক্রিসএফ

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

0

মন্দটি কিছুটা উপরে থেকে যায় .. এটি সমস্ত ভাষার ব্যবহারের প্রসঙ্গে নির্ভর করে।

ইতিমধ্যে উল্লিখিতদের আরও একটি বিবেচনা হ'ল যদি কোনও কার্যক্ষম পার্শ্ব প্রতিক্রিয়া না থাকে তবে এটি কোনও প্রোগ্রামের সঠিকতার প্রমাণকে আরও সহজ করে তোলে।


0

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

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

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

0

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

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

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

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

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

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

for each pixel in an image:
    make it red

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

for each vertex to remove in a mesh:
     start removing vertex from connected edges():
         start removing connected edges from connected faces():
             rebuild connected faces excluding edges to remove():
                  if face has less than 3 edges:
                       remove face
             remove edge
         remove vertex

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

for each vertex to remove:
     mark connected edges
for each marked edge:
     mark connected faces
for each marked face:
     remove marked edges from face
     if num_edges < 3:
          remove face

for each marked edge:
     remove edge
for each vertex to remove:
     remove vertex

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

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


-1

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


এটি পূর্বের 12 টি উত্তরগুলিতে তৈরি এবং ব্যাখ্যা করা পয়েন্টগুলির চেয়ে বেশি কিছু দেওয়ার প্রস্তাব বলে মনে হচ্ছে না
gnat
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.