অপরিবর্তনীয় ধরণের ত্রুটিগুলি কী কী?

Question

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

একই সময়ে, আমি খুব কমই অন্যান্য অ্যাপ্লিকেশনগুলিতে অপরিবর্তনীয় প্রকারগুলি দেখতে পাই, এমনকি যখন পরিবর্তনটি কারও উপকারে না আসে।

প্রশ্ন: অপরিবর্তনীয় ধরনেরগুলি অন্যান্য অ্যাপ্লিকেশনগুলিতে খুব কমই কেন ব্যবহৃত হয়?

• এটি কি কারণ অপরিবর্তনীয় প্রকারের জন্য কোডটি লেখার পক্ষে এটি দীর্ঘতর,
• বা আমি কি কিছু মিস করছি এবং অপরিবর্তনীয় প্রকারগুলি ব্যবহার করার সময় কিছু গুরুত্বপূর্ণ ত্রুটি রয়েছে?

বাস্তব জীবন থেকে উদাহরণ

ধরা যাক আপনি এর Weatherমতো একটি রেস্টস্টুল এপিআই থেকে পেয়েছেন:

public Weather FindWeather(string city)
{
    // TODO: Load the JSON response from the RESTful API and translate it into an instance
    // of the Weather class.
}

আমরা সাধারণত যা দেখতে পাই তা হ'ল (কোডটি ছোট করার জন্য নতুন লাইন এবং মন্তব্যগুলি সরানো হয়েছে):

public sealed class Weather
{
    public City CorrespondingCity { get; set; }
    public SkyState Sky { get; set; } // Example: SkyState.Clouds, SkyState.HeavySnow, etc.
    public int PrecipitationRisk { get; set; }
    public int Temperature { get; set; }
}

অন্যদিকে, আমি এটিকে এ জাতীয়ভাবে লিখব, Weatherএপিআই থেকে একটি প্রাপ্তি , তারপরে পরিবর্তনটি অদ্ভুত হবে: বাস্তব জগতের আবহাওয়া পরিবর্তন করা Temperatureবা Skyপরিবর্তন করা যায় না, এবং পরিবর্তনের CorrespondingCityকোনও অর্থ হয় না।

public sealed class Weather
{
    private readonly City correspondingCity;
    private readonly SkyState sky;
    private readonly int precipitationRisk;
    private readonly int temperature;

    public Weather(City correspondingCity, SkyState sky, int precipitationRisk,
        int temperature)
    {
        this.correspondingCity = correspondingCity;
        this.sky = sky;
        this.precipitationRisk = precipitationRisk;
        this.temperature = temperature;
    }

    public City CorrespondingCity { get { return this.correspondingCity; } }
    public SkyState Sky { get { return this.sky; } }
    public int PrecipitationRisk { get { return this.precipitationRisk; } }
    public int Temperature { get { return this.temperature; } }
}

Comments

"এর জন্য আরও কাজ করা দরকার" - উদ্ধৃতি আবশ্যক। আমার অভিজ্ঞতায় এর জন্য কম কাজ দরকার ।

— কনরাড রুডলফ

@ কনরাডরুডল্ফ: আরও কাজ করে , আমি একটি পরিবর্তনযোগ্য শ্রেণি তৈরি করতে আরও কোড লিখতে চাইছি। আমার প্রশ্নের উদাহরণটি এটিকে ব্যাখ্যা করে, একটি পরিবর্তনীয় শ্রেণির জন্য 7 লাইন এবং এক অপরিবর্তনীয় শ্রেণীর জন্য 19 টি with

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

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

— Mert Akcakaya

@ মুর্ট: কোড স্নিপেটগুলি সাধারণ জিনিসের জন্য দুর্দান্ত। একটি কোড স্নিপেট লেখা যা ক্ষেত্র এবং বৈশিষ্ট্যের মন্তব্য সহ সঠিক শ্রেণি তৈরি করবে এবং সঠিক অর্ডারিং করা সহজ কাজ হবে না।

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

