কার্যনির্বাহী প্রোগ্রামিংয়ে অ্যাসাইনমেন্ট অপারেটর বা লুপের ব্যবহারকে নিরুৎসাহিত করা কেন?


9

যদি আমার ফাংশন দুটি প্রয়োজনের নীচে পূরণ করে তবে আমি বিশ্বাস করি যে Sum তালিকার আইটেমগুলির সত্যতা নির্ধারণ করে এমন তালিকার আইটেমগুলির সংশ্লেষ ফিরিয়ে ফাংশনটি খাঁটি ফাংশন হিসাবে উল্লেখ করার যোগ্যতা অর্জন করে, তাই না?

1) প্রদত্ত আই / পি সেট জন্য, ফাংশন বলা হওয়ার সময় নির্বিশেষে একই ও / পি ফিরিয়ে দেওয়া হবে

2) এটির কোনও পার্শ্ব প্রতিক্রিয়া নেই

public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){
    int result = 0;
    foreach(var item in numbers)
        if(predicate(item)) result += item;
    return result;
}

উদাহরণ: Sum(x=>x%2==0, new List<int> {1,2,3,4,5...100});

কারণ আমি এই প্রশ্নটি জিজ্ঞাসা করছি কারণ আমি প্রায় প্রতিটি যেখানেই লোকেরা অ্যাসাইনমেন্ট অপারেটর এবং লুপগুলি এড়াতে পরামর্শ দেয় কারণ এটি অপরিহার্য প্রোগ্রামিং শৈলী see সুতরাং ফাংশন প্রোগ্রামিংয়ের পরিপ্রেক্ষিতে লুপ এবং অ্যাসাইনমেন্ট অপারেটরের ব্যবহার করে যা উপরের উদাহরণ দিয়ে ভুল হতে পারে?


1
এটির কোনও পার্শ্ব প্রতিক্রিয়া নেই - এর পার্শ্ব প্রতিক্রিয়া রয়েছে, যখন itemলুপে পরিবর্তনশীল রূপান্তরিত হয়।
Fabio

@ ফ্যাবিও ঠিক আছে তবে আপনি কি পার্শ্ব প্রতিক্রিয়ার সুযোগটি বিশদভাবে বলতে পারেন?
রাহুলগা_দেব

উত্তর:


16

এটি কার্যকরী প্রোগ্রামিংয়ে কী এমন একটি পার্থক্য তৈরি করে?

কার্যকরী প্রোগ্রামিং নীতিগত ঘোষণা দ্বারা হয় । আপনার ফলাফল কীভাবে এটি গণনা করা যায় তার পরিবর্তে আপনি কী বলেছিলেন ।

আসুন আপনার স্নিপেটের কার্যকরী বাস্তবায়নের দিকে একবার নজর দিন। হাসকেলে এটি হবে:

predsum pred numbers = sum (filter pred numbers)

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

