সি # নামস্থান এবং পাঠাগারগুলির জন্য শ্রেণি নামকরণ কনভেনশন

Question

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

Company
Company.TextUtils
    public class TextUtils {...}
Company.MathsUtils
    public class MathsUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SIUnits
    public enum SISuffixes {...}
    public class SIUnits {...}

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

Comments

martinfowler.com/bliki/TwoHardThings.html

— সমৃদ্ধ জিলা

মাইক্রোসফ্টের নির্দেশিকাটি এনামগুলির জন্য একক নামের প্রস্তাব দেয় (তার SISuffixপরিবর্তে SISuffixes), এবং আমি মনে করি যে একবচনটি আরও ভালভাবে পড়তে পারে। "প্রত্যয় এ" Suffix.A হিসাবে পড়ে । এছাড়াও, আমি সাধারণত স্তরক্রমের স্তরের উপরে থেকে নামগুলি পুনরাবৃত্তি করা এড়িয়ে চলি। এটি হ'ল পরিবর্তে Company.SIUnits.SISuffixes, আমি Company.SI.SuffixCompany.SI.Unit

— হ্যরিসন পেইন

@ রিচজিলা thecodelesscode.com/case/220

— টিন ম্যান

Answer 1

আপনার নামকরণ কৌশলটি আপনার কোডের বাকী অংশ থেকে বিচ্ছিন্ন হয়ে কতটা কার্যকর তা নির্ধারণ করা খুব কঠিন।

নেমস্পেসটি আপনার কোডবেসের বিস্তৃত কাঠামোর সাথে খাপ খায় এমন কিছু ধারণা দেওয়া উচিত এবং শ্রেণীর নামটি সাধারণত area অঞ্চলে কী ধরণের কার্যকারিতা বা ধারণাটি উপস্থাপন করে তা বর্ণনা করবে।

গুহাতাগুলি আলাদা করে রাখুন, আপনার নির্দিষ্ট উদাহরণে, আপনার যদি আরও অনেক 'ইউটিল' ধরণের ক্লাস হওয়ার সম্ভাবনা থাকে তবে আমি তাদের এগুলির অধীনে রাখার বিষয়টি বিবেচনা করব That সেইভাবে Company.Utils.Mathsযদি আপনাকে একাধিক ইউটিলিটি অঞ্চলে সাধারণ বৈশিষ্ট্য যুক্ত করতে হয় তবে আপনার ইতিমধ্যে রয়েছে এটির জন্য একটি প্রাকৃতিক অবস্থান।

Comments

এটা একটা ভাল ধারণা মত শোনাচ্ছে। খুব বেশি উদ্বেগ বন্ধ করুন, কেবল এটিকে সমস্ত "Company.Util" এ ব্যবহার করুন।

— ব্যবহারকারী 15

Answer 2

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

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

Comments

নেমস্পেসের দিকনির্দেশগুলির প্রত্যক্ষ লিঙ্ক: এমএসডিএন.মাইক্রোসফটি.এইন

— ইউএস

যা কাকতালীয়ভাবে বা এই বিষয়টিতে একটি দুর্দান্ত বইয়ের একই নাম, এটি মাইক্রোসফ্ট লোকেরাও লিখেছিল যারা ডটনেট কাঠামো তৈরিতে অংশ নিয়েছিল, তারা কী সঠিক করেছে এবং কোথায় তারা ভুল পেয়েছিল সে সম্পর্কে বিভিন্ন মন্তব্য দিয়েছিল। পাঠ্য মূল্যবান: অ্যামাজন

— মাচাডো

@ এনভয়েগ্ট, আপনি দয়া করে আমাদের বন্ধু প্যাগোটি প্রদত্ত লিঙ্কটি থেকে একটি উদ্ধৃতি যুক্ত করতে আপনার উত্তরটি সম্পাদনা করতে পারেন: " নামস্থান এবং সেই নামস্থানে কোনও প্রকারের জন্য একই নামটি ব্যবহার করবেন না example উদাহরণস্বরূপ, ডিবাগটিকে একটি নেমস্পেসের নাম হিসাবে ব্যবহার করবেন না এবং তারপরে একই নেমস্পেসে ডিবাগ নামের একটি শ্রেণীও সরবরাহ করুন Several

— মাচাদো

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

— জন রেয়নর

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

— কার্ল লেথ

Answer 3

আমি সি # বা। ​​নেট ইকোসিস্টেমের সাথে কাজ করেছি তাই কিছুক্ষণ হয়ে গেছে তাই বর্তমানের প্রস্তাবিত সেরা অনুশীলনগুলি কী তা আমি বলতে পারি না। আমি আপনার নামগুলিতে পরিবর্তনের প্রস্তাব দিই:

Company
Company.Text
    public class TextUtils {...}
Company.Math
    public class MathUtils {...}
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

আমি এখানে যা করেছি তা হ'ল নেমস্পেসের নামগুলি থেকে "ইউটিলস" মুছে ফেলা। আমি মনে করি যে, "util" একটি নামস্থানে করা উচিত হবে না, কারণ Company.Textনামস্থান একদিন ক্লাস যে থাকতে পারে না টেক্সট ইউটিলিটি ক্লাস। Company.Mathনামস্থান ইতিমধ্যে রয়েছে ArbitraryPrecisionNumberযা একটি "ইউটিলিটি" হবে বলে মনে হচ্ছে না।