প্রদত্ত উদাহরণের সাথে আমি একমত নই, অপরিবর্তনীয় সংস্করণটি আরও এবং বিভিন্ন কাজ করে চলেছে। আপনি অ্যাক্সেসরগুলির সাথে সম্পত্তি ঘোষণা করে উদাহরণস্বরূপ-স্তর ভেরিয়েবলগুলি সরিয়ে ফেলতে পারবেন {get; private set;}, এবং এমনকি মিউটਟੇবলেরও একজন নির্মাণকারী থাকতে হবে কারণ those সমস্ত ক্ষেত্র সর্বদা সেট করা উচিত এবং আপনি কেন এটি প্রয়োগ করবেন না? এই দুটি পুরোপুরি যুক্তিসঙ্গত পরিবর্তনগুলি তাদের বৈশিষ্ট্য এবং এলওসি সমতাতে নিয়ে আসে।

— ফোশি

Answer 1

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

1. পরিবর্তনীয় প্রকারের সাথে তুলনা করে বাস্তবায়ন প্রচেষ্টা । অপরিবর্তনীয় প্রকারের সাথে, আপনার কোনও সংস্থার প্রয়োজন যাবতীয় বৈশিষ্ট্যের জন্য তর্ক করতে হবে। আপনার উদাহরণ একটি ভাল। আপনার 10 টি ক্লাস রয়েছে এমন প্রতিটি কল্পনা করে দেখুন 5-10 টি বৈশিষ্ট্য রয়েছে। কিছু সহজ করতে, আপনি এমনভাবে অনুরূপ গঠন করা বা সংশোধন করা অপরিবর্তনীয় দৃষ্টান্ত তৈরি করতে একটি রচয়িতা বর্গ আছে প্রয়োজন হতে পারে StringBuilderবা UriBuilderC #, অথবা WeatherBuilderআপনার ক্ষেত্রে। এটি আমার পক্ষে প্রধান কারণ যেহেতু আমি অনেকগুলি ক্লাস ডিজাইন করি তা এত চেষ্টা করার মতো নয়।
2. গ্রাহক ব্যবহারযোগ্যতা । পরিবর্তনীয় প্রকারের তুলনায় তুলনামূলকভাবে অপরিবর্তনীয় টাইপ ব্যবহার করা আরও বেশি কঠিন। ইনস্ট্যান্টেশন সমস্ত মান শুরু করার প্রয়োজন। অপরিচ্ছন্নতার অর্থ হ'ল আমরা কোনও বিল্ডার ব্যবহার না করে এর মানটি পরিবর্তনের জন্য কোনও পদ্ধতির কাছে উদাহরণটি পাস করতে পারি না এবং যদি আমাদের কোনও বিল্ডার প্রয়োজন হয় তবে তার অপূর্ণতা আমার (1) এর মধ্যে রয়েছে।
3. ভাষার কাঠামোর সাথে সামঞ্জস্যতা। অনেকগুলি ডেটা ফ্রেমওয়ার্কগুলিকে অপারেটিংয়ের জন্য মিউটেবল টাইপ এবং ডিফল্ট কনস্ট্রাক্টর প্রয়োজন। উদাহরণস্বরূপ, আপনি অপরিবর্তনীয় প্রকারের সাথে নেস্টেড লিনকিউ-টু-এসকিউএল কোয়েরি করতে পারবেন না, এবং উইন্ডোজ ফর্মের টেক্সটবক্সের মতো সম্পাদকগুলিতে সম্পাদনার জন্য বৈশিষ্ট্যগুলি আবদ্ধ করতে পারবেন না।

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

Comments

"ইনস্ট্যান্টেশনের আগেই সমস্ত মূল্যবোধ প্রয়োজন Also": এছাড়াও একটি পরিবর্তনীয় ধরণের কাজটি করা হয়, যদি না আপনি অবিচ্ছিন্ন ক্ষেত্রগুলির চারপাশে ভাসমান কোনও বস্তুর ঝুঁকি গ্রহণ না করেন ...

— জর্জিও

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

— tia

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

— জর্জিও

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

— কেভিন

আমি বর্তমানে এফ # তে কোড দিই, যেখানে অপরিবর্তনশীলতা ডিফল্ট (তাই কার্যকর করা সহজ)। আমি দেখতে পেলাম যে আপনার পয়েন্ট 3টি বড় বাধা। আপনি সর্বাধিক স্ট্যান্ডার্ড। নেট লাইব্রেরিগুলি ব্যবহার করার সাথে সাথে আপনাকে হুপের মধ্য দিয়ে ঝাঁপিয়ে পড়তে হবে। (এবং যদি তারা প্রতিবিম্ব ব্যবহার করে এবং এভাবে স্থাবরতার বাইপাস করে ... আরগ!)

— গুরান

Answer 2

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

