"কখন এক জিনিস" দৃষ্টান্তটি ক্ষতিকারক হয়ে যায়?


21

তর্ক করার জন্য এখানে একটি নমুনা ফাংশন যা প্রদত্ত ফাইলের লাইন-বাই-লাইনের বিষয়বস্তু মুদ্রণ করে।

সংস্করণ 1:

void printFile(const string & filePath) {
  fstream file(filePath, ios::in);
  string line;
  while (std::getline(file, line)) {
    cout << line << endl;
  }
}

আমি জানি এটি প্রস্তাবিত যে ফাংশনগুলি বিমূর্ততার এক স্তরে একটি কাজ করে। আমার কাছে, যদিও উপরের কোডটি বেশ কয়েকটি কাজ করে এবং মোটামুটি পারমাণবিক।

কিছু বই (যেমন রবার্ট সি মার্টিনের ক্লিন কোড) উপরের কোডটি পৃথক ফাংশনে বিভক্ত করার পরামর্শ দেয় বলে মনে হয়।

সংস্করণ 2:

void printFile(const string & filePath) {
  fstream file(filePath, ios::in);
  printLines(file);
}

void printLines(fstream & file) {
  string line;
  while (std::getline(file, line)) {
    printLine(line);
  }
}

void printLine(const string & line) {
  cout << line << endl;
}

আমি বুঝতে পারি তারা কী অর্জন করতে চায় (ফাইল খুলুন / পঠন লাইনগুলি / মুদ্রণ লাইন) তবে এটি কি কিছুটা ওভারকিল নয়?

মূল সংস্করণটি সহজ এবং কিছু অর্থে ইতিমধ্যে একটি কাজ করে - একটি ফাইল মুদ্রণ করে।

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

এই ক্ষেত্রে কোডটি এক জায়গায় রাখাই ভাল?

"ডু ওয়ান থিং" দৃষ্টান্তটি কোন মুহুর্তে ক্ষতিকারক হয়ে ওঠে?


13
এই জাতীয় কোডিং অনুশীলনটি সর্বদা কেস কেস ভিত্তিতে থাকে। একক পন্থা কখনও হয় না।
iammilind

1
@ অ্যালেক্স - গৃহীত উত্তরটির প্রশ্নের সাথে আক্ষরিক কোনও সম্পর্ক নেই। আমি দেখতে সত্যিই অদ্ভুত।
কেওসপ্যান্ডিয়ন

2
আমি নোট করেছি যে আপনার রিফ্যাক্টর সংস্করণটি উল্টো দিকে রয়েছে, যা পাঠযোগ্যতার অভাবকে অবদান রাখে। ফাইল নিচে পড়া, তোমার সাথে দেখা করতে আশা printFile, printLines, এবং পরিশেষে printLine
অ্যান্থনি পেগ্রাম

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

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

উত্তর:


15

অবশ্যই, এটি কেবল " একটি জিনিস কী ?" লাইন এক জিনিস পড়া এবং একটি লাইন অন্য একটি লিখতে হয়? অথবা একটি ধারা থেকে অন্য স্রোতে একটি লাইন অনুলিপি করা একটি জিনিস হিসাবে বিবেচিত হচ্ছে? নাকি কোনও ফাইল অনুলিপি করছেন?

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

আইএমও কেবলমাত্র একটি একক লাইন কোড সমন্বিত একটি ক্রিয়াকলাপ সমস্যার জন্য খুব কমই কার্যকর। সরাসরি 1printLine() ব্যবহার করে আপনার কোনও সুবিধা নেই । যদি আমি দেখি , হয় হয় এটির নামটি যা বলেছিল তা আমি ধরেই নিতে পারি, বা এটি অনুসন্ধান করে দেখে নেওয়া উচিত। যদি আমি দেখি , আমি তা অবিলম্বে জানি যে এটি কী করে, কারণ এটি স্ট্রিংয়ের বিষয়বস্তুকে লাইন হিসাবে আউটপুট দেওয়ার আধ্যাত্মিক উপায় ।std::cout << line << '\n'printLine()std::cout << line << '\n'std::cout

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

