একই নামের একাধিক ক্লাস, তবে বিভিন্ন নামের স্থান?

Question

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

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

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

এই অনুশীলনের চারপাশে গাইডলাইনগুলি কী কী?

Comments

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

— লিওপোল্ড Asperger 21

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

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

— তেলস্তিন

মডেলগুলি Employeeবেশ কয়েকবার এমন সিস্টেমে কাজ করার পরে মনে হচ্ছে আপনার সমস্ত বৈশিষ্ট্যের মিলনের সাথে আপনার একটি মডেল প্রয়োজন এবং একটি typeবা departmentবৈশিষ্ট্য অন্তর্ভুক্ত । অন্যথায়, কোডটির অনাবশ্যক নকল রয়েছে।

নেমস্পেসগুলি শুরু হওয়ার কারণগুলির মধ্যে এটি কি অন্যতম ছিল না? নাম সংঘর্ষের অনুমতি দিতে?

— ড্যান পিচেলম্যান

Answer 1

আমি আমার প্রকল্পগুলির মধ্যেও এটি দেখে ও কাজ করার পরে আমি এই জাতীয় ব্যবহারের বিরুদ্ধে একটি উত্তর দেওয়ার চেষ্টা করব।

কোড পাঠযোগ্যতা

সবার আগে, বিবেচনা করুন যে কোড পাঠযোগ্যতা গুরুত্বপূর্ণ এবং এই অনুশীলনটি এর বিপরীতে। কেউ একটি কোডের টুকরো পড়ে এবং কেবল এটির একটি ফাংশন রয়েছে তা বলি doSomething(Employee e)। এটি আর পঠনযোগ্য নয়, কারণ Employeeবিভিন্ন প্যাকেজে 10 টি পৃথক ক্লাসের কারণে আপনার ইনপুটটি আসলে কী তা জানতে আপনাকে প্রথমে আমদানির ঘোষণার অবলম্বন করতে হবে।

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

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

কোড সদৃশ

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

কোড জটিলতা

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

কোড যোগাযোগ

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

কীভাবে সমস্যা থেকে মুক্তি পাবেন

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

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

আপনার প্রোগ্রামিং ভাষার উপর নির্ভর করে, আপনি ক্লাসগুলি চিহ্নিত করতে চাইতে পারেন যা অবশেষে @Deprecatedআপনার দলটিকে তত্ক্ষণাত বুঝতে সহায়তা করতে পারে যে তারা কিছু পরিবর্তন করতে হবে যা নিয়ে কাজ করছে aid

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

একটি দীর্ঘ গল্প সংক্ষিপ্ত করতে: এই "অনুশীলন" প্রযুক্তিগতভাবে সুরক্ষিত, তবে গোপন ব্যয়ে পুরো চেপে গেছে যা কেবল আরও রাস্তায় আরও ঘটবে। আপনি সমস্যাটি তত্ক্ষণাত্ মুক্তি পেতে সক্ষম না হতে পারলে এর ক্ষতিকারক প্রভাবগুলি সহ আপনি তাত্ক্ষণিকভাবে শুরু করতে পারেন।

Comments

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

— অবহিত

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

— ফ্রাঙ্ক

যদি একই নামের একাধিক ক্লাস একই প্রসঙ্গে ব্যবহার করা হয় তবে তা শক্ত। আমি কেস দেখিনি। আমি একই নামে একাধিক ক্লাস দেখেছি, তবে আপনারা যেমন উল্লেখ করেছেন সেগুলি প্রায়শই একই প্রসঙ্গে ব্যবহৃত হয় না।

— অবহিত

@ আরন্ডোমায় - দুঃখের বিষয়, এই কোডবেসে এই ঘটনাটি মোটামুটি সাধারণ।

— তেলস্তিন

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

— পাবলো এইচ

Answer 2

স্কালা সংগ্রহের ফ্রেমওয়ার্ক এটির একটি ভাল উদাহরণ। পরিবর্তনীয় এবং অপরিবর্তনীয় সংগ্রহ পাশাপাশি সিরিয়াল এবং সমান্তরাল (এবং ভবিষ্যতে সম্ভবত বিতরণও হতে পারে) সংগ্রহ রয়েছে। সুতরাং, উদাহরণস্বরূপ, চারটি Mapবৈশিষ্ট্য রয়েছে:

scala.collection.Map
scala.collection.immutable.Map
scala.collection.mutable.Map
scala.collection.concurrent.Map

আরও তিনটি ParMap:

scala.collecion.parallel.ParMap
scala.collecion.parallel.immutable.ParMap
scala.collecion.parallel.mutable.ParMap

আরও আকর্ষণীয়:

scala.collection.immutable.Map            extends scala.collection.Map
scala.collection.mutable.Map              extends scala.collection.Map
scala.collection.concurrent.Map           extends scala.collection.mutable.Map

scala.collecion.parallel.ParMap           extends scala.collection.Map
scala.collecion.parallel.immutable.ParMap extends scala.collecion.parallel.ParMap
scala.collecion.parallel.mutable.ParMap   extends scala.collecion.parallel.ParMap

সুতরাং, ParMapপ্রসারিত ParMapপ্রসারিত Mapএবং Mapপ্রসারিত Mapপ্রসারিত Map।

আর কি: কিন্তু, চল এটা মোকাবেলা করি হবে আপনি তাদের কল? এটি নিখুঁত জ্ঞান তোলে। নেমস্পেসের জন্য এটিই!

Comments

"নামস্থানের জন্য এটিই!" => +1

— এসভিডজেন

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

— redcalx

Answer 3

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

আমি মনে করি এখন পর্যন্ত দুটি অত্যন্ত গুরুত্বপূর্ণ বিবেচনা রয়েছে যা আপনাকে একটি জোর বা অন্য দিকে যেতে চাইবে, @ জর্জ এবং @ ফ্র্যাঙ্কের দুটি উত্তর থেকে আঁকতে:

1. যদি আপনি এমন পরিস্থিতিটির পূর্বে ধারণা করেন যেখানে একই কোডের একাধিক শ্রেণির একই কোড প্রসঙ্গে ব্যবহার করার প্রয়োজন হতে পারে তবে এটি একই নামটি ব্যবহার না করার কারণ। এটি হ'ল যদি আপনার সাথে কাজ করার প্রয়োজন hr.Employeeহয় তবে একই সাথে অনুমতিগুলির সন্ধান করা প্রয়োজন তবে security.Employeeএটি বিরক্তিকর বাস্তব বাস্তব হতে চলেছে।
2. বিপরীতভাবে, যদি একই নামের সমস্ত সহ আপনার ক্লাসগুলির সকলের একই বা খুব অনুরূপ এপিআই থাকে, তবে আপনার যখন একই নামটি বিভিন্ন নেমস্পেসের সাথে ব্যবহার করা উচিত তখন এটির একটি উত্তম উদাহরণ । স্কেলার উদাহরণটি হুবহু এটি, যেখানে সমস্ত Mapক্লাস একই ইন্টারফেস প্রয়োগ করে বা একে অপরের সাবক্লাস হয়। এক্ষেত্রে অস্পষ্টতা বা "বিভ্রান্তি" তাত্ক্ষণিকভাবে একটি ভাল জিনিস বলা যেতে পারে, কারণ ব্যবহারকারী যথাযথভাবে শ্রেণীর সমস্ত প্রয়োগগুলি বা ইন্টারফেসের সাথে একই আচরণ করতে পারে ... যা ইন্টারফেস এবং সাবক্লাসের বিন্দু।