পার্শ্ব প্রতিক্রিয়াগুলি বাতিল করে ফাংশন করা

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

একটি সাধারণ উদাহরণ হিসাবে, আপনার যদি এমন কোনও ফাংশন থাকে যা এর মতো পার্শ্ব প্রতিক্রিয়া সৃষ্টি করে:

// Make 'x' the absolute value of itself.
void make_abs(int& x);

তারপরে আমাদের কোনও অপরিবর্তনীয় পূর্ণসংখ্যার ডেটা প্রকারের দরকার নেই যা অপারেটরদের পোস্ট-ইনিশিয়েশনাল এসাইনমেন্টের মতো নিষেধ করে যাতে সেই ফাংশনটি পার্শ্ব প্রতিক্রিয়া এড়ায়। আমরা কেবল এটি করতে পারি:

// Returns the absolute value of 'x'.
int abs(int x);

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

সম্পূর্ণ কপি করার জন্য ব্যয়বহুল

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

// Transforms the vertices of the specified mesh by
// the specified transformation matrix.
void transform(Mesh& mesh, Matrix4f matrix);

এই মুহুর্তে জালটির জন্য কয়েক সহস্রাধিক বহুভুজের সাথে আরও কয়েকশো মেগাবাইট মেমরির প্রয়োজন হতে পারে, আরও বেশি প্রান্ত এবং প্রান্ত, একাধিক টেক্সচার মানচিত্র, আকারের লক্ষ্যবস্তু ইত্যাদি etc. পুরো জালটি কেবল এটি তৈরি করার জন্য অনুলিপি করা সত্যিই ব্যয়বহুল হবে ' transformপার্শ্ব প্রতিক্রিয়া মুক্ত ফাংশন, যেমন:

// Returns a new version of the mesh whose vertices been 
// transformed by the specified transformation matrix.
Mesh transform(Mesh mesh, Matrix4f matrix);

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

ধারাবাহিক ডেটা স্ট্রাকচারস

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

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

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

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

অপরিবর্তনীয় ওভারহেড

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

Answer 3

একমাত্র ত্রুটিটি আমি ভাবতে পারি যে তাত্ত্বিকভাবে অপরিবর্তনীয় ডেটার ব্যবহার পরিবর্তনীয়গুলির চেয়ে ধীর হতে পারে - একটি নতুন উদাহরণ তৈরি করা ধীরে ধীরে এবং বিদ্যমান তথ্যটি পরিবর্তনের চেয়ে আগেরটি সংগ্রহ করা ধীরে ধীরে।

অন্য "সমস্যা" হ'ল আপনি কেবল পরিবর্তনযোগ্য প্রকার ব্যবহার করতে পারবেন না। শেষ পর্যন্ত আপনাকে রাষ্ট্রটি বর্ণনা করতে হবে এবং আপনাকে এটি করতে পারস্পরিক পরিবর্তন করতে হবে - রাষ্ট্র পরিবর্তন না করে আপনি কোনও কাজ করতে পারবেন না।

তবে এখনও সাধারণ নিয়মটি হ'ল যেখানেই আপনি অপরিবর্তনীয় প্রকারের ব্যবহার করতে পারেন এবং প্রকারকে কেবল তখনই পরিবর্তনযোগ্য করে তোলা হয় যখন সেখানে সত্যিই কারণ করার কোনও কারণ থাকে ...

এবং " অপ্রয়োজনীয় প্রকারগুলি অন্যান্য অ্যাপ্লিকেশনগুলিতে এত কম কেন ব্যবহৃত হয়? " এই প্রশ্নের উত্তর দেওয়ার জন্য - আমি সত্যিই মনে করি না যে তারা ... আপনি যেখানেই দেখেন সবাই আপনার ক্লাসগুলিকে যেমন অপরিবর্তনীয় করে তোলার পরামর্শ দেন ... উদাহরণস্বরূপ: http://www.javapractices.com/topic/TopicAction.do?Id=29

Comments

আপনার উভয় সমস্যা যদিও হাস্কেলের মধ্যে নেই।

— ফ্লোরিয়ান মার্জাইন

@ ফ্লোরিয়ানমার্গাইন আপনি কি বিস্তারিত বর্ণনা করতে পারেন?

— এমপিপিও

অল্পতা স্মার্ট সংকলককে সত্য ধন্যবাদ নয়। এবং হাস্কেল-তে, এমনকি I / O একটি অপরিবর্তনীয় API এর মাধ্যমে।

