শ্রেণি পদ্ধতির সংখ্যার সীমা কত?


22

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

একটি প্রকল্পে আমি একটি শ্রেণি "নোট" বিকাশ করি, যার বৈশিষ্ট্য হিসাবে তার বৈশিষ্ট্য: শিরোনাম, বিবরণ, ক্রিয়েটডিট ইত্যাদি
Then

তবে অ্যাপ্লিকেশনটির বিকাশের ক্ষেত্রে আরও কার্যকারিতা প্রয়োজন ছিল, এবং তাই আরও পদ্ধতি।

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

আমি সম্মতি দিচ্ছি যে 15 টিরও বেশি পদ্ধতি রয়েছে, তবে সম্ভবত কিছুটা নতুন নকশার প্রয়োজন হতে পারে।
তবে সেই ক্ষেত্রেও যদি কিছু পদ্ধতি বা উত্তরাধিকার মুছে ফেলা কোনও বিকল্প না হয় তবে সঠিক উপায়টি কী হবে?


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


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


উত্তর:


30

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


সঠিক, তবে এটি যদি কোনও ইউটিলিটি ক্লাস হয় তবে 10-15 অবধি ঠিক আছে।
সিড

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

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

13

উত্তরটি সত্যিই সহজ: প্রতিটি শ্রেণীর মধ্যে যা তার দায়িত্বগুলির সাথে সম্পর্কিত তা রাখুন, তবে দায়িত্ব অর্পণ করার সময় সাবধানতা অবলম্বন করুন।

কখনও কখনও একটি বড় শ্রেণি বিভিন্ন দায়িত্ব সহ ছোট শ্রেণীর সমন্বিত।

সাধারণভাবে, আমি যখন ক্লাসটি ব্যবহারের ক্ষেত্রে বা রক্ষণাবেক্ষণে অনর্থক হয়ে পড়ে তখন দায়িত্বগুলি ছোট শ্রেণিতে ভাগ করার চেষ্টা করি। আমার খুব কমই ক্লাস রয়েছে যা 500 লাইনের চেয়ে দীর্ঘ are আমার বৃহত্তম ক্লাসে প্রায় 1.5k লোকস রয়েছে।

আপনি কেবল একটি সাধারণ নিয়মের মতো বলতে পারবেন না যেমন "ক্লাসের n এবং m পদ্ধতির মধ্যে থাকা উচিত"।


8

কেবলমাত্র এতগুলি পদ্ধতি থাকার কোনও কারণ নেই (ওও ডিজাইনে)। এটিও সত্য নয় যে কম পদ্ধতিযুক্ত একটি শ্রেণি আরও ভাল ডিকোপলড।

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

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


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

@ লুকা: এই কয়েকটি বইয়ের সমস্যা হ'ল উদাহরণগুলি প্রায়শই সংক্ষিপ্ত হয় এবং তাই অনেক বাস্তব-বিশ্বের উদাহরণগুলির চেয়ে ছোট।
হতাশ

ঠিক ... সম্ভবত বেশিরভাগের জন্য ধারণাটি আরও পরিষ্কার করা এবং ক্রেতাদের সম্ভাব্য ভিত্তিকে আরও বাড়িয়ে তোলা ...
ফ্রান্সেস্কো

আমি কেবল 15 টি পদ্ধতির সাথে কোনও ধরণের ডেটাগ্রিড বা এমনকি ইউআই নিয়ন্ত্রণ দেখতে চাই। আপনি যদি এই ক্লাসগুলি ছোট ছোট করে ফেলে থাকেন তবে ইন্টারফেসটি একটি দুঃস্বপ্ন হয়ে যাবে।
ফ্যালকন

6

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

কিছুটা কংক্রিটের মতো কিছু হ'ল 7 প্লাস / বিয়োগ 2 নিয়ম । এটি বলে যে মানব মন 5 এবং 9 "অবজেক্ট" স্মৃতিতে ধরে রাখতে এবং বুঝতে পারে। কোনও নির্দিষ্ট বর্গ পড়ার সময় অবজেক্টগুলি সম্ভবত সেই শ্রেণিটি তৈরির পদ্ধতি এবং ক্ষেত্রগুলি হতে পারে। যাইহোক, ক্লাস ঘন ঘন, আরো 9২ ক্ষেত্র এবং পদ্ধতি আছে এমনকি আপনি যদি accessors, mutators এবং কোন মান অপারেশন গণনা করা হয় না (উদাহরণস্বরূপ, toString(), hashCode(), এবং equals()জাভা)।

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


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