একই জায়গার সাথে নেমস্পেস এবং ক্লাস?

Question 1

আমি একটি লাইব্রেরি প্রকল্পের আয়োজন করছি এবং আমার একটি কেন্দ্রীয় পরিচালকের ক্লাস Scenegraphরয়েছে এবং সিনেমগ্রাফের নেমস্পেসে থাকা অন্যান্য ক্লাসগুলির পুরো গোছা রয়েছে।

আমি চিত্রগ্রাহী হওয়া MyLib.Scenegraphএবং অন্যান্য ক্লাসগুলি হবার জন্য যা করতে চাই তা হ'ল MyLib.Scenegraph.*তবে এটি করার একমাত্র Scenegraphউপায়টি দৃশ্যপট সি ফাইলগুলিতে অন্যান্য শ্রেণীর অভ্যন্তরীণ ক্লাসগুলি তৈরি করা এবং এটি কেবল খুব অযৌক্তিক ।

পরিবর্তে, আমি এটি Mylib.Scenegraph.Scenegraphএবং MyLib.Scenegraph.*, কোন ধরণের কাজ হিসাবে সংগঠিত করেছি কিন্তু আমি দেখতে পেয়েছি যে আমি শ্রেণি বা নামের স্থানটি উল্লেখ করছি কিনা তা সম্পর্কে ভিজ্যুয়াল স্টুডিও কিছু পরিস্থিতিতে বিভ্রান্ত হয়ে পড়ে।

এই প্যাকেজটি গুছিয়ে নেওয়ার জন্য কি কোনও ভাল উপায় আছে যাতে এটি ব্যবহারকারীর জন্য আমার সমস্ত কোড একসাথে অনাকাঙ্ক্ষিত জগাখিচুড়ি না করেই সুবিধাজনক?

Question 2

আমি আপনাকে কোনও শ্রেণীর নাম-স্থানের মতো নাম দেওয়ার পরামর্শ দিচ্ছি না, এই নিবন্ধটি দেখুন ।

ফ্রেমওয়ার্ক ডিজাইনের গাইডলাইনগুলি ৩.৪ বিভাগে বলা আছে "নামস্থান এবং সেই নামস্থানে কোনও প্রকারের জন্য একই নাম ব্যবহার করবেন না"। এটাই:
namespace MyContainers.List 
{ 
    public class List { … } 
}
কেন এই বেদনা? ওহ, আমাকে উপায়গুলি গণনা করুন।

আপনি নিজেকে এমন পরিস্থিতিতে ফেলতে পারেন যেখানে আপনি মনে করেন যে আপনি একটি জিনিস উল্লেখ করছেন তবে বাস্তবে অন্য কোনও বিষয়কে উল্লেখ করছেন। ধরুন আপনি এই দুর্ভাগ্যজনক পরিস্থিতিতে শেষ করেছেন: আপনি ব্লাহ.ডিএলএল লিখছেন এবং Foo.DLL এবং বার.ডিএলএল আমদানি করছেন, দুর্ভাগ্যক্রমে, দুজনেরই ফু নামে একটি টাইপ রয়েছে:
// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah  
{   
using Foo;   
using Bar;   
class C { Foo foo; } 
}
সংকলক একটি ত্রুটি দেয়। "Foo" Foo.Foo এবং Bar.Foo এর মধ্যে অস্পষ্ট। বোমার আমি অনুমান করি যে নামটি পুরোপুরি যোগ্যতা অর্জনের মাধ্যমে আমি এটি ঠিক করব:
   class C { Foo.Foo foo; } 
এটি এখন " Foo in Foo.Foo Foo.Foo এবং Bar.Foo এর মধ্যে দ্ব্যর্থহীন " অস্পষ্টতার ত্রুটি দেয় । প্রথম ফু বলতে কী বোঝায় আমরা এখনও তা জানি না এবং যতক্ষণ না আমরা এটি নির্ধারণ করতে পারি, ততক্ষণ আমরা দ্বিতীয়টি কী বোঝায় তা খুঁজে বের করার চেষ্টা করার চেষ্টাও করি না।