void copyLines(std::istream& is, std::ostream& os)
{
  std::string line;
  while( std::getline(is, line) );
    os << line << '\n';
  }
}

এই জাতীয় অ্যালগরিদম অন্যান্য প্রসঙ্গেও পুনরায় ব্যবহার করতে পারে।

তারপরে আপনি এই এক ব্যবহারের ক্ষেত্রে সুনির্দিষ্ট সমস্ত কিছু একটি ফাংশনে রেখে দিতে পারেন যা এই জেনেরিক অ্যালগরিদমকে কল করে:

void printFile(const std::string& filePath) {
  std::ifstream file(filePath.c_str());
  printLines(file, std::cout);
}

1 নোট করুন যে আমি ব্যবহার '\n'না করে ব্যবহার করেছি std::endl'\n'একটি নতুন লাইন আউটপুট আউটপুট জন্য ডিফল্ট পছন্দ হওয়া উচিত , std::endlবিজোড় ক্ষেত্রে


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

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

1
আমি বিরোধিতা করতে চাইছিলাম না - কেবল একটি সংযোজনের পরামর্শ দেওয়ার জন্য। আমি অনুমান করি যে আমি যা বলতে ভুলে গেছি তা হ'ল, প্রশ্ন থেকে, ডেকোপস করা printLineইত্যাদি বৈধ - এগুলির প্রতিটিই একটি বিমূর্ততা - তবে এর অর্থ প্রয়োজনীয় নয় doesn't printFileইতিমধ্যে "একটি জিনিস" যদিও আপনি এটিকে তিনটি পৃথক নিম্ন স্তরের বিমূর্তিতে পচন করতে পারেন তবে বিমূর্তনের প্রতিটি সম্ভাব্য স্তরে আপনাকে পচন করতে হবে না । প্রতিটি ফাংশনে অবশ্যই "একটি জিনিস" করতে হবে, তবে প্রতিটি "একটি জিনিস" ফাংশন হওয়ার দরকার নেই। কল গ্রাফের মধ্যে খুব বেশি জটিলতা সরিয়ে নেওয়া নিজেই একটি সমস্যা হতে পারে।
স্টিভ 314

7

একটি ক্রিয়াকলাপ কেবল "এক জিনিস" করাই দুটি কাঙ্ক্ষিত প্রান্তের উপায়, Godশ্বরের কাছ থেকে আদেশ নয়:

  1. যদি আপনার ফাংশনটি কেবল "একটি জিনিস" করে, এটি আপনাকে কোড ডুপ্লিকেশন এবং এপিআই ব্লাট এড়াতে সহায়তা করবে কারণ আপনি উচ্চ-স্তরের, কম কমপোজেবল ফাংশনগুলির মিশ্রিত বিস্ফোরণের পরিবর্তে আরও জটিল কাজগুলি করতে ফাংশন রচনা করতে সক্ষম হবেন ।

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

সুতরাং, "একটি জিনিস" অনিবার্যভাবে বিষয়গত এবং এটি আপনার প্রোগ্রামের সাথে কী স্তরের বিমূর্ততা প্রাসঙ্গিক তা নির্ভর করে। যদি আপনি printLinesএকক, মৌলিক ক্রিয়াকলাপ এবং মুদ্রণ লাইনগুলির একমাত্র উপায় যা আপনার যত্ন করে বা যত্নের বিষয়ে চিন্তা করেন তবে আপনার উদ্দেশ্যে printLinesকেবল একটি কাজ করে does আপনি যদি দ্বিতীয় সংস্করণটি আরও পঠনযোগ্য না পান (তবে আমি না) প্রথম সংস্করণটি ভাল।

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


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

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

6

এই স্কেল, এটি কোন ব্যাপার না। একক-কার্যকারিতা বাস্তবায়ন পুরোপুরি সুস্পষ্ট এবং বোধগম্য। তবে, আরও কিছুটা জটিলতা যুক্ত করা থেকে ক্রিয়া থেকে পুনরাবৃত্তিকে বিভক্ত করা খুব আকর্ষণীয় করে তোলে। উদাহরণস্বরূপ, ধরুন আপনার "* .txt" এর মতো কোনও প্যাটার্ন দ্বারা নির্দিষ্ট ফাইলগুলির সেট থেকে লাইনগুলি প্রিন্ট করা দরকার। তারপরে আমি ক্রিয়া থেকে পুনরাবৃত্তি পৃথক করব:

printLines(FileSet files) {
   files.each({ 
       file -> file.eachLine({ 
           line -> printLine(line); 
       })
   })
}

এখন ফাইল পুনরাবৃত্তি পৃথকভাবে পরীক্ষা করা যেতে পারে।

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


4
আমি মনে করি আপনি এটি পেরেক দিয়েছিলেন। আমাদের যদি কোনও লাইন ব্যাখ্যা করার জন্য কোনও মন্তব্যের প্রয়োজন হয়, তবে কোনও পদ্ধতি বের করার সময় সবসময়ই আসে।
রজার সিএস ওয়ার্নারসন

5

জিনিসগুলি ব্যাখ্যা করার জন্য যখন আপনার কোনও মন্তব্যের প্রয়োজন বোধ হয় তখন পদ্ধতিগুলি নিষ্ক্রিয় করুন।

এমন পদ্ধতি লিখুন যা হয় কেবল তাদের নামটি সুস্পষ্ট উপায়ে যা বলে তা করে বা চতুরতার সাথে নামকরণ পদ্ধতিগুলিকে কল করে একটি গল্প বলে।


3

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

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

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

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


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

মন্তব্যের জন্য ধন্যবাদ. দ্রষ্টব্য আমি অকাল বিমূর্ততার পক্ষে পরামর্শ দিচ্ছি না, কেবল যৌক্তিক ক্রিয়াকলাপগুলি ভাগ করে দিচ্ছি যাতে পরবর্তী সময়ে এটি করা আরও সহজ।
মাইকেল ব্রাউন

2

আমি ব্যক্তিগতভাবে উত্তরোত্তর পদ্ধতির পছন্দ করি, কারণ এটি ভবিষ্যতে আপনার কাজকে বাঁচায় এবং "কীভাবে এটি জেনারিক উপায়ে করতে হবে" মানসিকতা জোর করে। তবুও আপনার ক্ষেত্রে সংস্করণ 1 সংস্করণ 2 এর চেয়ে ভাল - কেবল কারণ সংস্করণ 2 দ্বারা সমাধান করা সমস্যাগুলি খুব তুচ্ছ এবং fstream- নির্দিষ্ট। আমি মনে করি এটি নিম্নলিখিত পদ্ধতিতে করা উচিত (নওয়াজের প্রস্তাবিত বাগ ফিক্স সহ):

জেনেরিক ইউটিলিটি ফাংশন:

void printLine(ostream& output, const string & line) { 
    output << line << endl; 
} 

void printLines(istream& input, ostream& output) { 
    string line; 
    while (getline(input, line)) {
        printLine(output, line); 
    } 
} 

ডোমেন-নির্দিষ্ট ফাংশন:

void printFile(const string & filePath, ostream& output = std::cout) { 
    fstream file(filePath, ios::in); 
    printLines(file, output); 
} 

এখন printLinesএবং printLineকেবল সাথেই fstreamনয়, যে কোনও প্রবাহের সাথেও কাজ করতে পারে ।


2
আমি একমত নই এই printLine()ফাংশনটির কোনও মূল্য নেই। আমার উত্তর দেখুন ।
এসবিআই

1
ঠিক আছে, আমরা যদি প্রিন্টলাইন () রাখি তবে আমরা একটি সজ্জা যুক্ত করতে পারি যা লাইন নম্বর বা সিনট্যাক্স রঙ যুক্ত করে। এটি বলার পরে, আমি কোনও কারণ না পাওয়া পর্যন্ত আমি এই পদ্ধতিগুলি নিষ্কাশন করব না।
রজার সিএস ওয়ার্নারসন

2

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