— ফ্লোরিয়ান মার্জাইন

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

— সুপারক্যাট

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

— ম্যাক

Answer 4

যে কোনও বাস্তব-বিশ্বের সিস্টেমের মডেল করতে যেখানে জিনিসগুলি পরিবর্তন করতে পারে, পরিবর্তনযোগ্য স্থিতি কোথাও কোথাও এনকোড করা দরকার। কোনও বস্তু পরিবর্তনীয় স্থিতি ধরে রাখতে পারে এমন তিনটি প্রধান উপায় রয়েছে:

• অপরিবর্তনীয় কোনও জিনিসের পরিবর্তযোগ্য রেফারেন্স ব্যবহার করা
• একটি পরিবর্তনীয় অবজেক্টের জন্য অপরিবর্তনীয় রেফারেন্স ব্যবহার করে
• একটি পরিবর্তনীয় অবজেক্টের পরিবর্তনীয় রেফারেন্স ব্যবহার করে

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

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

Answer 5

আপনার ক্ষেত্রে উত্তরটি মূলত কারণ সি # তে অপরিবর্তনীয়তার পক্ষে কম সমর্থন ...

এটি দুর্দান্ত হবে যদি:

• ডিফল্টরূপে সবকিছু অপরিবর্তনীয় হবে যদি না অন্যথায় উল্লিখিত হয় (যেমন একটি 'পরিবর্তনযোগ্য' কীওয়ার্ড সহ), পরিবর্তনীয় এবং পরিবর্তনীয় প্রকারের মিশ্রণ বিভ্রান্তিকর হয়

• রূপান্তর পদ্ধতি ( With) স্বয়ংক্রিয়ভাবে উপলব্ধ হবে - যদিও ইতিমধ্যে এটি দেখুন সহ অর্জন করা যেতে পারে

• একটি নির্দিষ্ট পদ্ধতি কলের ফলাফল বলার উপায় থাকবে (যেমন ImmutableList<T>.Add) বাতিল করা যাবে না বা কমপক্ষে একটি সতর্কতা উত্পন্ন করবে

• এবং প্রধানত যদি সংকলকটি যথাসম্ভব যথাসম্ভব অনাবশ্যকতা নিশ্চিত করতে পারে যেখানে অনুরোধ করা হয়েছে (দেখুন https://github.com/dotnet/roslyn/issues/159 )

Comments

তৃতীয় পয়েন্টটি পুনরায়, রিসার্পারের একটি MustUseReturnValueAttributeকাস্টম বৈশিষ্ট্য রয়েছে যা ঠিক এটি করে। PureAttributeএকই প্রভাব আছে এবং এটি আরও ভাল।

— সেবাস্তিয়ান রেডল

Answer 6

অপরিবর্তনীয় ধরনেরগুলি অন্যান্য অ্যাপ্লিকেশনগুলিতে খুব কমই ব্যবহৃত হয় কেন?

অজ্ঞতা? অনভিজ্ঞতা?

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

Comments

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

— জর্জিও

@ জর্জিও: কিছু দেশে, এখনও অনেক ইঞ্জিনিয়ার লিনকিউ ছাড়াই সি # কোড লেখেন, এফপি ছাড়াই, পুনরাবৃত্তকারী এবং জেনেরিক ছাড়াই, তাই বাস্তবে, তারা 2003 এর পর থেকে সি # এর সাথে যা ঘটেছিল তা কোনওভাবেই মিস করেছেন If এমনকি যদি তারা তাদের পছন্দের ভাষাও না জানেন If , আমি এগুলিকে মূল-মূলধারার কোনও ভাষা জানার জন্য খুব কমই কল্পনা করেছি।

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

@ মাইনমা: ভালো যে আপনি ইটালিক্সে শব্দটি ইঞ্জিনিয়ারদের লিখেছেন ।

— জর্জিও

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

— আরসেনি মরজেনকো

@ মাইনমা: আমি একমত ইঞ্জিনিয়ার বা পরামর্শকের মতো শিরোনামগুলি প্রায়শই বিস্তৃত হয় যার কোনও বহুল-গ্রহণযোগ্য অর্থ নেই। এগুলি প্রায়শই কাউকে বা তাদের অবস্থানকে তার চেয়ে বেশি গুরুত্বপূর্ণ / মর্যাদাপূর্ণ করতে ব্যবহৃত হয়।

— জর্জিও