.NET এ ফাইলের জন্য প্রতিটি শ্রেণি নিয়ম? [বন্ধ]

Question

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

আর একটি যুক্তি যা আমি সারাক্ষণ শুনি তা হ'ল "এমনকি মাইক্রোসফ্টও এটি করে না, তবে আমাদের কেন করা উচিত?"

এ সম্পর্কে সাধারণ What'sকমত্য কী? এমন কিছু ঘটনা রয়েছে যেখানে এড়ানো উচিত?

Comments

আলাদা ফাইলগুলিতে সি # ক্লাসের

আরও দেখুন: প্রোগ্রামারস.স্ট্যাকেক্সচেঞ্জ

— প্রশ্নগুলি / 121365/…

Answer 1

প্রতি ফাইলের জন্য একটি শ্রেণি আপনাকে ফাইলের বিভিন্নতা না দেখে প্রতিটি চেক ইন কী পরিবর্তন হয় সে সম্পর্কে আরও ভাল ধারণা দেয়।

Comments

একই ফাইলে আরও ক্লাস কেবল একটি ক্রিয়ায় সম্পর্কিত শ্রেণীর মধ্যে পার্থক্য বাড়ায়।

— লুকা

যথাযথ পৃথক দর্শক আপনাকে একটি প্রতিশ্রুতিবদ্ধতার সমস্ত ভিন্নতা দেখতে দেয়।

— ডায়কাম

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

— রবার্ট ডেভিস

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

— abombss

Answer 2

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

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

আমি কেন প্রতি ফাইলটিতে একাধিক ক্লাস চাইতে পারি তার একটি দুর্দান্ত উদাহরণ:

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

Comments

+1.000। সেরা অনুশীলনের যৌক্তিকতা বোঝা এবং সেগুলি লঙ্ঘনের আগে দুবার চিন্তা করা দুর্দান্ত। দাসত্ব মেনে চলা মন্দ।

— dsimcha

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

— জেফ স্টার্নাল

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

— জেমস

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

— শ্রেণিই

প্রতি ফাইলের জন্য একটি শ্রেণি রাখা এবং ফাইলের নাম এবং শ্রেণীর নাম সিঙ্কে রাখা একটি কনভেনশন, ঠিক যেমন ভেরিয়েবলের নামকরণ। এই পদ্ধতির জন্য ভিজ্যুয়াল স্টুডিও খুব ভালভাবে সুরযুক্ত। উত্স নিয়ন্ত্রণ সিস্টেম এবং বিকাশকারীদের জন্য যা প্রকল্পের মাঝখানে যুক্ত করা সহজ for তারা শ্রেণীর নামের সাথে মেলে ফাইলের নামটি স্বজ্ঞাতভাবে অনুসন্ধান করবে।

— ওয়বিক

Answer 3

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Comments

.NET- তে কি এমন কোনও নিয়ম আছে? আমিও আমি কেবল বিবৃতি ফলাফল ফিরিয়ে দিতে হবে। : ও

— জোয়ান ওয়েঙ্গেজ

Answer 4

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

সাধারণ 'সেরা অনুশীলন' প্রতি ক্লাসে একটি ফাইল থাকতে হয়।

Comments

যদি আপনি স্বীকার করেন যে তারা একত্রে আছেন, তবে কেন আপনি তাদের ডুপিয়ে দিচ্ছেন না?

— ম্যাট

@ ম্যাট: এটিকে অত্যধিক ওষুধ এড়ানো বলা হয়। আপনার যদি কয়েকটি দৃly়ভাবে দম্পতিযুক্ত ক্লাস থাকে এবং সেগুলি ডিকপলিং করে এটি যে পরিমাণে ব্যবহারিক নমনীয়তার পরিমাণ সরবরাহ করে তার তুলনায় অনেক জটিলতা যুক্ত করে, তবে কী কথা?

— dsimcha