নেমস্পেস থেকে "ইউটিল" সরিয়ে ফেলাও একই নামের সাথে দুটি জিনিস রাখার ফলে উদ্ভূত যে কোনও বিভ্রান্তি দূর করে (রবার্টের উত্তরে বলা হয়েছে: /software//a/340440/13156 )

আপনি কোডটি অন্যভাবে পরিচালনা করতে পারতেন:

Company
Company.Util
    public class TextUtils {...}
    public class MathUtils {...}
Company.Math
    public class ArbitraryPrecisionNumber {...}
    public class MathsNotation {...}
Company.SI
    public enum SISuffixes {...}
    public class SIUnits {...}

এই ক্ষেত্রে, সমস্ত ইউটিলিটি ক্লাস একই নামস্থানে বাস করে। Company.Textকেবলমাত্র একটি ইউটিলিটি ক্লাস থাকার কারণে আর কোনও নামস্থান নেই ।

ব্যক্তিগতভাবে, আমি প্রথম বিকল্পটি কিছুটা আরও স্পষ্ট দেখতে পাচ্ছি।

Answer 4

নামের স্থান এবং এর অভ্যন্তরের শ্রেণীর জন্য একই নাম ব্যবহার করা সমস্যাযুক্ত।

• যদি নেমস্পেসে একাধিক শ্রেণি থাকে তবে অন্য শ্রেণি কেন সেখানে রাখা হবে? এটি ঠিক মনে হচ্ছে না, কারণ নামের স্থানটির লক্ষ্যটি কেবল একটি নয়, এর মধ্যে থাকা সমস্ত শ্রেণীর বর্ণনা করা । উদাহরণস্বরূপ, আপনি আছে যদি JsonSerialization, BinarySerializationএবং XmlSerializationএকটি নামস্থানে ক্লাস, এটা জ্ঞান আপনার নামস্থান নাম হবে XmlSerialization?

  সাধারণত যা ঘটে থাকে তা হ'ল অস্তিত্ববান নেমস্পেস থেকে কোনও শ্রেণি উত্তোলনের কারণে, বা একাধিক ক্লাস বা অন্যান্য পুনর্গঠনের মধ্যে একত্রীকরণের কারণে আপনি নিজেকে একটি প্রধান শ্রেণিযুক্ত নেমস্পেসের সাথে খুঁজে পান ; প্রগতিশীলভাবে, নাবালক শ্রেণিগুলিকে সেখানে রাখা হয় কারণ তারা মূল শ্রেণীর সাথে কিছুটা সম্পর্কিত। উদাহরণস্বরূপ, একটি নেমস্পেসে LogParserএকটি একক শ্রেণী থাকতে পারে LogParserএবং তারপরে কেউ রাখে LogConverter, কারণ এটি পার্সারের সাথে সম্পর্কিত, তারপরে LogSearcher, ইত্যাদি here এখানে সমস্যা হ'ল নেমস্পেসের নামটি পরিবর্তন করা হয়নি: LogConverterযুক্ত হওয়ার সাথে সাথে, নাম পরিবর্তন করা উচিত ছিল LogsProcessingবা, সহজভাবে Logs,।

• যদি নেমস্পেসে কেবল একটি ক্লাস থাকে তবে কোড সংস্থার মধ্যে এটি কোনও সমস্যার লক্ষণ হতে পারে।

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

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

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

---

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

নামকরণ একটি কারণে বিদ্যমান: যখন আপনার পরে জিনিসপত্রের সন্ধান করা প্রয়োজন তখন আপনার জীবনকে আরও সহজ করে তুলতে। আপনি জানেন যে আপনার যদি কোনও চার্ট আঁকার দরকার হয় তবে আপনি "চার্ট" বা "প্লট" অনুসন্ধান করার চেষ্টা করতে পারেন। যখন কোনও অ্যাপ্লিকেশন চালানের উত্স তৈরি করার উপায়টি পরিবর্তন করতে হবে তখন আপনি "চাল্য [ই / আইএন]" বা "বিল" সন্ধান করবেন। একইভাবে, এমন কোনও ক্ষেত্রে কল্পনা করার চেষ্টা করুন যেখানে আপনি নিজেকে বলে থাকবেন: "এইচএম, সম্ভবত এই বৈশিষ্ট্যটি মিসকে খুঁজে পাওয়া উচিত" ” পারছি না।

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

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

কল্পনা করুন আপনি এমন কিছু কোড তৈরি করেছেন যা ইউনিট এবং ইউনিট রূপান্তর নিয়ে কাজ করে। আপনি এটির নাম রাখতে পারেন Utilityএবং আপনার সহকর্মীরা তাকে ঘৃণা করতে পারে; অথবা আপনি এটি নাম দিতে পারেন Unitsএবং UnitsConversion।

Comments

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

— হতাশ

আমি আপনার সাথে একমত, কিন্তু বিকল্প হিসাবে আপনি কি পরামর্শ করবেন?

— ব্যবহারকারী 15

আমি এটি কল করব ..

— সামথিংম্যানেজার

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

— ম্যাটি ভির্ককুনেন

@ ফ্রাস্ট্রেটেড উইথফোর্ডস ডিজাইনার: কেবল ... Math? আমি দেখি না যে কীভাবে Utilityপ্রত্যেকে প্রত্যয় যুক্ত করা আমাদের জীবনকে আরও সহজ করে তুলবে। .NET এর System.Math.Min()পদ্ধতিটি ব্যবহার করার সময়, আপনি কি SystemUtility.MathUtility.Min()পরিবর্তে লেখার পছন্দ করবেন ? সব ক্ষেত্রেই আমি আমার উত্তরটি ভারী সম্পাদনা করেছি, সুতরাং এটি এখন আরও স্পষ্ট হওয়া উচিত।

— আর্সেনী মোরজেনকো