Question 3

নেমস্পেসে একই নাম দেওয়া এবং ক্লাস অন্যরা যেমনটি বলেছে তেমন সংকলককে বিভ্রান্ত করতে পারে।

কীভাবে নাম রাখব?

যদি নেমস্পেসের একাধিক ক্লাস থাকে তবে এমন একটি নাম সন্ধান করুন যা এই সমস্ত শ্রেণীর সংজ্ঞা দেয়।

যদি নেমস্পেসের মাত্র একটি শ্রেণি থাকে (এবং সেইজন্য এটি একই নাম দেওয়ার প্রলোভন থাকে) নামের স্থানটির নাম ClassName NS । মাইক্রোসফ্ট অন্তত এইভাবে তাদের নামের নাম দেয়।

Question 4

আমি আপনাকে পরামর্শ দেব যে আমি যে পরামর্শটি microsoft.public.dotnet.languages.csharpব্যবহার করেছি MyLib.ScenegraphUtil.Scenegraphএবং তা অনুসরণ করুন MyLib.ScenegraphUtil.*।

Question 5

CA1724: Type Names Should Not Match Namespaces ...

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

Question 6

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

উদাহরণস্বরূপ, আমার ক্ষেত্রে আমি যে ব্যক্তি এই জাতীয় সিদ্ধান্ত গ্রহণ করিনি সেহেতু এটি কার্যকর করার জন্য আমার একটি উপায় খুঁজে বের করা দরকার।

সুতরাং যারা এখানে নেমস্পেসের নাম বা শ্রেণীর নাম পরিবর্তন করতে পারবেন না তাদের পক্ষে এমন একটি উপায় যা আপনি আপনার কোডটিকে কাজ করতে পারেন।

// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah
{
    using FooNSAlias = Foo;//alias
    using BarNSAlias = Bar;//alias
    class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}

মূলত আমি নেমস্পেস "এলিয়াস" তৈরি করেছি এবং এটি আমাকে ক্লাসে পুরোপুরি যোগ্যতা অর্জনের অনুমতি দেয় এবং ভিজ্যুয়াল স্টুডিও "বিভ্রান্তি" দূরে চলে যায়।

দ্রষ্টব্য: আপনার নামকরণ বিরোধটি যদি এগুলি করা আপনার নিয়ন্ত্রণে থাকে তবে আপনার এড়ানো উচিত। আপনি যখন প্রশ্নে ক্লাস এবং নেমস্পেসের নিয়ন্ত্রণে নন তখন আপনার কেবলমাত্র উল্লিখিত কৌশলটি ব্যবহার করা উচিত।

Question 7

শুধু আমার 2 সেন্ট যোগ করা হচ্ছে:

আমার নিম্নলিখিত ক্লাস ছিল:

namespace Foo {
    public struct Bar {
    }
    public class Foo {
        //no method or member named "Bar"
    }
}

ক্লায়েন্টটি এভাবে লেখা হয়েছিল:

using Foo;

public class Blah {
    public void GetFoo( out Foo.Bar[] barArray ) {
    }
}

আউট প্যারামিটারটি ব্যবহার না করে আউটপুট ফেরত না পাওয়ার গেটফু ত্রুটিটি ভুলে যাওয়া সংকলক Foo.Bar [] টাইপের ডেটা সমাধান করতে পারেনি। এটি ত্রুটিটি ফিরিয়েছিল: Foo.Bar টাইপ বা নামের সন্ধান করতে পারে নি।

দেখা যাচ্ছে যে এটি সংকলনের চেষ্টা করার সময় এটি ক্লাস হিসাবে ফুটিকে সমাধান করেছে এবং ফু ক্লাসে এমবেডড ক্লাস বারটি খুঁজে পেল না। এটি ফু.বার নামে একটি নেমস্পেসও খুঁজে পেল না। এটি নামস্থান ফু-তে একটি ক্লাস বারের সন্ধান করতে ব্যর্থ হয়েছিল। নামের জায়গার বিন্দুগুলি সিনট্যাকটিক নয়। পুরো স্ট্রিংটি একটি টোকেন, বিন্দুর দ্বারা বিস্মৃত শব্দগুলি নয়।