কখনও কখনও আমার কাছে মূলত "ডেটা" ক্লাস থাকে যা কেবলমাত্র এই এক শ্রেণীর দ্বারা ব্যবহৃত হয়, তাই আমি সাধারণত ডেটা-ক্লাসটি ব্যবহারকারীর মতো একই ফাইলে রাখি কারণ ডেটাক-লাসের সাধারণত কোনও যুক্তিই কম থাকে এবং এটি মনে হয় এটির মতো এটির জন্য একটি নতুন ফাইল তৈরি করতে বর্জ্য।

— আর্লজ

@ ম্যাট: কখনও কখনও সহায়ক ক্লাস থাকে যা আমি যুক্ত-গ্রহণযোগ্য হিসাবে তর্ক করব। তারা অন্য শ্রেণীর অংশের জন্য জটিলতা হ্রাস করে তবে এখনও সেই শ্রেণীর খুব নির্দিষ্ট উদ্দেশ্যকে সহজ করে দেয়।

— জর্দান পারমার

@TheMatt: decouple এই: msdn.microsoft.com/en-us/library/... মডিউল মধ্যে সংযোগ খারাপ, কিন্তু একটি লজিক্যাল বৈশিষ্ট্য মধ্যে শ্রেণীর মধ্যে সহযোগিতা এড়ানো সম্ভব নয়।

— বেন ভয়েগট

Answer 5

অনুমানমূলক যুক্তি ছাড়াই এবং উইন্ডোজ .NET- এ ভিজ্যুয়াল স্টুডিও আইডিই এবং ক্রমবর্ধমান সফ্টওয়্যার প্রকল্পগুলির সাথে ফোকাস করা, এই ফাইলটি প্রতি এক শ্রেণির জন্য কেবল এই প্রসঙ্গেই বোধ করা যায়।

---

সাধারণভাবে, ভিজ্যুয়াল রেফারেন্সের জন্য কিছুই প্রতি ফাইলের জন্য এক শ্রেণিতে মারধর করে না। সত্যিই।

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

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

class BicycleWheel {
    class WheelSpoke {
    }
}

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

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

অনেক ভাল কারণ ...

Comments

ধন্যবাদ, "তাদের অন্তত প্রথম অংশগুলি" বলতে কী বোঝ? মানে আপনি নেস্টেড ক্লাসও আলাদা করতে পারবেন?

— জোয়ান ভেঞ্জে

আমি যে partialকীওয়ার্ডটি উল্লেখ করেছি তার একটি পরোক্ষ রেফারেন্স ।

— জন কে

রেকর্ডের জন্য নেস্টেড ক্লাসগুলি partial এমএসডিএন.মাইক্রোসফটকম /en-us/library/wa80x488(VS.80).aspx হতে পারে আমি এটিকে কৌতূহলের বাইরে দেখলাম।

— জন কে

এটি কেবল এটি দেখানোর জন্য যায় যে ডিফল্ট দৃশ্যটি লজিক্যাল (নেমস্পেস / শ্রেণি) হওয়া উচিত এবং শারীরিক (ফাইল) নয়।

— ডেভিড স্মিট

@ ডেভিডস্মিটটি ভিজ্যুয়াল স্টুডিওতে ক্লাস ভিউ এর জন্য যা।

— জ্যাক

Answer 6

বেশিরভাগ ক্ষেত্রে, আমি ফাইলের বিধি অনুসারে একটি শ্রেণি অনুসরণ করি। আমি নিয়মিত একমাত্র ব্যতিক্রম হ'ল একটি এনামের সংজ্ঞা যা দৃ specific়ভাবে নির্দিষ্ট শ্রেণীর সাথে মিলিত হয়। সেই এক ক্ষেত্রে, আমি প্রায়শই সেই শ্রেণীর ফাইলটিতে এনামের সংজ্ঞাটি অন্তর্ভুক্ত করব।

Answer 7

