কীভাবে আমার কোডটিতে "পরিচালক" এড়ানো যায়

Question

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

আমার গ্রন্থাগারের বেশিরভাগ পরিচালক এই ক্লাসগুলি নিয়ে গঠিত (যদিও এটি কিছুটা আলাদা হয়):

• ধারক - ব্যবস্থাপক মধ্যে বস্তুর জন্য একটি ধারক
• বৈশিষ্ট্য - ব্যবস্থাপকের মধ্যে অবজেক্টের জন্য বৈশিষ্ট্য

আমার লাইব্রেরির জন্য আমার নতুন ডিজাইনে, আমার লাইব্রেরিটি এক সাথে বেঁধে রাখার জন্য আমার এই নির্দিষ্ট ক্লাস রয়েছে।

• কম্পোনেন্টম্যানেজার - সত্ত্বা সিস্টেমে উপাদান পরিচালনা করে

  • ComponentContainer
  • ComponentAttributes
  • দৃশ্য * - একটি দৃশ্যের একটি রেফারেন্স (নীচে দেখুন)

• সিস্টেমম্যানেজার - সত্ত্বা সিস্টেমে সিস্টেম পরিচালনা করে

  • SystemContainer
  • দৃশ্য * - একটি দৃশ্যের একটি রেফারেন্স (নীচে দেখুন)

• সত্ত্বা ব্যবস্থাপক - সত্ত্বা ব্যবস্থাতে সত্তাগুলি পরিচালনা করে

  • সত্তা পুল - সত্তা একটি পুল
  • সত্তাঅ্যাট্রিবিউটস - কোনও সত্তার বৈশিষ্ট্য (এটি কেবলমাত্র কম্পোনেন্ট কনটেনার এবং সিস্টেম ক্লাসে অ্যাক্সেসযোগ্য হবে)
  • দৃশ্য * - একটি দৃশ্যের একটি রেফারেন্স (নীচে দেখুন)

• দৃশ্য - সমস্ত পরিচালককে একসাথে বাঁধে

  • ComponentManager
  • SystemManager
  • EntityManager

আমি কেবল দৃশ্য ক্লাসে সমস্ত ধারক / পুল রাখার কথা ভাবছিলাম।

অর্থাত

এর পরিবর্তে:

Scene scene; // create a Scene

// NOTE:
// I technically could wrap this line in a createEntity() call in the Scene class
Entity entity = scene.getEntityManager().getPool().create();

এটি হবে:

Scene scene; // create a Scene

Entity entity = scene.getEntityPool().create();

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

নোট:

1. একটি সত্তা সিস্টেম হ'ল গেমসের জন্য ব্যবহৃত একটি নকশা। এটি 3 প্রধান অংশ নিয়ে গঠিত: উপাদান, সত্তা এবং সিস্টেমগুলি। উপাদানগুলি হ'ল ডেটা, যা সত্তাগুলি স্বতন্ত্র হওয়ার জন্য সত্তায় "যুক্ত" হতে পারে। একটি সত্তা একটি পূর্ণসংখ্যা দ্বারা প্রতিনিধিত্ব করা হয়। সিস্টেমগুলিতে সুনির্দিষ্ট উপাদান সহ কোনও সত্তার যুক্তি যুক্ত থাকে।
2. আমি আমার লাইব্রেরির জন্য আমার নকশাটি পরিবর্তনের কারণ হ'ল কারণ আমি মনে করি এটি বেশ পরিবর্তন করা যেতে পারে, আমি এই মুহুর্তে অনুভূতি / প্রবাহকে পছন্দ করি না।

Comments

আপনি কীভাবে পরিচালকগণের সম্পর্কে শুনেছেন এবং কীভাবে তারা আপনার সাথে সম্পর্কিত তা খারাপভাবে ব্যাখ্যা করতে পারেন?

— মিঃফক্স

আপনি নীচের লিঙ্কগুলি সহায়ক বলে মনে করতে পারেন : ম্যানেজার ক্লাসগুলি কি খারাপ স্থাপত্যের লক্ষণ হতে পারে? এবং নামকরণের ক্লাসগুলি - কীভাবে সমস্ত কিছু পরিচালকের কল করা এড়ানো যায়

