খুব বেশি ব্যক্তিগত কাজ / পদ্ধতি থাকার মতো জিনিস আছে কি?


63

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

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

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

[সম্পাদনা]

লোকেরা আমাকে জিজ্ঞাসা করছে যে কেন আমি মনে করি যে অনেক বেশি কাজ করা খারাপ অভ্যাস।

সহজ উত্তর: এটি একটি অন্ত্র অনুভূতি।

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

অতীতে, আমি কেবল ব্যক্তিগত প্রকল্পগুলিই প্রোগ্রাম করে আসছি। এটি সম্প্রতি সম্প্রতি আমি টিম-ভিত্তিক প্রকল্পগুলিতে চলে এসেছি। এখন, আমি নিশ্চিত করতে চাই যে অন্যরা আমার কোডটি পড়তে এবং বুঝতে পারে।

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

সুতরাং, আমি সঠিক পথ বেছে নেওয়ার জন্য নিজেকে আলোকিত করার জন্য এটি বলছি।

[সম্পাদনা]

নীচে, আমি কীভাবে আমার সমস্যার সমাধান করতে পারি তার দুটি সংস্করণ অন্তর্ভুক্ত করেছি। প্রথমটি কোডটির বড় অংশগুলি পৃথক না করে সমাধান করে । দ্বিতীয় করে পৃথক জিনিস।

প্রথম সংস্করণ:

public static int Main()
{
    // Displays the menu.
    Console.WriteLine("Pick your option");
    Console.Writeline("[1] Input and display a polynomial");
    Console.WriteLine("[2] Add two polynomials");
    Console.WriteLine("[3] Subtract two polynomials");
    Console.WriteLine("[4] Differentiate two polynomials");
    Console.WriteLine("[0] Quit");
}

দ্বিতীয় সংস্করণ:

public static int Main()
{
    DisplayMenu();
}

private static void DisplayMenu()
{
    Console.WriteLine("Pick your option");
    Console.Writeline("[1] Input and display a polynomial");
    Console.WriteLine("[2] Add two polynomials");
    Console.WriteLine("[3] Subtract two polynomials");
    Console.WriteLine("[4] Differentiate two polynomials");
    Console.WriteLine("[0] Quit");
}

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

দ্রষ্টব্য: উপরের কোডটি সাধারণীকরণ করা হয়েছে তবে এটি আমার সমস্যার মতো প্রকৃতির।

এখন, এখানে আমার প্রশ্ন: কোনটি? আমি কি প্রথমটিকে বেছে নেব, না দ্বিতীয়টি?


1
"অনেক বেশি কাজ করা খারাপ অভ্যাস?" কেন? এটিকে কেন আপনার কাছে খারাপ মনে হচ্ছে তা বোঝাতে দয়া করে আপনার প্রশ্ন আপডেট করুন।
এস .লট

আমি 'শ্রেণীর একাত্মতা' ধারণাটি পড়ার পরামর্শ দেব - বব মার্টিন 'ক্লিন কোড' এ নিয়ে আলোচনা করেছেন।
JᴀʏMᴇᴇ

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

যদি কেউ আমাকে "এই উত্তরটি কার্যকর না কেন" বলতে পারেন, আমি কৃতজ্ঞ হব। একজন সর্বদা শিখতে পারেন। :-)
পাবলো এইচ

@ পাবলো আপনার দেওয়া উত্তরটি ওপিতে একটি ভাল পর্যবেক্ষণ এবং অন্তর্দৃষ্টি দেয়, তবে এটি যে প্রশ্নটি করা হয়েছিল তার আসলে উত্তর দেয় না। আমি এটিকে মন্তব্যে সরিয়ে নিয়েছি।
ম্যাপেল_শ্যাফ্ট

উত্তর:


36

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

এটিই এনক্যাপসুলেশন নামে পরিচিত যা উচ্চ স্তরে একটি নিয়ন্ত্রণ বিমূর্তি তৈরি করে । এটি একটি ভাল জিনিস।

এর মানে হল যে কেউ আপনার কোড পড়া, যখন তারা পেতে startTheEngine()আপনার কোডে পদ্ধতি, যেমন নিম্ন স্তরের বিস্তারিত সব উপেক্ষা করতে পারেন openIgnitionModule(), turnDistributorMotor(), sendSparksToSparkPlugs(), injectFuelIntoCylinders(), activateStarterSolenoid(), এবং অন্যান্য জটিল, ছোট, ফাংশন যে অনুক্রমে সঞ্চালন করা আবশ্যক সমস্ত অনেক বড়, আরো বিমূর্ত ফাংশন সহজতর startTheEngine()

আপনার কোডে যে সমস্যাটি আপনি মোকদ্দমা করছেন সেগুলি যদি না সরাসরি সেই উপাদানগুলির সাথে এক করে দেয় তবে কোড রক্ষণাবেক্ষণকারীরা স্যান্ডবক্সযুক্ত, এনক্যাপসুলেটেড কার্যকারিতা উপেক্ষা করে অগ্রসর হতে পারে।

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

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

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


3
সুতরাং আপনি বিশ্বাস করেন যে পুরো ক্লাসে কেবলমাত্র এক জায়গায় ডাকা হয় সেইজন্য যুক্তি সরবরাহ করা ভাল 'এনক্যাপসুলেশন' ভাল?
স্টিভেন জিউরিস

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

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