আপনি সম্ভবত এটি বলতে পারেন যে এটি ব্যবহার sumএবং filterএটি একটি কৌশল এবং এটি গণনা করে না। এই সাহায্যকারীদের ব্যতীত এটিকে বাস্তবায়ন করা যাক (তবে সর্বোত্তম উপায়টি হ'ল প্রথমে তাদের বাস্তবায়ন করা)।

"ফাংশনাল প্রোগ্রামিং 101" সমাধান যা ব্যবহার করে না sumতা পুনরাবৃত্তি সহ:

sum pred list = 
    case list of
        [] -> 0
        h:t -> if pred h then h + sum pred t
                         else sum pred t

এটি এখনও পুরোপুরি পরিষ্কার যে একক ফাংশন কলের ক্ষেত্রে ফলাফল কী । এটি হয় 0, বা recursive call + h or 0, নির্ভর করে pred h। তবুও বেশ সোজাভাবে, শেষের ফলাফলটি তাত্ক্ষণিকভাবে সুস্পষ্ট না হলেও (যদিও কিছুটা অনুশীলন করে এটি সত্যই forলুপের মতো পড়ে )।

এটি আপনার সংস্করণের সাথে তুলনা করুন:

public int Sum(Func<int,bool> predicate, IEnumerable<int> numbers){
    int result = 0;
    foreach(var item in numbers)
        if (predicate(item)) result += item;
    return result;
}

ফলাফলটি কি? ওহ, আমি দেখুন: একক returnবিবৃতি, কোন এখানে অবাক: return result

তবে কী result? int result = 0? ঠিক মনে হচ্ছে না। আপনি এটি পরে কিছু করুন 0। ঠিক আছে, আপনি itemএটিতে যোগ করুন । ইত্যাদি।

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

সুতরাং, ভেরিয়েবল এবং লুপগুলি কী ভুল?

না।

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

ভেরিয়েবল এবং লুপগুলি কেবল কার্যকরী প্রোগ্রামিং নয়।

সারসংক্ষেপ

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

সর্বাধিক বিস্তৃত ভাষাগুলি আপনাকে কিছু কার্যকরী নির্মাণ ব্যবহার করতে দেয়। উদাহরণস্বরূপ পাইথনে আপনি যে কোনওটি চয়ন করতে পারেন:

result = 0
for num in numbers:
    if pred(result):
        result += num
return result

অথবা

return sum(filter(pred, numbers))

অথবা

return sum(n for n in numbers if pred(n))

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


সুন্দর ব্যাখ্যা জন্য THX !!
রাহুলগা_দেব

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

1
@ ফ্রেক্স: ধন্যবাদ !! আমি এই ব্যাপারে নজর দিব। এছাড়াও সম্প্রতি মূল্যবোধের মূল্য নিয়ে রিচ হিকির আলাপ জুড়ে এসেছিল এটি সত্যই উজ্জ্বল। আমার মনে হয় একটি আঙ্গুলের নিয়ম - "মূল্যবোধের সাথে মূল্যবোধের সাথে কাজ করার পরিবর্তে মূল্যবোধ এবং
ভাবের

1
@ ফ্রেক্স: এছাড়াও এ কথা বলা ন্যায়সঙ্গত যে এফপি অপরিহার্য প্রোগ্রামিংয়ের চেয়ে বিমূর্ততা - কারণ শেষ পর্যন্ত কাউকে মেশিনকে "কীভাবে করবেন" নির্দেশ দিতে হবে, তাই না? যদি হ্যাঁ, তবে এফপির তুলনায় অত্যাবশ্যক প্রোগ্রামিংয়ের আরও কম স্তরের নিয়ন্ত্রণ নেই?
রাহুলগা_দেব

1
@ ফ্রেক্স: আমি রাহুলের সাথে একমত হব যে এই অন্তর্নিহিত মেশিনের কাছাকাছি যে দিক থেকে জরুরি তা নিম্ন স্তরের। যদি হার্ডওয়্যার বিনা মূল্যে ডেটার অনুলিপি তৈরি করতে পারে, দক্ষতা উন্নত করতে আমাদের ধ্বংসাত্মক আপডেটের প্রয়োজন হবে না। এই অর্থে, অপরিহার্য দৃষ্টান্তটি ধাতবটির কাছাকাছি।
জর্জিও

9

পরিবর্তনীয় রাষ্ট্রের ব্যবহার সাধারণত কার্যকরী প্রোগ্রামিংয়ে নিরুৎসাহিত করা হয়। লুপগুলি ফলস্বরূপ নিরুৎসাহিত করা হয়, কারণ লুপগুলি কেবল পরিবর্তনীয় অবস্থার সাথে সংমিশ্রণে কার্যকর।

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

আপনার ক্ষেত্রে, আপনি লিখতে পারেন numbers.Where(predicate).Sum()যা স্পষ্টভাবে অনেক সহজ। এবং সহজ মানে কম বাগ।


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

@ রাহুলআরওয়াল: কোন সীমা?
জ্যাকবিবি

আমি অর্থে বিভ্রান্ত হয়ে পড়েছি যদি প্রোগ্রামিং দৃষ্টান্তটি ফাংশনের দৃষ্টিকোণ থেকে গ্রাহক থেকে এফপি হিসাবে যোগ্যতা অর্জন করে? Bcoz যদি আমি বাস্তবায়ন বাস্তবায়ন তাকান Whereমধ্যে numbers.Where(predicate).Sum()- এটা ব্যবহার করে foreachলুপ।
রাহুলগা_দেব

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

7

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

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

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