— R4D4

@ এমআরফক্স মূলত আমি ডাঙ্কের কথা বলেছি শুনেছি এবং আমার লাইব্রেরিতে আমার অনেক * ম্যানেজার ক্লাস রয়েছে, যেগুলি থেকে আমি মুক্তি পেতে চাই।

— মিগুয়েল.মার্টিন

এই হিসাবে ভাল সহায়ক হতে পারে: medium.com/@wrong.about/...

— Zapadlo

আপনি একটি কার্যকারী অ্যাপ্লিকেশন বাইরে একটি কার্যকর কাঠামো ফ্যাক্টর। কল্পনাযুক্ত অ্যাপ্লিকেশনগুলির জন্য একটি কার্যকর কাঠামো লেখা প্রায় অসম্ভব।

— কেভিন cline

Answer 1

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

ডাঙ্ক যেমন বলেছে, ম্যানেজার ক্লাসগুলিকে এ জাতীয় বলা হয় কারণ তারা জিনিসগুলিকে "পরিচালনা" করে। "পরিচালনা" হ'ল "ডেটা" বা "কর" এর মতো, এটি একটি বিমূর্ত শব্দ যা প্রায় কোনও কিছুই ধারণ করতে পারে।

আমি প্রায় 7 বছর আগে আপনার চেয়ে বেশিরভাগ জায়গায় একই জায়গায় ছিলাম এবং আমি ভাবতে শুরু করেছিলাম যে আমার চিন্তাভাবনাতে কিছু ভুল হয়েছে কারণ কিছুই করার কোড করার এত প্রচেষ্টা ছিল না।

আমি এটি ঠিক করার জন্য যা পরিবর্তন করেছি তা হ'ল কোডে আমি ব্যবহার করা শব্দভাণ্ডার পরিবর্তন । আমি জেনেরিক শব্দগুলি সম্পূর্ণরূপে এড়িয়ে চলে যাই (যদি না এটি জেনেরিক কোড না হয় তবে আপনি যখন জেনেরিক লাইব্রেরি তৈরি করেন না তখন তা বিরল)। আমি কোনও প্রকারের "পরিচালক" বা "অবজেক্ট" এর নাম এড়াতে চাই ।

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

কখনই কোনও প্রকারের নাম "পরিচালক" রাখবেন না এবং নিশ্চিত করুন যে আপনার সমস্ত ধরণের একক অনন্য ভূমিকা রয়েছে তা আমার প্রস্তাবনা। কিছু সময় নামগুলি খুঁজে পাওয়া শক্ত হতে পারে তবে সাধারণত প্রোগ্রামিংয়ে এটি করা সবচেয়ে কঠিন কাজ

Comments

যদি কোনও দম্পতি dynamic_castআপনার পারফরম্যান্সকে হত্যা করছে, তবে স্ট্যাটিক টাইপ সিস্টেমটি ব্যবহার করুন- এটি তার জন্য। এলএলভিএমের মতো আপনার নিজের আরটিটিআই রোল করতে সত্যিই এটি একটি বিশেষায়িত প্রসঙ্গ, কোনও সাধারণ নয়। তারপরেও, তারা এটি করে না।

— ডেড এমএমজি

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

— ক্লাইম

@ ডেড এমজি আমি ডায়নামিক_কাস্ট ব্যবহার করছি না, আমিও ডায়নামিক_কাস্টের বিকল্প ব্যবহার করছি না। আমি এটি লাইব্রেরিতে প্রয়োগ করেছি, তবে আমি এটি বের করে নিয়ে বিরক্ত হতে পারি না। template <typename T> class Class { ... };আসলে বিভিন্ন শ্রেণীর (যথা কাস্টম উপাদান এবং কাস্টম সিস্টেম) আইডি নির্ধারণের জন্য। আইডি অ্যাসাইনমেন্টটি ভেক্টরে উপাদান / সিস্টেমগুলি সঞ্চয় করতে ব্যবহৃত হয়, মানচিত্রের কারণে আমার কোনও গেমের জন্য প্রয়োজনীয় পারফরম্যান্স আনতে পারে না।