1
@ স্টিভেন - বুঝতে সহজ কী? myString.replaceAll(pattern, originalData);অথবা আমার ব্যাকিং চর অ্যারে সহ আমার কোডের পুরো প্রতিস্থাপনের সমস্ত পদ্ধতিটি আটকে দিচ্ছি যা প্রতিবার অন্তত অন্তর্নিহিত স্ট্রিং অবজেক্টটির প্রতিনিধিত্ব করে এবং যখনই স্ট্রিংয়ের কার্যকারিতাটি ব্যবহার করা দরকার?
jmort253

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

22

হ্যা এবং না. মৌলিক তত্ত্বটি হ'ল: একটি পদ্ধতিতে কেবল একটি জিনিস এবং একটি জিনিস করা উচিত

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

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


1
পড়তে ভালো লাগল সবাই অন্ধভাবে 'এক জিনিস' রুল অনুসরণ করে না! ; পি সুন্দর উত্তর!
স্টিভেন জিউরিস

16
আমি প্রায়শই একটি বৃহত পদ্ধতিকে ছোট পদ্ধতিতে বিভক্ত করি যদিও তারা কেবল বড় পদ্ধতিটিই পরিবেশন করবে। এটি ভাগ করার কারণ হ'ল এটি পরিচালনা করা এবং বোঝা সহজ হয়ে যায়, পরিবর্তে কেবল একটি বিশাল কোডের (যা স্ব-ও ভাল মন্তব্যও করতে পারে) না পেয়ে।
গ্যাবলিন

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

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

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

17

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


10

jmort253 এর দুর্দান্ত উত্তর আমাকে "হ্যাঁ, তবে" উত্তরটি অনুসরণ করতে অনুপ্রাণিত করেছে ...

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

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


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

8

প্রায়শই ওও প্রকল্পে আমি যোগদান করেছি প্রায়শই খুব বড় ক্লাসগুলির এবং খুব দীর্ঘ পদ্ধতিগুলির দ্বারা খারাপভাবে ভুগছি।

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


7

5 টি পাবলিক পদ্ধতি এবং 25 টি ব্যক্তিগত পদ্ধতি সহ একটি শ্রেণি আমার কাছে এত বড় বলে মনে হয় না। কেবল নিশ্চিত করুন যে আপনার ক্লাসগুলির সু-সংজ্ঞায়িত দায়িত্ব রয়েছে এবং পদ্ধতির সংখ্যা সম্পর্কে খুব বেশি চিন্তা করবেন না।

এটি বলেছে যে, এই ব্যক্তিগত পদ্ধতিগুলিকে পুরো টাস্কের একটি নির্দিষ্ট দিকের উপর ফোকাস করা উচিত, তবে "doSomethingPart1", "doSomethingPart2" পদ্ধতিতে নয়। যদি এই ব্যক্তিগত পদ্ধতিগুলি কেবল নির্বিচারে বিভক্ত দীর্ঘ গল্পের টুকরো হয় তবে প্রত্যেকটি পুরো প্রসঙ্গে বাইরে অর্থহীন।


+1 এর জন্য "যদি এই ব্যক্তিগত পদ্ধতিগুলি কেবল নির্বিচারে বিভক্ত দীর্ঘ গল্পের টুকরো হয় তবে প্রতিটিই পুরো প্রসঙ্গে বাইরে অর্থহীন।"
মাহদি

4

আর। মার্টিনের ক্লিন কোড থেকে উদ্ধৃত অংশ (পৃষ্ঠা 176):

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


3

কিছু বিকল্প:

  1. সেটা ঠিক আছে. আপনার ব্যক্তিগত পদ্ধতিগুলির নাম দেওয়ার পাশাপাশি কেবল ব্যক্তিগত পদ্ধতিগুলির নাম দিন। এবং আপনার সার্বজনীন পদ্ধতিগুলির নাম দিন।

  2. এই সহায়ক সহায়ক পদ্ধতিগুলির কয়েকটি হেল্পার ক্লাস বা সহায়ক মডিউলগুলিতে বিমূর্ত করুন। এবং নিশ্চিত করুন যে এই সহায়ক সহায়ক ক্লাসগুলি / মডিউলগুলি ভাল নামকরণ করেছে এবং এটি নিজের মধ্যে এবং শক্ত বিমূর্ততা।


1

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

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

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

এখানে ভারসাম্য খুঁজে পাওয়া প্রকল্প এবং তার প্রয়োজনীয়তার উপর নির্ভর করে। এর পাল্টা যুক্তিটি হ'ল একটি জুনিয়র প্রোগ্রামার 50 টি কোড লাইনের কোডটি সমাধান করতে পারে যা কোনও স্থপতি 50 ক্লাস নেয়।


0

খুব বেশি ব্যক্তিগত কাজ / পদ্ধতি থাকার মতো জিনিস আছে কি?

হ্যাঁ.

পাইথনে "প্রাইভেট" ধারণাটি (সি ++, জাভা এবং সি # হিসাবে ব্যবহৃত) সত্যই বিদ্যমান নেই।

নামকরণের একটি "সাজ্ট-অফ-প্রাইভেট" আছে, তবে এটি।

ব্যক্তিগত পরীক্ষা-নিরীক্ষার কোডের দিকে নিয়ে যেতে পারে। এটি কোডকে সহজভাবে বন্ধ করে "ওপেন-ক্লোজড প্রিন্সিপাল" ভেঙে ফেলতে পারে।

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


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