এই প্রশ্নের সঠিক উত্তরটির জন্য ভবিষ্যতের ভবিষ্যদ্বাণী করার জন্য একটি ভাল ক্ষমতা প্রয়োজন, যেমন:

  • আমার এখনই করা দরকার AএবংB
  • সম্ভাব্যতাটি কী, অদূর ভবিষ্যতে আমারও করা আবশ্যক A-এবং B+(উদাহরণস্বরূপ এ এবং বি এর মতো দেখতে কিছুটা আলাদা তবে) কিছুটা আলাদা?
  • আরও বেশি ভবিষ্যতে সম্ভাবনা কী, যে এ + হবে A*বা হবে A*-?

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

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

একটি উদাহরণ হিসাবে, আমি আপনাকে এই আসল গল্পটি বলি:

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

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

এটি একটি উদাহরণ যেখানে কার্যকর চাকা ক্যাটালগ ব্যতীত "চাকা পুনরুদ্ধার করবেন না" উদাহরণটিও ক্ষতিকারক হয়ে উঠতে পারে!


2

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

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

আপনার সুন্দর এবং বেশ লিনিয়ার সামান্য ফাংশন হঠাৎ একটি জটিল জগতে শেষ হবে যা আলাদা ফাংশনে বিভক্ত হওয়ার জন্য অনুরোধ করে।


2

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

মূল পোস্ট থেকে

void printLine(const string & line) {
  cout << line << endl;
}

আপনি যদি যথেষ্ট পেডেন্টিক হন তবে আপনি লক্ষ্য করতে পারেন যে প্রিন্টলাইন এখনও দুটি কাজ করে: কৌটকে লাইনটি লিখতে এবং "শেষ রেখা" অক্ষর যুক্ত করে। কিছু লোক নতুন ফাংশন তৈরি করে এটি পরিচালনা করতে চাইতে পারে:

void printLine(const string & line) {
  reallyPrintLine(line);
  addEndLine();
}

void reallyPrintLine(const string & line) {
  cout << line;
}

void addEndLine() {
  cout << endl;
}

ওহ না, এখন আমরা সমস্যাটিকে আরও ভয়াবহ করে তুলেছি! প্রিন্টলাইনও দু'টি জিনিস করে! এটি এখন অবধারিত! 1! সর্বাধিক অযৌক্তিক "কাজের আশপাশ" তৈরি করার পক্ষে এটি খুব বেশি বোকামি তৈরি করে না যে কোনও অনিবার্য সমস্যা থেকে মুক্তি পাওয়ার জন্য কেউ কল্পনা করতে পারে যে একটি লাইন প্রিন্ট করা নিজেই লাইনটি মুদ্রণ করে এবং একটি শেষ-লাইন চরিত্র যুক্ত করে।

void printLine(const string & line) {
  for (int i=0; i<2; i++)
    reallyPrintLine(line, i);
}

void reallyPrintLine(const string & line, int action) {
  cout << (action==0?line:endl);
}

1

সংক্ষিপ্ত উত্তর ... এটি নির্ভর করে।

এটি সম্পর্কে ভাবুন: ভবিষ্যতে কী হবে যদি আপনি কেবল স্ট্যান্ডার্ড আউটপুট মুদ্রণ করতে চান না তবে কোনও ফাইল to

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

আপনি যদি নিশ্চিত হন তবে আপনার কেবল কনসোলে আউটপুট প্রয়োজন, এটি সত্যিকার অর্থে খুব বেশি বোঝা যায় না। "র‌্যাপার" ওভার লেখা cout <<অকেজো মনে হয়।


1
তবে কড়া কথায় বলতে গেলে, প্রিন্টলাইন কি লাইন ধরে পুনরুক্তি থেকে বিমূর্ততার আলাদা স্তরের কাজ করে না?

@ পিটার আমার কাছে তাই অনুমান, তাই তারা আপনাকে কার্যকারিতা পৃথক করার পরামর্শ দেয়। আমি ধারণাটি সঠিক, তবে আপনার এটি কেস-টু-কেস ভিত্তিতে প্রয়োগ করা উচিত।

1

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


0

অন্যান্য পোস্টাররা যেমন মন্তব্য করেছেন, একটি কাজ করা মাপের বিষয়।

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

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