— মাইগুয়েল.মার্টিন

আচ্ছা আমি আসলে ডাইনামিক_কাস্টের কোনও বিকল্প বাস্তবায়ন করি নি, কেবল একটি জাল টাইপ_আইডি। তবে, এখনও আমি চাইনি টাইপ_আইডি কী অর্জন করেছে।

— মাইগুয়েল.মার্টিন

"আপনার ধরণের সত্যিকারের দায়িত্বের সাথে সম্পর্কিত সঠিক শব্দটি সন্ধান করুন" - যদিও আমি এটির সাথে পুরোপুরি একমত, প্রায়শই একটি শব্দও (যদি থাকে) থাকে না যে বিকাশকারী সম্প্রদায় একটি নির্দিষ্ট ধরণের দায়বদ্ধতার জন্য সম্মত হয়েছে।

— বাইটেডেভ

Answer 2

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

আসুন অবজেক্টফ্যাক্টরি দিয়ে শুরু করা যাক । প্রথমত, ফাংশন পয়েন্টার। এগুলি স্টেটহীন, কোনও বস্তু তৈরির একমাত্র কার্যকর রাষ্ট্রবিহীন উপায় newএবং এর জন্য আপনার কোনও কারখানার প্রয়োজন নেই। রাষ্ট্রীয়ভাবে একটি জিনিস তৈরি করা যা দরকারী এবং ফাংশন পয়েন্টারগুলি এই কাজের জন্য কার্যকর নয়। এবং দ্বিতীয়ত, প্রতিটি অবজেক্টকে কীভাবে নিজেকে ধ্বংস করতে হয় তা জানতে হবে, এটি ধ্বংসের জন্য সঠিক উত্সর্গের সন্ধানের প্রয়োজন নেই। এবং তদতিরিক্ত, আপনার ব্যবহারকারীর ব্যতিক্রম এবং সংস্থান সুরক্ষার জন্য আপনাকে অবশ্যই কোনও স্মার্ট পয়েন্টারটি দিতে হবে, কাঁচা পয়েন্টার নয়। আপনার পুরো ক্লাসরেজিস্ট্রি ডেটা ক্লাসটি কেবলমাত্র std::function<std::unique_ptr<Base, std::function<void(Base*)>>()>, তবে উপরোক্ত গর্তগুলির সাথে। এর অস্তিত্বের দরকার নেই।

তারপরে আমাদের কাছে অ্যালোকেটর ফান্টেক্টর রয়েছে - ইতিমধ্যে স্ট্যান্ডার্ড বরাদ্দকারী ইন্টারফেস সরবরাহ করা হয়েছে - এটি কেবল উল্লেখ করা উচিত নয় যে তারা কেবলমাত্র মোড়ক delete obj;এবং return new T;- যা আবার ইতিমধ্যে সরবরাহ করা হয়েছে, এবং তারা বিদ্যমান কোন স্টেটফুল বা কাস্টম মেমরি বরাদ্দকারীদের সাথে যোগাযোগ করবে না।

এবং ClassRegistry কেবল সহজ std::map<std::string, std::function<std::unique_ptr<Base, std::function<void(Base*)>>()>>তবে আপনি বিদ্যমান কার্যকারিতাটি ব্যবহার না করে এর জন্য একটি ক্লাস লিখেছিলেন। এটি একই, তবে সম্পূর্ণ অকারণে ক্রেডি ম্যাক্রোগুলির সাথে বিশ্বব্যাপী পরিবর্তনীয় অবস্থা।

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

তারপরে আমাদের শনাক্তকরণযোগ্য । এটি এখানে অনেক একই গল্প- std::type_infoইতিমধ্যে প্রতিটি টাইপকে রান-টাইম মান হিসাবে চিহ্নিত করার কাজটি সম্পাদন করে, এবং এটি ব্যবহারকারীর পক্ষে অতিরিক্ত বয়লারপ্লেটের প্রয়োজন হয় না।

    template<typename T, typename Y>
    bool isSameType(const X& x, const Y& y) { return typeid(x) == typeid(y); }
    template <class Type, class T>
    bool isType(const T& obj)
    {
            return dynamic_cast<const Type*>(std::addressof(obj));
    }