আমিও বিশ্বাস করি যে কোনও একক ফাইলের মধ্যে এক ধরণের অন্তর্ভুক্ত থাকা উচিত।

এই নিয়মের একটি ব্যতিক্রম রয়েছে যা অবশ্যই উল্লেখ করতে হবে: দুটি শ্রেণি রয়েছে যা কেবল একটি জেনেরিক যুক্তির দ্বারা পৃথক হয় যেমন:

RelayCommand     

এবং

RelayCommand<T>

Comments

এক্ষেত্রে স্টাইলকপকে সুখী করার জন্য আপনি কি কাজটি জানেন?

— জর্জ পোলেভয়

অসম্মতি, জেনেরিক ক্লাসগুলির জন্য আরও একটি কনভেনশন রয়েছে, ফু 1.cs for ফু <T> `এবং ফু 2.cs for ফু <টি, টি 1>` `

— ওবাইক

@ ওবাইক: আমার কাছে যদি ফু <টি>, ফু <ইউ> এবং ফু <ইউ, টি> থাকে? এখন কি?

— আন্দ্রে রিনিয়া

@ আন্ড্রেইরাইনাহা: একই নামস্থান Foo<T>এবং এর Foo<U>মধ্যে থাকা অসম্ভব । তবে নামের জায়গাগুলি পৃথক হলে এগুলি সাধারণত বিভিন্ন ফোল্ডারে থাকে। সুতরাং এটির জন্য Foo<T>এবং Foo<U>এটি ফু 1.cs and for ফু <ইউ, টি> `Foo`2.cs হওয়া উচিত। তবে এখনও ফাইল প্রতি এক শ্রেণি।

— ওয়বিক

তথ্যটির জন্য আপনাকে ধন্যবাদ! :)

— আন্দ্রে রেনিয়া

Answer 8

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

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

Comments

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

— জেফ স্টার্নাল

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

— জেসন এম

Answer 9

বিষয়বস্তুটি যতই হালকা হউক না কেন, আমি মনে করি ফাইল প্রতি ফাইলের জন্য একটি শ্রেণি / ইন্টারফেস / ইত্যাদি প্রয়োজনীয়।

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

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

Answer 10

আমি দেখতে পেয়েছি যে একই ফাইলে এটি স্ট্যান্ডার্ড কারখানার শ্রেণীর সাথে শ্রেণিভুক্ত করা খুব দরকারী।

Answer 11

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

সুতরাং কথাটি হ'ল: বিচক্ষণতা ব্যবহার করা উচিত !!!

Comments

সত্য জ্ঞান, প্রোগ্রামিংয়ের কোনও নিয়ম কঠোর এবং দ্রুত নয়।

— কেওসপ্যান্ডিয়ন

Answer 12

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

Comments

রিশার্পারের মতো সরঞ্জামগুলির সাথে আমি এই যুক্তিটিকে কম মূল্যবান বলে মনে করি। আমি সিটিআরএল + টি করি এবং আমি যে ধরণের সন্ধান করছি তার নাম টাইপ করা শুরু করুন।

— মার্ক

হ্যাঁ, তবে আপনি কি চান আপনার অ্যাপ্লিকেশন কাঠামো কোনও তৃতীয় পক্ষের সরঞ্জামের উপর নির্ভরশীল?

— চৌম্বকটি

@ ম্যাগনাস আমি বলছিলাম না এটি না করার কারণ নয়, তবে কারও পক্ষে এটি করার পক্ষে যুক্তি কম জোর করা উচিত।

— চিহ্নিত করুন

Answer 13

সি # এর স্টাইলকপ সরঞ্জামটির স্ট্যান্ডার্ড বিধি রয়েছে যার জন্য একটি নেমস্পেসে একাধিক শীর্ষ স্তরের শ্রেণি প্রয়োজন হয় না (প্লাস্টিকের সেই নামস্থানে কোনও সংখ্যক ইন্টারফেস, প্রতিনিধি এবং এনাম)।

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

Comments

আপনি যখন "এক নামস্থানে একাধিক শীর্ষ স্তরের শ্রেণি" বলেন না, আপনি একটি namespaceব্লকে বোঝাচ্ছেন , তাই না?

— ড্যানিয়েল প্রাইডেন

SA1403 হিসাবে নির্দেশিত বিধিগুলি: এসি # নথিতে কেবলমাত্র একটি একক নেমস্পেস থাকতে পারে। SA1402: এসি # নথিটিতে কেবলমাত্র স্তরের একক শ্রেণী থাকতে পারে যতক্ষণ না সমস্ত ক্লাসের সমস্ত বিভাগ আংশিক এবং একই ধরণের হয়।

— স্টিভ গিলহাম

Answer 14

ফাইলের জন্য এক সময় এক শ্রেণি, তবে ...

যখন একাধিক ক্লাস কঠোরভাবে সম্পর্কিত হয়, একই ক্লাসে সংক্ষিপ্ত উত্স ফাইলটি উত্সর্গ করার চেয়ে একই উত্স ফাইলে একাধিক শ্রেণি হয়, আইএমএইচও, ভাল । উত্সটি আরও পঠনযোগ্য এবং কমপ্যাক্ট (এবং #region ব্যবহার করে একই উত্সটি আগের তুলনায় আরও কাঠামোগত হতে পারে)।

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

Comments

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

— পিটার

যদি আপনি উত্স কোড উত্পন্ন করার চেষ্টা করেন (আমার কেসটি ওপেনগিএলটির স্পেসিফিকেশন থেকে সি # বাইন্ডিংয়ের প্রজন্ম, যার হাজার হাজার এন্ট্রি পয়েন্ট রয়েছে) প্রচুর পরিমাণে ডেটার জন্য একটি সামান্য শ্রেণি ভাবা কঠিন ...

— লুকা

Answer 15

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

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

অর্থাত।

• সোমবার আমি আমার ক্লাসে x এবং y ফাইল y.css এ পরিবর্তন করি
• মঙ্গলবার আমি x এর নিজস্ব ফাইল x.css এ ক্লাস এক্স আলাদা করি কারণ এটি বড় হয়েছে
• বুধবার আমার বস সোমবার x ক্লাসে কী বদলেছে তা দেখতে চায় তাই তিনি x.css এর ইতিহাসের দিকে তাকান, কেবল x.css মঙ্গলবারের পরিবর্তনের আগে ইতিহাস দেখায় না।

Comments

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

— সুপারক্যাট

আমি ক্লাস করব যে এটি একটি very tightly relatedশ্রেণি হিসাবে এবং এটিকে রেখে দেওয়া যদি এটি কেবলমাত্র একটি স্বল্প পরিমাণে পর্দার স্থান নেয় এবং অন্য কোনও শ্রেণীর দ্বারা একই উদ্দেশ্যে ব্যবহৃত হয় না।

— জিঞ্জারব্রেডবয়

Answer 16

আসলেই কি সমস্যা? :)
সত্যই ছোট্ট ক্লাসগুলি যেমন এনামদের মতো অন্যদের সাথেও করা যায়। অনুসরণ করার একটি নিয়ম রয়েছে: কেবল এমন কিছু ক্লাস একসাথে রাখুন যাতে কিছু মিল থাকে।

একটি বিচ্যুতি হিসাবে - আমার একটি প্রকল্পে আমার একটি ফাইল আছে যার ভিতরে 150 ক্লাস রয়েছে। ফাইলটিতে কোডের 10000 লাইন রয়েছে। তবে এটি স্বয়ংক্রিয়ভাবে উত্পন্ন তাই এটি সম্পূর্ণ গ্রহণযোগ্য :)

Comments

আমার অর্ধ মিলিয়ন লাইনের সাথে 120 টি ক্লাস এবং 750 সাবক্লাসের একই ফাইল রয়েছে এটি স্বয়ংক্রিয়ভাবে তৈরি is সমস্যাটি হ'ল: আমি যদি এটিতে ক্লিক করি তবে আমাকে অবশ্যই পুনরায় বুট করতে হবে কারণ সবকিছু বন্ধ হয়ে যায়।

— বেহরোজ

Answer 17

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

Comments

"আমদানির ঘোষণার বয়লারপ্লেট" বলতে কী বোঝ? "বিবৃতি ব্যবহার করছেন"? কিন্তু ক্লাসগুলি কি একই নামস্থানে যাবে না?

— জোয়ান ওয়েঞ্জ

@ জোয়ান: আমি বোঝাতে চাইছি খুব সাধারণ কিছু সম্পাদন করার জন্য 15 টি ভিন্ন তবে সম্পর্কিত মডিউল আমদানি করা। সম্ভবত এটি সি # তে বিশেষভাবে প্রযোজ্য নয়। আমি সত্যিই সি # জানি না, তবে অন্য ভাষায় এটি একটি বেশ বিরক্তিকর সমস্যা।

— dsimcha

ধন্যবাদ হ্যাঁ তাই আমি বিভ্রান্ত হয়ে পড়েছিলাম।

— জোয়ান ওয়েঞ্জ

Answer 18

আমি এটি করি তবে কেবল যখন ক্লাসগুলি শিশু-পিতামাতার ফ্যাশনের সাথে সম্পর্কিত হয় এবং শিশু ক্লাসগুলি কেবল পিতামাতার দ্বারা ব্যবহৃত হয়।

Comments

ধন্যবাদ, তবে কেন আপনি এটিকে অন্য কোনও ফাইলে আলাদা করবেন না? উৎসুক.

— জোয়ান ওয়েঞ্জ

@ হেনচম্যান এটিকে আমার চেয়ে অনেক বেশি স্পষ্টতই বলেছেন, বিশেষত যখন সন্তানের বস্তু খুব ছোট থাকে। সাধারণত আমাদের ক্ষেত্রে এমন ঘটনা

— ঘটে

Answer 19

আমি সাধারণত ফাইল প্রতি এক ক্লাসে আঁকড়ে থাকি। তবে আমি প্রকল্প-ব্যাপী ব্যবহৃত একই ধরণের নির্মাণের গ্রুপগুলির জন্য ব্যতিক্রম করব। উদাহরণ স্বরূপ:

• একটি ইভেন্টআর্গস.সি যে কোনও উপক্লাস রয়েছে EventArgs, যেহেতু তারা সাধারণত প্রতিটি কোডের 5-10 লাইন থাকে তবে এগুলি সাধারণত বিভিন্ন শ্রেণীর দ্বারা ব্যবহৃত হয়। বিকল্পভাবে, আমি EventArgsক্লাসগুলি একই ফাইলে ক্লাসগুলি রেখে যা ইভেন্টগুলি ঘোষণা করে as
• একটি ডেলিগেটস সি-তে এমন প্রতিনিধি থাকে যা প্রজেক্ট জুড়ে ব্যবহৃত হয়, যেহেতু তারা সাধারণত প্রতি এক লাইন থাকে। আবার বিকল্পটি হ'ল তাদের ক্লাসের সাথে একই ফাইলে রাখলে যেগুলি তাদের প্রকাশ করে / গ্রহণ করে।
• একটি Enums.cs যাতে enumপ্রজেক্ট জুড়ে ব্যবহৃত হয়। (যদি এমন একটি থাকে enumযা কেবলমাত্র একটি শ্রেণীর দ্বারা ব্যবহৃত হয়, আমি সাধারণত এটি privateclass শ্রেণিতে তৈরি করব ))

Answer 20

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

Answer 21

আমি এটি 99% সময় অনুসরণ করি। মানগুলি অনুসরণ করা ভাল, তবে আমি বিশ্বাস করি নমনীয়তারও এর জায়গা আছে place কখনও কখনও মনে হয় বিষয়গুলি ছিন্ন করতে সময় নষ্ট করার মতো সময় লাগে। এই সময়গুলিতে, আমি নিজের উপর উঠে এসেছি এবং কেবল আমার কোডটি লিখি।

Answer 22

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

Answer 23

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

বা মূল শ্রেণীর জন্য কিছু এক্সটেনশন পদ্ধতি ধারণ করতে একটি পৃথক শ্রেণি class

Answer 24

One case could be:যখন আপনার ক্লাসগুলি যৌথভাবে module / unitএমন একটি ফর্ম গঠন করে যা কিছু প্রধান শ্রেণীর মতো পরিবেশন করে helper classes, অন্যান্য জ্ঞানী নং ।

কটাক্ষপাত আছে ASP.NET MVC 2.0 প্রকল্পের সোর্স কোড। এটি কঠোরভাবে এই বিধি অনুসরণ করে

Answer 25

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

আমি এমএস অনুশীলনগুলি অনুসরণ করব না কারণ তারা সেরা অনুশীলন নয়!

Answer 26

অন্য কারও বিষয় আমি উল্লেখ করতে দেখিনি যে হ'ল আপনি যখন প্রতি ফাইলের নিয়মে এক শ্রেণি ব্যবহার করে বিকাশ করেন আপনি সহজেই দেখতে পারেন যে নির্দিষ্ট শ্রেণিটি কী ব্যবহার করছে।

উদাহরণস্বরূপ: আপনার দুটি ক্লাস থাকতে পারে যেখানে একটি শ্রেণি লিনক ব্যবহার করে এবং অন্যটি ব্যবহার করে না।

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

Answer 27

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

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

যখন দু'জন ব্যক্তি একটি বহু-শ্রেণীর ফাইলে কাজ করছেন এবং উভয়ই নির্ভরতা যুক্ত করেন তখন ভাল সুযোগ পাবেন আপনি usingশীর্ষে থাকা ব্লকটিতে একীভূত সংঘাত পাবেন । ক্লাসগুলিকে ফাইলগুলিতে পৃথক করা নির্ভরশীলতাগুলিকে আলাদা করে দেয় যাতে আপনি দেখতে পারেন যে প্রতিটি শ্রেণি কী ব্যবহার করছে এবং আপনি এ জাতীয় দ্বন্দ্ব পান না।

এই নিয়মের ব্যতিক্রম রয়েছে (ইন্টারফেস + বাস্তবায়ন, এনামস, ...) তবে এটি বিপরীতে তুলনামূলকভাবে আরও ভাল শুরু করার জায়গা যা সাধারণত জুনিয়র বিকাশকারীদের সমস্ত ধরণের সম্পর্কযুক্ত ক্লাসগুলিকে একই ফাইলে বান্ডিল করতে দেয়।

এক-ক্লাস-প্রতি-ফাইলটি একটি স্পষ্ট দ্ব্যর্থহীন নিয়ম যার অর্থ ব্যাখ্যার বিষয় নয়।

---

সম্পর্কিত-ক্লাস-এ-ফাইলটি ব্যক্তিগত পছন্দ এবং ব্যাখ্যার সাপেক্ষে (আপনি অন্যান্য সমস্ত উত্তর থেকে দেখতে পাবেন যে এটি কখন ব্যবহার করা ঠিক হবে) এবং সুতরাং এটি একটি দুর্বল নিয়ম।

Answer 28

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

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

Answer 29

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

Answer 30

ফাইলের জন্য একটি কোড আইটেম, হ্যাঁ।

বাকি সমস্ত কিছুই একটি অপব্যবহার - এবং, খুব স্পষ্টভাবে, আরএডি ভুক্তভোগির লক্ষণ।

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