আমার ক্লাস এবং পদ্ধতিগুলি যতটা সম্ভব ছোট রাখুন?


20

কিছু দিন আগে, আমি একটি সফটওয়্যার ইঞ্জিনিয়ারিং পিএইচডি পরীক্ষার্থীর সাথে কথা বলছিলাম এবং এক পর্যায়ে তিনি আমাকে বললেন:

আপনার ক্লাস এবং পদ্ধতিগুলি যতটা সম্ভব ছোট রাখুন

এবং আমি ভাবছি যদি এটি সর্বদা একটি ভাল অনুশীলন হয়।

আমি উদাহরণস্বরূপ বোঝাতে চাইছি, এটিতে কেবল মাত্র 2 টি আটিবিটস সহ কোনও শ্রেণি রাখা কি উপযুক্ত? উদাহরণস্বরূপ, কিছু পদ্ধতিতে আমার সাথে কাজ করার জন্য জোড়া জোড়া পূর্ণসংখ্যার প্রয়োজন। আমি কি "PairOfIntgers" ক্লাস লিখব?

এই উপায়টি কি খুব বেশি টুকরোয় কোডটি "ভাঙ্গতে" পারে?


10
এটি হওয়া উচিত"As small as possible, but no smaller."
স্টুপারউসার

"আমি উদাহরণস্বরূপ বলতে চাইছি, এটিতে কেবল মাত্র 2 টি আটিবিটস সহ কোনও শ্রেণি রাখা কি উপযুক্ত?" - এটি হতে পারে "প্রিমিটিভ অবসেশন" (যেমন jamesshore.com/Blog/PrimitiveObsession.html ) অনুসন্ধান করুন
টর্স্টেন

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

উত্তর:


23

সেই পরামর্শে সত্যের দানা রয়েছে, তবে আইএমএইচও এটি খুব ভালভাবে প্রকাশিত হয় না, সুতরাং ভুল বোঝাবুঝি করা এবং / অথবা একটি নির্বোধ চরম গ্রহণ করা সহজ। যে কোনও হারে, এটি কঠোর আইন না করে থাম্বের নিয়ম হওয়া উচিত। এবং আপনার এই জাতীয় নিয়মে সর্বদা "যুক্তিসঙ্গত সীমার মধ্যে" ধারাটি বোঝানো উচিত , বা "তবে আপনার সাধারণ জ্ঞানটি ব্যবহার করতে ভুলবেন না" :-)

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


1
অন্ধভাবে অনুসরণ না করার একটি নিয়ম, খুব অনেক ক্ষুদ্র ক্লাস বেশিরভাগ সময় কয়েকটি বৃহত্তর শ্রেণীর চেয়ে অনেক খারাপ।
রায়থাল

4
আমার থাম্বের ব্যক্তিগত নিয়মটি হল: আপনি যদি স্ক্রিনে একবারে কোনও সম্পূর্ণ পদ্ধতি বাস্তবায়ন দেখতে না পান তবে রিফ্যাক্টর।
ড্যান রে

6
@ ড্যানরে, হ্যাঁ, ক্লিন কোড না পড়া পর্যন্ত আমার একই নিয়ম ছিল । এটি বেশ ধাক্কা খেয়েছিল, তবে ধীরে ধীরে আমার সর্বোত্তমটিকে প্রায় 10 লাইনে নামিয়েছে।
পিটার তারেক

2
আইএমও ক্লিন কোড ছোট পদ্ধতির প্রতি তার চরমপন্থায় ভয়ঙ্কর। সমস্যাটি হ'ল যখন পদ্ধতিগুলি ছোট করা হয়, তখন সেগুলির আরও অনেক কিছু থাকবে। অবশ্যই খুব দীর্ঘ পদ্ধতিগুলি খুব দীর্ঘ, তবে বব মার্টিন 10 10-লাইন একের বেশি 10 টি 1-লাইন পদ্ধতি পছন্দ করে বলে মনে হচ্ছে (এইভাবে কার্যকরভাবে একই কোডটি প্রায় 5x যত বেশি পর্দার স্থান গ্রহণ করে) taking হতে পারে এটি কোনও ধরণের শিক্ষামূলক কৌশল হিসাবে বোঝানো হয়েছে, আমি বিশ্বাস করতে পারি না যে কেউ কেউ এই বইয়ের কোডটি কোনও ভাল বলে মনে করে।
জুনাস পুলক্কা

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

9

এখানে চাপ দেওয়ার জন্য আরও গুরুত্বপূর্ণ সমস্যাটি হ'ল ভাল বিমূর্ততা তৈরি করছে । যে ছোট ছোট ক্লাসগুলি আলগাভাবে মিলিত হয় এবং উচ্চ সংহতি থাকে সেগুলি ভাল বিমূর্তনের পণ্য

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

এক্ষেত্রে একটি শ্রেণি তৈরি করার জন্য আর একটি ইতিবাচক বিষয় হ'ল মানচিত্র বা তালিকার মতো নিম্ন স্তরের ডেটা স্ট্রাকচারটি বলার চেয়ে ক্লাসটি অনেক ভাল / সুন্দরভাবে বিকশিত হতে পারে।

তৃতীয়ত, একটি ভাল বিমূর্ততা পঠনযোগ্যতা একটি মহান চুক্তি উন্নতি করতে পারে। যে ক্লাসগুলি এসআরপি মেনে চলে সেগুলি সাধারণত এমন কোনও শ্রেণীর চেয়ে বেশি সহজে বোঝা যায় যেগুলি ক্লাসে নেই।

এবং কেবল একটি চূড়ান্ত নোট হিসাবে ... আপনি যত শিক্ষার্থীই হন না কেন ... ওওপি এবং ভাল বিমূর্ততা বুঝতে এবং সেগুলি কখন ব্যবহার করবেন তা আপনার অভিজ্ঞতার প্রয়োজন। আপনার খারাপ কোড লিখতে হবে এবং এটি বজায় রাখতে ব্যথাটি অতিক্রম করতে হবে। 'ভাল' কী এবং আপনার লাইনে কী সমস্যা হবে সে সম্পর্কে আপনার জ্ঞান তৈরির জন্য আপনাকে অন্যদের ভাল কোড লিখতে দেখা দরকার ... সুতরাং আপনি যদি এখনই তা না পান তবে নিজেকে হারাবেন না।


2

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


2

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

আপনার ক্লাস ছোট রাখার চেষ্টা করুন। এবং পদ্ধতি আরও ছোট। 10 লাইন হতে পারে?!? বর্তমানে আমি প্রবাহের নকশা এবং ইভেন্ট ভিত্তিক উপাদানগুলি ব্যবহার করার চেষ্টা করছি যা মনে হয় ক্লাসগুলি ছোট রাখতে সহায়তা করে। প্রথম আমি অনেক ক্লাসে উঠতে উদ্বিগ্ন ছিলাম তবে এটি সত্যিই কাজ করে !!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx


2

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

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


0

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

আমি যখন আমার কোড দেখি তখন জানতে পারি কোনও পদ্ধতি খুব বড় কিনা। যদি এটি খুব বেশি করে কাজ করে এবং পড়তে খুব কষ্ট হয় তবে এটি রিফ্যাক্টর সময়।

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

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


কখনও এসআরপি অনুসরণ পদ্ধতিগুলি ছোট করবেন না এবং এটি স্বয়ংক্রিয়ভাবে কাজটি করবে।
বিনয় প্রজাপতি

0

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

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

এবং ছোট ক্লাসগুলি বোঝা সর্বদা সহজ। এগিয়ে যান, "ক্লিন কোড" পড়ুন

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