সমস্যা সমাধান হয়েছে, তবে ম্যাক্রো এবং হোয়াট নোটের পূর্ববর্তী দু'শ লাইনের কোনও ছাড়াই। এটি আপনার আইডেন্টিফিয়েবল অ্যারেটিকে আর কিছুই হিসাবে চিহ্নিত করে না তবে std::vectorআপনাকে অনন্য মালিকানা বা অ-মালিকানা আরও ভাল করা হলেও আপনাকে রেফারেন্স-কাউন্টিং ব্যবহার করতে হবে।

ওহ, এবং আমি উল্লেখ যে প্রকারভেদ একটি গুচ্ছ ধারণ করে একেবারে বেহুদা typedefs? সরাসরি কাঁচা প্রকারটি ব্যবহার করার মাধ্যমে আপনি আক্ষরিক কোনও উপকার অর্জন করতে পারবেন না এবং পাঠযোগ্যতার একটি ভাল অংশ হারাবেন।

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

এখন, কম্পোনেন্টফিল্টারটি আসলে কিছুটা দামের হতে পারে, যদি আপনি এটি অনেকটা রিফ্যাক্টর করে থাকেন। কিছুটা এইরকম

class ComponentFilter {
    std::unordered_map<std::type_info, unsigned> types;
public:
    template<typename T> void SetTypeRequirement(unsigned count = 1) {
        types[typeid(T)] = count;
    }
    void clear() { types.clear(); }
    template<typename Iterator> bool matches(Iterator begin, Iterator end) {
        std::for_each(begin, end, [this](const std::iterator_traits<Iterator>::value_type& t) {
            types[typeid(t)]--;
        });
        return types.empty();
    }
};

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

এই বাকি বেশ একই গল্প। এখানে আপনার লাইব্রেরি ব্যবহার না করে আরও ভাল কিছু করা যায় না।

আপনি এই কোডটিতে পরিচালকদের কীভাবে এড়াবেন? মূলত এগুলি সব মুছুন।

Comments

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

— ট্যাক্রয়

আমি স্টাডি :: টাইপ_ইনফো ব্যবহার না করার কারণটি হ'ল আমি আরটিটিআই এড়াতে চেষ্টা করছিলাম । আমি উল্লেখ ফ্রেমওয়ার্ক গেম লক্ষ্য ছিল, যা মূলত কারনেই আমি ব্যবহার করছি না হয় typeidবা dynamic_cast। মতামতের জন্য ধন্যবাদ যদিও, আমি এটি প্রশংসা করি।

— মিগুয়েল.মার্টিন

এই সমালোচকেরা উপাদান-সত্তা সিস্টেম গেম ইঞ্জিনগুলি সম্পর্কে আপনার জ্ঞানের ভিত্তিতে বা এটি একটি সাধারণ সি ++ কোড পর্যালোচনা?

— ডেন

@ ডেন আমি অন্য যে কোনও কিছুর চেয়ে ডিজাইনের ইস্যুটি বেশি ভাবি।

— মিগুয়েল.মার্টিন

Answer 3

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

আমার অনুমান যে আপনার ম্যানেজার ক্লাসগুলি সম্ভবত অনেক কিছু করে। আমি বাজি ধরছি যদি আপনি সেই জিনিসগুলিকে ঘনিষ্ঠভাবে সম্পর্কিত ক্রিয়ামূলক টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরা সম্পর্কিত আপনি সম্ভবত ক্লাসের নামটি দেখলে তারা কি করতে পারেন তা কার্যকরী টুকরা সম্পর্কিত ক্লাসের নামগুলি নিয়ে আসতে সক্ষম হবেন। এটি ডিজাইন বজায় রাখা এবং বোঝার জন্য আরও সহজ করে দেবে।

Comments

+1 এবং কেবলমাত্র তারা যথেষ্ট সময়সীমায় তারা কিছু করতে পারে না। লোকেরা "ম্যানেজার" বর্ণনাকারীকে রান্নাঘর-সিঙ্ক / সুইস-আর্মি-ছুরি ক্লাস তৈরির আমন্ত্রণ হিসাবে দেখেন।

