যে ক্রিয়াকলাপগুলি কেবলমাত্র অন্য ফাংশনগুলিকে কল করে। এটি কি একটি ভাল অনুশীলন?


13

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

DataTable reportTable = new DataTable();
void RunReport()
{
    reportTable = DataClass.getReportData();
    largeReportProcessingFunction();
    outputReportToUser();
}

আমি এই বৃহত ফাংশনগুলি ছোট ছোট ভাণ্ডারে ভাঙতে সক্ষম হতে চাই, তবে আমি ভয় পাচ্ছি যে আমি কয়েক ডজন অ-পুনঃব্যবহারযোগ্য ফাংশনগুলি শেষ করব এবং একই কাজ "এখানে সমস্ত কিছু করব" যার একমাত্র কাজ function এই সমস্ত ছোট ফাংশন কল করুন, যেমন:

void largeReportProcessingFunction()
{
    processSection1HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    processSection1SummaryTableData();
    calculateSection1SummaryTableTotalRow();
    formatSection1SummaryTableDisplay();
    processSection1FooterData();
    getSection1FooterSummaryTotals();
    formatSection1FooterDisplay();

    processSection2HeaderData();
    calculateSection1HeaderAverages();
    formatSection1HeaderDisplay();
    calculateSection1HeaderAverages();
    ...
}

বা, যদি আমরা আরও এক ধাপ এগিয়ে যাই:

void largeReportProcessingFunction()
{
    callAllSection1Functions();

    callAllSection2Functions();

    callAllSection3Functions();
    ...        
}

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

থটস?


দিন শেষে ... এটা কি আরও বেশি পঠনযোগ্য? হ্যাঁ, সুতরাং এটি আরও ভাল সমাধান।
sylvanaar

উত্তর:


18

এটি সাধারণত ফাংশনাল পচন হিসাবে উল্লেখ করা হয় এবং সঠিকভাবে করা হলে সাধারণত এটি করা ভাল।

এছাড়াও, কোনও ক্রিয়াকলাপ বাস্তবায়ন বিমূর্ততার একক স্তরের মধ্যে হওয়া উচিত। আপনি যদি গ্রহণ করেন largeReportProcessingFunction, তবে এর ভূমিকাটি নির্ধারণ করা হ'ল কোন ক্রমে কোন প্রক্রিয়াকরণ পদক্ষেপ নেওয়া উচিত। এই প্রতিটি পদক্ষেপের বাস্তবায়ন নীচে বিমূর্ত স্তরতে রয়েছে এবং largeReportProcessingFunctionএটি সরাসরি নির্ভর করে না।

দয়া করে মনে রাখবেন যে এটি নামকরণের একটি খারাপ পছন্দ:

void largeReportProcessingFunction() {
    callAllSection1Functions();
    callAllSection2Functions();
    callAllSection3Functions();
    ...        
}

আপনি দেখতে পাচ্ছেন callAllSection1Functionsএমন একটি নাম যা আসলে কোনও বিমূর্ততা সরবরাহ করে না, কারণ এটি আসলে কী করে তা বলে না, বরং এটি কীভাবে এটি করে। processSection1পরিবর্তে বা প্রসঙ্গে আসলে যা অর্থপূর্ণ তা বলা উচিত ।


6
আমি এই উত্তরটির সাথে মূলত একমত, আমি "প্রসেসসেকশন 1" কীভাবে অর্থবহ নাম তা দেখতে পাচ্ছি না except এটি কার্যত "কলআলসেকশন 1 ফাংশনস" এর সমতুল্য।
এরিক কিং

2
@ এরিকিং: callAllSection1Functionsবাস্তবায়ন সম্পর্কে বিশদটি ফাঁস করেছে। বাহ্যিক দৃষ্টিকোণ থেকে, এটি processSection1তার কাজটিকে "সমস্ত বিভাগ 1 ফাংশন" থেকে স্থিত করে বা সরাসরি তা করে কিনা বা প্রকৃত কাজটি করবে এমন একটি ইউনিকর্ন ডেকে পিক্সি-ডাস্ট ব্যবহার করে কিনা তা বিবেচনা করে না। সব সত্যিই ব্যাপার যে, যে পরে একটি কল processSection1, section1 বিবেচনা করা যেতে পারে প্রক্রিয়া । আমি সম্মত হই যে প্রক্রিয়াকরণ একটি জেনেরিক নাম, তবে আপনার যদি উচ্চ সংহতি থাকে (যার জন্য আপনার সর্বদা চেষ্টা করা উচিত) তবে আপনার প্রসঙ্গটি সাধারণত এটি সঙ্কুচিত করার পক্ষে যথেষ্ট সংকীর্ণ।
back2dos

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

4

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

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


3

এটা নির্ভর করে. আপনার তৈরি করা সমস্ত ফাংশন যদি সত্যই কাজের একক ইউনিট হয় তবে তা ঠিক আছে, যদি সেগুলি কেবল তাদের কলিং ফাংশনের 1-15, 16-30, 31-45 এর লাইনে থাকে তবে এটি খারাপ। দীর্ঘ ফাংশনগুলি খারাপ নয়, যদি তারা একটি কাজ করে, আপনার প্রতিবেদনটির একটি বৈধতাযুক্ত ফাংশন থাকার জন্য যদি আপনার 20 টি ফিল্টার থাকে তবে সমস্ত বিশটি পরীক্ষা করা দীর্ঘ হতে চলেছে। এটি ঠিক আছে, ফিল্টার বা ফিল্টারগুলির গ্রুপ দ্বারা এটি ভেঙে দেওয়া কোনও আসল সুবিধার জন্য কেবল অতিরিক্ত জটিলতা যুক্ত করছে।

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


3
আমার অভিজ্ঞতা, দীর্ঘ ফাংশন হয় মন্দ।
বার্নার্ড

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

3

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

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

আপনি রিপোর্টের ডেটাতে পাস করতে পারেন এমন রিপোর্টবিল্ডার ক্লাস থাকার কথা বিবেচনা করুন। আপনি যদি রিপোর্টবিল্ডারকে পৃথক শ্রেণিতে বিভক্ত করতে পারেন তবে এটিও করুন।


2
পদ্ধতিগুলি পুরোপুরি ভাল ফাংশন দেয় serve
ডেড এমএমজি

1

হ্যাঁ.

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

বর্ণনামূলক পদ্ধতির নাম ব্যবহার করা হলে এটি পদ্ধতিটিকে আরও পঠনযোগ্য করে তুলতে সহায়তা করে।


1

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

processSection1HeaderData();
processSection2HeaderData();

বিভাগের শিরোলেখগুলি প্রসেস করতে ব্যবহৃত কোডে কোনও মিল নেই কি? পার্থক্যগুলিকে প্যারামিটারাইজ করে আপনি কি উভয়ের জন্য একটি সাধারণ ফাংশন নিষ্কাশন করতে পারেন?


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

1

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

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


0

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

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


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

1
প্রস্তাবিত অঞ্চলগুলি বাদে +1। আমি অঞ্চলগুলি ব্যবহার করব না।
বার্নার্ড

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

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

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