এই আচরণটি ভিএস 2015 চলমান দ্বারা প্রদর্শিত হয়েছিল। নেট 4.6

Question 8

অন্যরা যেমন বলেছে, কোনও শ্রেণীর নামকরণের স্থানের মতো নামকরণ এড়ানো ভাল অভ্যাস।

সফটওয়্যার ইঞ্জিনিয়ারিং স্ট্যাক এক্সচেঞ্জের সম্পর্কিত সম্পর্কিত "একই শ্রেণি এবং নেমস্পেসের নাম" সম্পর্কিত একটি প্রশ্নের উত্তর থেকে কিছু অতিরিক্ত নামকরণ পরামর্শ এখানে রইল :

আপনি ঠিক বলেছেন যে আপনার নামের স্থানটি যেমন থাকা ঠিক তেমন নামকরণ করা উচিত নয়। আমি মনে করি আপনি ব্যবহার করতে পারেন এমন অনেকগুলি পদ্ধতি রয়েছে:

বহুবচন: মডেল.ডাটাসোর্স। ডেটা উত্স

এটি বিশেষত ভাল কাজ করে যদি নেমস্পেসের প্রাথমিক উদ্দেশ্যটি এমন বেসগুলি থাকে যা একই বেস টাইপ থেকে উত্তরাধিকারী হয় বা একই ইন্টারফেস প্রয়োগ করে implement

সংক্ষিপ্ত: Model.QueryStorage

যদি কোনও নেমস্পেসে কেবলমাত্র কয়েকটি সংখ্যক প্রকার থাকে, তবে আপনার সম্ভবত সেই নেমস্পেসের প্রয়োজন হবে না।

এন্টারপ্রাইজ করুন: মডেল.প্রজেক্টসিস্টেম.প্রজেক্ট

এটি বিশেষত এমন বৈশিষ্ট্যগুলির জন্য কাজ করতে পারে যা আপনার পণ্যের গুরুত্বপূর্ণ অংশ, তাই তারা তাদের নিজস্ব নামের প্রাপ্য।

(নোট যে উপরোক্ত উত্তর ব্যবহারসমূহ Model.DataSource.DataSource, Model.QueryStorage.QueryStorage.এবংModel.Project.Project যেমন বদলে উদাহরণMyLib.Scenegraph.Scenegraph ।)

(আমি এখানে অন্যান্য উত্তরগুলিতে নামকরণের অন্যান্য পরামর্শও সহায়ক পেয়েছি))

Question 9

পুরানো পোস্ট, তবে এখানে আমি অন্য একটি ধারণা নিয়ে যাচ্ছি যাতে কারওর সহায়তা হতে পারে:

"... তবে এটি করার একমাত্র উপায় এটি সিনেকগ্রাফের ফাইলগুলিতে অন্যান্য ক্লাসের অভ্যন্তরীণ শ্রেণি তৈরি করা এবং এটি কেবল খুব অকাট্য।"

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

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

কিছুটা এইরকম...

দৃশ্যাবলী:

namespace MyLib
{
    public partial class Scenegraph
    {
        //Scenegraph specific implementations
    }
}

ডিপেন্ডেন্টক্লাস.সি:

namespace MyLib
{
    public partial class Scenegraph
    {
        public class DependentClass
        {
            //DependentClass specific implementations
        }
    }
}

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

Question 10

যখন এটি নেমস্পেসের মূল বর্গ হয় happens সুতরাং একটি লাইব্রেরিতে নেমস্পেস স্থাপনের জন্য এটি একটি অনুপ্রেরণা, যদি আপনি নামের জায়গার নামের সাথে 'লিবি' যুক্ত করেন তবে সমস্যাটি চলে যাবে ...

namespace SocketLib
{
    class Socket
    {