— এরিক ডায়েট্রিচ

@ এরিক - আহা হ্যাঁ, আমার যোগ করা উচিত ছিল যে ভাল শ্রেণীর নাম রাখা কেবল গুরুত্বপূর্ণ নয় কারণ এটি কাউকে ক্লাস কী করতে পারে তা বলে; তবে সমানভাবে ক্লাসের নামটিও ক্লাসের কি করা উচিত নয় তা বলে।

— ডঙ্ক

Answer 4

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

আমি তোমাদের ব্যবহার করতে পারে অনুমান করা Databaseমত, ComponentDatabase। অথবা আপনি কেবল ব্যবহার করতে পারেন Components, Systemsএবং Entities(এটি আমি ব্যক্তিগতভাবে ব্যবহার করি এবং মূলত কেবল আমি সংক্ষিপ্ত শনাক্তকারীদের পছন্দ করি যদিও এটি "ম্যানেজার" এর চেয়ে সম্ভবত কম তথ্য জানায়) con

যে অংশটি আমি খানিকটা আচ্ছন্ন তা হ'ল:

Entity entity = scene.getEntityManager().getPool().create();

getআপনি কোনও সত্তা তৈরির আগে এটি পুরোপুরি স্টাফ করে তোলে এবং মনে হয় নকশাটি প্রয়োগের বিশদটি কিছুটা ফাঁস করছে যদি আপনি সত্তা পুলগুলি এবং "পরিচালক" তৈরি করতে তাদের সম্পর্কে জানতে হয়। আমি মনে করি "পুল" এবং "পরিচালক" এর মতো জিনিসগুলি (যদি আপনি এই নামের সাথে আঁকেন) তবে ক্লায়েন্টের কাছে উন্মুক্ত কিছু নয়, ইসিএসের প্রয়োগের বিবরণ হওয়া উচিত।

কিন্তু জানিনা, আমি কিছু খুব কল্পনাশক্তিরহিত এবং জেনেরিক ব্যবহার দেখেছি Manager, Handler, Adapter, এবং এই ধরণের নাম, কিন্তু আমি মনে করি এটা একটা যুক্তিসঙ্গতভাবে মার্জনীয় ব্যবহারের ক্ষেত্রে যখন জিনিস "ম্যানেজার" বলা আসলে "পরিচালনার" ( "নিয়ন্ত্রণ জন্য দায়ী কে? "," হ্যান্ডলিং? ") অবজেক্টের জীবনকাল, পৃথকভাবে তাদের তৈরি এবং ধ্বংস এবং এর অ্যাক্সেস সরবরাহ করার জন্য দায়বদ্ধ। এটি অন্ততপক্ষে আমার জন্য "ম্যানেজার" এর সবচেয়ে সহজ এবং স্বজ্ঞাত ব্যবহার।

এটি বলেছে যে, আপনার নামে "ম্যানেজার" এড়ানোর একটি সাধারণ কৌশল কেবলমাত্র "ম্যানেজার" অংশটি গ্রহণ করা এবং -sশেষে একটি যুক্ত করা। :-D উদাহরণস্বরূপ, আসুন আমরা বলি যে আপনার একটি রয়েছে ThreadManagerএবং এটি থ্রেড তৈরি করতে এবং সেগুলি সম্পর্কে তথ্য সরবরাহ করার জন্য এবং সেগুলি আরও অ্যাক্সেস করার জন্য দায়বদ্ধ, তবে এটি থ্রেডগুলিতে পুল করে না তাই আমরা এটি কল করতে পারি না ThreadPool। ঠিক আছে, এই ক্ষেত্রে, আপনি কেবল এটি কল Threads। আমি যখন কল্পনাও করি না কেন আমি যা করি তা তাই।

"উইন্ডোজ এক্সপ্লোরার" এর সমতুল্য সমতুল্য যখন "ফাইল ম্যানেজার" বলা হত তখন আমি আবার স্মরণ করিয়ে দিই:

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

Comments

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

— জাস্টিন সময় 2 পুনর্বহাল মনিকা