যদি অপরিবর্তনীয় বস্তু ভাল হয় তবে লোকেরা কেন পরিবর্তনীয় জিনিস তৈরি করতে থাকবে? [বন্ধ]

Question

যদি অপরিবর্তনীয় বস্তু¹ ভাল, সহজ হয় এবং সমবর্তী প্রোগ্রামিংয়ে সুবিধা দেয় কেন প্রোগ্রামাররা পারস্পরিক পরিবর্তনযোগ্য বস্তু তৈরি করে রাখে²?

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

---

^{¹ অপরিবর্তনীয় বস্তুর একটি বস্তু যার রাষ্ট্র পর এটি তৈরি করা হয় পরিবর্তন করা যেতে পারে।
² এর চপল বস্তুর একটি বস্তু যার পরে এটি তৈরি করা হয় পরিবর্তিত হতে পারে।}

Comments

আমি মনে করি যে, পৃথক্ বৈধ কারণে (নীচে পিটার উল্লেখ) থেকে, "অলস ডেভেলপার" "মূঢ়" ডেভেলপার "। আর আগে" মূঢ় ডেভেলপার চেয়ে বেশি প্রচলিত কারণ নেই "এছাড়াও আছে" -এর অজ্ঞ ডেভেলপার "।

— জোয়াকিম সয়ার

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

— বাইনারি ওয়ারিয়ার

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

— জোছিম সউর

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

— বাইনারি ওয়ারিয়ার

-1, অপরিবর্তনীয় বস্তু 'ভাল' না। সুনির্দিষ্ট পরিস্থিতির জন্য আরও কম-বেশি উপযুক্ত। যে কেউ আপনাকে একটি কৌশল বা অন্যটি বলছে সে হ'ল উদ্দেশ্য বা 'ভাল' বা অন্যটির থেকে সমস্ত পরিস্থিতির জন্য আপনাকে ধর্ম বিক্রি করছে।

— গ্র্যান্ডমাস্টারবি

Answer 1

পরিবর্তনীয় এবং অপরিবর্তনীয় উভয় বস্তুর নিজস্ব ব্যবহার, উপকারিতা এবং কনস রয়েছে।

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

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

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

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

Comments

সেটা ঠিক. বিশেষত জিইউআই প্রোগ্রামিংয়ে, মিউটটেবল অবজেক্ট খুব সহজ।

— ফ্লোরিয়ান সালিহোভিক

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

— স্টিভেন এভার্স

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

— কনরাড রুডলফ

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

— প্যাটার তারেক

রাষ্ট্র বনাম পরিচয় সম্পর্কে আপনি একটি ভাল বক্তব্য রেখেছেন। এই কারণেই রিজ হিকি (ক্লোজারের লেখক) ক্লোজুরে দুটি আলাদা করেছিলেন apart যে কেউ তর্ক করতে পারে, আপনার যে গাড়িটি ১/২ টি ট্যাঙ্ক রয়েছে তার সাথে গাড়িটি 1/4 ট্যাঙ্ক গ্যাসের মতো গাড়ি নয়। তাদের একই পরিচয় রয়েছে, তবে তারা একই নয়, আমাদের বাস্তবতার সময়ের প্রতিটি "টিক" আমাদের বিশ্বের প্রতিটি বস্তুর একটি ক্লোন তৈরি করে, আমাদের মস্তিস্ক কেবল এগুলি একসাথে একটি সাধারণ পরিচয় দিয়ে সেলাই করে। সময় উপস্থাপনের জন্য ক্লোজুরে রেফস, পরমাণু, এজেন্ট ইত্যাদি রয়েছে। এবং প্রকৃত সময়ের জন্য মানচিত্র, ভেক্টর এবং তালিকা।

— টিমোথি বাল্ড্রিজ

Answer 2

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

Comments

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

— পিটার Török

@ পেটারট্রিক এটি কেবল অতিরিক্ত প্রচেষ্টা নয় - এটি আপনার সত্য সহকারী কোডাররা আপনাকে অগ্নিপরীক্ষায় ঝুলিয়ে দিতে চাইবে কারণ তারা আপনার কোডিংয়ের স্টাইলটি তাদের অভিজ্ঞতার চেয়ে ভিনগ্রহের বলে মনে করে। এটি এই ধরণের জিনিসকে নিরুৎসাহিত করে।

— ওনোরিও ক্যাটেনাচি

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

— পিয়েটার টার্ক

@ পিটারট্রিক একটি অত্যাবশ্যকীয় ভাষায় পরিবর্তনযোগ্য অবজেক্টগুলি হ'ল ডিফল্ট আচরণ। আপনি যদি কেবল অপরিবর্তনীয় বস্তু চান তবে কার্যকরী ভাষায় স্যুইচ করা ভাল।

— এমুরি

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

— আসাদ সাইদুদ্দীন

Answer 3

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

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

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

       public class ImmutablePerson { 
   
        public ImmutablePerson(string name, ImmutableEventList eventsToAttend)
        {
             this.name = name;
             this.eventsToAttend = eventsToAttend;
        }
        private string name;
        private ImmutableEventList eventsToAttend;
   
        public string Name { get { return this.name; } }
   
        public ImmutablePerson RSVP(ImmutableEvent immutableEvent){
            // the person is RSVPing an event, thus mutating the state 
            // of the eventsToAttend.  so we need a new person with a reference
            // to the new Event
            ImmutableEvent newEvent = immutableEvent.OnRSVPReceived(this);
            ImmutableEventList newEvents = this.eventsToAttend.Add(newEvent));
            var newSelf = new ImmutablePerson(name, newEvents);
            return newSelf;
        }
       }
   
       public class ImmutableEvent { 
        public ImmutableEvent(DateTime when, ImmutablePersonList peopleAttending, ImmutablePersonList peopleNotAttending){
            this.when = when;     
            this.peopleAttending = peopleAttending;
            this.peopleNotAttending = peopleNotAttending;
        }
        private DateTime when; 
        private ImmutablePersonList peopleAttending;
        private ImmutablePersonList peopleNotAttending;
        public ImmutableEvent OnReschedule(DateTime when){
              return new ImmutableEvent(when,peopleAttending,peopleNotAttending);
        }
        //  notice that this will be an infinite loop, because everytime one counterpart
        //  of the bidirectional relationship is added, its containing object changes
        //  meaning it must re construct a different version of itself to 
        //  represent the mutated state, the other one must update its
        //  reference thereby obsoleting the reference of the first object to it, and 
        //  necessitating recursion
        public ImmutableEvent OnRSVPReceived(ImmutablePerson immutablePerson){
              if(this.peopleAttending.Contains(immutablePerson)) return this;
              ImmutablePersonList attending = this.peopleAttending.Add(immutablePerson);
              ImmutablePersonList notAttending = this.peopleNotAttending.Contains( immutablePerson ) 
                                   ? peopleNotAttending.Remove(immutablePerson)
                                   : peopleNotAttending;
              return new ImmutableEvent(when, attending, notAttending);
        }
       }
       public class ImmutablePersonList
       {
         private ImmutablePerson[] immutablePeople;
         public ImmutablePersonList(ImmutablePerson[] immutablePeople){
             this.immutablePeople = immutablePeople;
         }
         public ImmutablePersonList Add(ImmutablePerson newPerson){
             if(this.Contains(newPerson)) return this;
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length];
             for(var i=0;i<immutablePeople.Length;i++)
                 newPeople[i] = this.immutablePeople[i];
             newPeople[immutablePeople.Length] = newPerson;
         }
         public ImmutablePersonList Remove(ImmutablePerson newPerson){
             if(immutablePeople.IndexOf(newPerson) != -1)
             ImmutablePerson[] newPeople = new ImmutablePerson[immutablePeople.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutablePeople[i] == newPerson;
                newPeople[i] = this.immutablePeople[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutablePersonList(newPeople);
         }
         public bool Contains(ImmutablePerson immutablePerson){ 
            return this.immutablePeople.IndexOf(immutablePerson) != -1;
         } 
       }
       public class ImmutableEventList
       {
         private ImmutableEvent[] immutableEvents;
         public ImmutableEventList(ImmutableEvent[] immutableEvents){
             this.immutableEvents = immutableEvents;
         }
         public ImmutableEventList Add(ImmutableEvent newEvent){
             if(this.Contains(newEvent)) return this;
             ImmutableEvent[] newEvents= new ImmutableEvent[immutableEvents.Length];
             for(var i=0;i<immutableEvents.Length;i++)
                 newEvents[i] = this.immutableEvents[i];
             newEvents[immutableEvents.Length] = newEvent;
         }
         public ImmutableEventList Remove(ImmutableEvent newEvent){
             if(immutableEvents.IndexOf(newEvent) != -1)
             ImmutableEvent[] newEvents = new ImmutableEvent[immutableEvents.Length-2];
             bool hasPassedRemoval = false;
             for(var i=0;i<immutablePeople.Length;i++)
             {
                hasPassedRemoval = hasPassedRemoval || immutableEvents[i] == newEvent;
                newEvents[i] = this.immutableEvents[hasPassedRemoval ? i + 1 : i];
             }
             return new ImmutableEventList(newPeople);
         }
         public bool Contains(ImmutableEvent immutableEvent){ 
            return this.immutableEvent.IndexOf(immutableEvent) != -1;
         } 
       }
   

Comments

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

— স্মার্টকাভম্যান

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

— স্মার্টকাভম্যান

@ স্মার্টকাভম্যান সম্পর্কে (2), আমিও একমত নই: সাধারণভাবে, "দ্বিদ্বন্দ্বী সম্পর্ক" হ'ল গনিতিক ধারণাটি পরিবর্তনের অরথোগোনাল। সাধারণত জাভাতে কার্যকর হিসাবে এটির জন্য পরিবর্তনের প্রয়োজন হয় না (আমি সেই বিষয়ে আপনার সাথে একমত হয়েছি)। তবে, আমি একটি বিকল্প বাস্তবায়নের কথা ভাবতে পারি: নির্মাণকারীর সাথে দুটি বস্তুর মধ্যে একটি সম্পর্ক শ্রেণি Relationship(a, b); সম্পর্ক তৈরি করার সময়ে, উভয় সত্তা a& bইতিমধ্যে বিদ্যমান এবং সম্পর্কটি নিজেও অপরিবর্তনীয়। আমি জাভাতে এই পদ্ধতির ব্যবহারিক বলে বলছি না; এটা সম্ভব।

— আন্দ্রেস এফ।

@AndresF।, সুতরাং, আপনি কি বলছে তা যদি উপর ভিত্তি করে Rহয় Relationship(a,b)এবং উভয় aএবং bঅপরিবর্তনীয় হয়, তন্ন তন্ন aনা bএকটি রেফারেন্স রাখা হবে R। এটি কাজ করার জন্য, রেফারেন্সটি অন্য কোথাও (স্ট্যাটিক শ্রেণীর মতো) সংরক্ষণ করতে হবে। আমি কি আপনার উদ্দেশ্যটি সঠিকভাবে বুঝতে পারি?

— স্মার্টকাভম্যান

অবিচ্ছিন্ন উপাত্তের জন্য দ্বি-নির্দেশমূলক সম্পর্ক সংরক্ষণ করা সম্ভব কারণ ছাতুলহু অলসতার মাধ্যমে নির্দেশ করে। এটি করার একটি উপায় এখানে রয়েছে: haskell.org/haskellwiki/Tying_the_Knot

— টমাস এডিং

Answer 4

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

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

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

Comments

এটি কি ওকাসাকি বই?

— যান্ত্রিক শামুক

হাঁ। কিন্ডা শুকনো তবে এক টন ভালো তথ্য ...

— পল সানওয়াল্ড

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

— থমাস আহলে

যদিও সর্বশেষ বাক্যটি অতীতে সম্ভবত সত্য ছিল এটি স্পষ্ট নয় যে এটি ভবিষ্যতে সত্যই থাকবে, বর্তমান হার্ডওয়্যার প্রবণতা ইত্যাদির

— ভিত্তিতে

Answer 5

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

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

Comments

সম্ভবত "জনপ্রিয়" পরিবর্তে "পরিচিত" শব্দটির আরও ভাল পছন্দ হবে।

— ডেন

হ্যা, তা ঠিক.

— ফ্লোরিয়ান সালিহোভিক

+1: আমি একমত: কিছু স্কালা এবং হাস্কেল শিখার পরে আমি জাভাতে ফাইনাল এবং সি ++ এ কোথাও কোথাও ব্যবহার করার ঝোঁক। সম্ভব হলে আমি অপরিবর্তনীয় বস্তুও ব্যবহার করি এবং, যদিও পরিবর্তনীয় অবজেক্টগুলি এখনও খুব ঘন ঘন প্রয়োজন হয়, আপনি কতবার অপরিবর্তনীয় জিনিসগুলি ব্যবহার করতে পারেন তা আশ্চর্যরকম।

— জর্জিও

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

— জর্জিও

Answer 6

আমি মনে করি এক প্রধান অবদান ফ্যাক্টর উপেক্ষা করা হয়েছে: জাভা বিন্স বস্তু mutating, এবং (বিশেষত উৎস বিবেচনা করা) এর একটি নির্দিষ্ট শৈলী উপর খুব বেশী নির্ভর বেশ কয়েক জনের নিতে বলে মনে হচ্ছে যে একটি (বা এমনকি হিসাবে ) ক্যানোনিকাল উদাহরণ কিভাবে সব জাভা লেখা উচিত।

Comments

+1, প্রথম তথ্য বিশ্লেষণের পরে কিছু ধরণের ডিফল্ট প্রয়োগ হিসাবে গেটার / সেটার প্যাটার্নটি প্রায়শই ব্যবহৃত হয়।

— জাপ

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

— ড্যারেল টিগু

Answer 7

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

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

তবে আজ যদি অনেক জুনিয়র প্রোগ্রামাররা হাইবারনেট বা অন্য কোনও ওআরএম ব্যবহার করে এন্টারপ্রাইজ সিস্টেমে দাঁত কাটা হয় তবে সম্ভবত তারা পরিবর্তিত বস্তু ব্যবহারের অভ্যাসটি গ্রহণ করবে। হাইবারনেটের মতো ফ্রেমওয়ার্কগুলি পরিবর্তনীয় বস্তুর জনপ্রিয়তার অন্তর্ভুক্ত হতে পারে।

Comments

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

— ড্যারেল টিগু

Answer 8

একটি প্রধান বিষয় যা এখনও উল্লেখ করা হয়নি তা হ'ল কোনও বস্তুর স্থিতিস্থাপক হতে পারে এমন পদার্থের পরিচয় পাওয়া সম্ভব করে যা সেই রাজ্যটিকে অপরিবর্তনীয় করে তোলে ।

অনেক প্রোগ্রাম বাস্তব-বিশ্বের জিনিসগুলি অন্তর্নিহিত পরিবর্তনযোগ্য যা মডেল করার জন্য ডিজাইন করা হয়েছে। ধরুন, সকাল 12:51 টায় কিছু পরিবর্তনশীল AllTrucks# 451 অবজেক্টের রেফারেন্স ধরে রেখেছে, যা একটি ডেটা স্ট্রাকচারের মূল যা এই মুহুর্তে (12:51 am) একটি বহরের সমস্ত ট্রাকে কার্গো কী রয়েছে তা নির্দেশ করে এবং কিছু পরিবর্তনশীল BobsTruck# 24601 পয়েন্ট অবজেক্টের সাথে কোনও অবজেক্টের রেফারেন্স পেতে ব্যবহার করা যেতে পারে যা নির্দেশ করে যে এই মুহুর্তে (12:51 পূর্বাহ্নে) ববসের ট্রাকে কী কার্গো রয়েছে। সকাল 12:52 টায় কিছু ট্রাক (ববস সহ) লোড এবং আনলোড করা হয় এবং ডেটা স্ট্রাকচার আপডেট করা হয় যাতে AllTrucksএখন এমন একটি ডেটা স্ট্রাকচারের রেফারেন্স রাখা হবে যা নির্দেশ করে যে 12:52 সকাল পর্যন্ত সমস্ত ট্রাকগুলিতে কার্গো রয়েছে।

কি হবে BobsTruck?

যদি প্রতিটি ট্রাক অবজেক্টের 'কার্গো' সম্পত্তি অপরিবর্তনীয় থাকে তবে # 24601 অবজেক্টটি বরাবরের জন্য সকাল 12:51 তে রাষ্ট্রের প্রতিনিধিত্ব করবে Bob তাহলে BobsTruck# 24601 আপত্তি একটি সরাসরি রেফারেন্স ঝুলিতে, তারপর যদি না কোডটি আপডেট AllTrucksএছাড়াও আপডেট করতে ঘটবে BobsTruck, এটা বব এর ট্রাক বর্তমান অবস্থা প্রতিনিধিত্ব করতে বন্ধ করে দিবে। আরও মনে রাখবেন যে যদি BobsTruckনা কোনও রূপ পরিবর্তনযোগ্য অবজেক্টের আকারে সংরক্ষণ করা হয়, তবে কোডটি আপডেট করে এমন একমাত্র উপায়টি AllTrucksযদি কোডটি পরিষ্কারভাবে প্রোগ্রাম করার জন্য হয় med

যদি কেউ BobsTruckসমস্ত বস্তুকে অপরিবর্তনীয় রাখার সময় রাষ্ট্র ববের ট্রাক পর্যবেক্ষণ করতে সক্ষম হতে চায় , তবে BobsTruckএকটি অপরিবর্তনীয় কাজ হতে পারে যা AllTrucksকোনও নির্দিষ্ট সময়ে যে মূল্য রেখেছিল বা দেওয়া থাকলে তা ববের ট্রাকের স্থিতি অর্জন করতে পারে ঐ সময়. একটিতে এটি এক জোড়া অপরিবর্তনীয় কার্যাবলীও ধারণ করতে পারে - যার মধ্যে একটি উপরের মতো হবে, এবং অন্যটি একটি বহরের রাষ্ট্র এবং নতুন ট্রাক রাষ্ট্রের জন্য একটি রেফারেন্স গ্রহণ করবে এবং একটি নতুন বহরের রাষ্ট্রের একটি রেফারেন্স ফিরিয়ে দেবে যা পুরনোটির সাথে মিলেছে, ববের ট্রাকের সাথে নতুন রাজ্য থাকবে।

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

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

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

Answer 9

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

আমি মনে করি আপনার প্রশ্নের উত্তর দেওয়ার সর্বোত্তম এবং দ্রুততম উপায় হ'ল আপনার পক্ষে অপ্রচলতা বনাম পরিবর্তনীয়তার পক্ষে এবং কনসের পক্ষে নেতৃত্ব দিন ।

Answer 10

এই ব্লগ পোস্টটি দেখুন: http://www.yegor256.com/2014/06/09/objects-should-be- অবিচ্ছেদ্য html । এটি সংক্ষিপ্ত করে যে অপরিবর্তনীয় জিনিসগুলি পরিবর্তনের চেয়ে কেন ভাল। এখানে আর্গুমেন্টগুলির একটি সংক্ষিপ্ত তালিকা:

• অপরিবর্তনীয় বস্তুগুলি নির্মাণ, পরীক্ষা এবং ব্যবহার করা সহজ
• সত্যিকারের অপরিবর্তনীয় বস্তু সর্বদা থ্রেড-নিরাপদ
• তারা সাময়িক মিলন এড়াতে সহায়তা করে
• তাদের ব্যবহার পার্শ্ব-প্রতিক্রিয়া মুক্ত (কোনও প্রতিরক্ষামূলক অনুলিপি নেই)
• পরিচয় পরিবর্তনের সমস্যা এড়ানো হয়
• তাদের সর্বদা ব্যর্থতা পরমাণু থাকে have
• তারা ক্যাশে অনেক সহজ

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

Answer 11

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

এটি বেশিরভাগ ডেটা বাঁধাইয়ের সাথে চারটি সমস্যা রয়েছে :

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

আপনি # 1 এবং # 2 প্রশমিত @ConstructorPropertiesকরতে পারেন এবং অপরিবর্তনীয় অবজেক্টটি তৈরি করতে অন্য পরিবর্তনীয় বিল্ডার অবজেক্ট (সাধারণত সাবলীল) তৈরি করতে পছন্দ করতে পারেন ann

Answer 12

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

অপরিবর্তনীয় অবজেক্টগুলি প্রায় পুরো রাজ্যের বাগের শ্রেণিটি বাদ দেয়।

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

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

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

Answer 13

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

Answer 14

প্রোগ্রামিং ল্যাঙ্গুয়েজগুলি কম্পিউটার দ্বারা নির্বাহের জন্য ডিজাইন করা হয়েছে। কম্পিউটারের সমস্ত গুরুত্বপূর্ণ বিল্ডিং ব্লক - সিপিইউ, র‌্যাম, ক্যাশে, ডিস্ক - পরিবর্তনীয়। যখন তারা (বিআইওএস) হয় না, তারা সত্যিই পরিবর্তনযোগ্য এবং আপনি নতুন নতুন পরিবর্তনযোগ্য বস্তুও তৈরি করতে পারবেন না।

অতএব, অপরিবর্তনীয় বস্তুর উপরে নির্মিত যে কোনও প্রোগ্রামিং ল্যাঙ্গুয়েজ তার প্রয়োগের উপস্থাপনের ফাঁকে ভুগছে। এবং সি এর মতো প্রাথমিক ভাষাগুলির জন্য এটি ছিল একটি বড় বাধা।

Answer 15

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

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

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

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

পিএস হিসাবে, আমি বুঝতে পারি যে জাভা গিটার এবং সেটটারগুলি হাতছাড়া হয়ে যাচ্ছে। পরীক্ষা করে দেখুন এই বাইরে।

Comments

অপরিবর্তনীয় রাষ্ট্র এখনও রাষ্ট্র।

— জেরেমি হিলার

@JeremyHeiler: সত্য, কিন্তু এটা এমন কিছু বিষয় যা রাষ্ট্রের হয় চপল। যদি কিছুই রূপান্তরিত হয় না, কেবলমাত্র একটি রাষ্ট্র রয়েছে, যা কোনও রাষ্ট্রের মতো একই জিনিস।

— রাল্ফচাপিন

Answer 16

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

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

বাস্তবে যদিও আপনার নিয়মিতভাবে নিয়মিত দরকার, তবুও আপনার কোডটিতে সর্বদা একমাত্র উপায় সেটার বা লিখনযোগ্য বৈশিষ্ট্যগুলি হ'ল একটি বিল্ডার প্যাটার্নের মাধ্যমে যেখানে বস্তুটি সম্পূর্ণ তাত্ক্ষণিকভাবে চালিত হওয়ার পরে সেগুলি লক হয়ে যায়।

সৃষ্টির পরে অনেকগুলি শ্রেণি পরিবর্তনযোগ্য যা জরিমানা, এটির সরাসরি সম্পত্তি হস্তান্তর করা উচিত নয় - পরিবর্তে এটিতে প্রকৃত ব্যবসায়ের যুক্তিযুক্ত পদ্ধতিতে কলগুলির মাধ্যমে এটির বৈশিষ্ট্যগুলিতে ম্যানিপুলেট করতে বলা উচিত (হ্যাঁ, একটি সেস্টার বেশ সমান সম্পত্তি হিসাবে সরাসরি হস্তক্ষেপ হিসাবে জিনিস)

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

Answer 17

যখন অবজেক্টটি ইনস্ট্যান্ট করার পরে আপনাকে বহুগুণ মান নির্ধারণ করতে হবে তখন মিউটেবল অবজেক্টগুলি ব্যবহৃত হয়।

ছয়টি পরামিতি সহ আপনার কোনও কনস্ট্রাক্টর থাকা উচিত নয়। পরিবর্তে আপনি সেটার পদ্ধতিতে অবজেক্টটি পরিবর্তন করেন।

এর উদাহরণ হ'ল একটি প্রতিবেদন অবজেক্ট, ফন্টের জন্য সেটটার সহ, ওরিয়েন্টেশন ইত্যাদি is

সংক্ষেপে: আপনার যখন কোনও বস্তুতে সেট করার মতো অবস্থা প্রচুর থাকে এবং খুব দীর্ঘ কনস্ট্রাক্টর স্বাক্ষর থাকা ব্যবহারিক হবে না তখন সংক্ষিপ্ত পরিবর্তনগুলি দরকারী।

সম্পাদনা: বিল্ডার প্যাটার্নটি অবজেক্টের পুরো রাজ্যটি তৈরি করতে ব্যবহার করা যেতে পারে।

Comments

এটিকে উপস্থাপন করা হয় যেন একাধিক মান সেট করার একমাত্র উপায় হ'ল পরিবর্তনের পরে পরিবর্তন এবং পরিবর্তন changes সম্পূর্ণতার জন্য খেয়াল করুন যে বিল্ডার প্যাটার্ন সমান বা আরও বেশি শক্তিশালী ক্ষমতা সরবরাহ করে এবং অপরিবর্তনীয়তা ত্যাগ করার জন্য কোনওটির প্রয়োজন হয় না। new ReportBuilder().font("Arial").orientation("landscape").build()

— gnat

"খুব দীর্ঘ কনস্ট্রাক্টর স্বাক্ষর থাকা ব্যবহারিক হবে না।": আপনি সর্বদা ছোট বস্তুগুলিতে প্যারামিটারগুলি গ্রুপ করতে পারেন এবং এই বিষয়গুলিকে কনস্ট্রাক্টরের পরামিতি হিসাবে পাস করতে পারেন।

— জর্জিও

@ সিএইচও আপনি যদি 10 বা 15 টি বৈশিষ্ট্য নির্ধারণ করতে চান তবে কী হবে? এছাড়াও এটি ভাল বলে মনে হয় না যে একটি পদ্ধতি withFontএকটি রিটার্ন দেয় Report।

— তুলিনাস কর্ডোভা

যতক্ষণ না 10 বা 15 টি বৈশিষ্ট্য নির্ধারণ করা যায়, তেমন কোডটি বিশ্রী হবে না যদি (1) জাভা জানত কীভাবে এই সমস্ত মধ্যবর্তী বস্তুগুলির নির্মাণকে এলিডে রাখতে হয়, এবং (2) আবারও, নামগুলি মানক করা হয়েছিল। এটি অপরিবর্তনীয়তা নিয়ে সমস্যা নয়; এটি জাভাতে কীভাবে এটি কীভাবে ভাল করতে হবে তা না জানার সমস্যা।

— সিএওও

@ সিএইচও 20 টি বৈশিষ্ট্যের জন্য একটি কল চেইন করা কুশ্রী। কুশল কোডটি নিম্নমানের কোড হতে পারে।

— তুলাইনস কর্ডোভা

Answer 18

আমি মনে করি পরিবর্তনীয় অবজেক্টগুলি ব্যবহার অপরিহার্য চিন্তাভাবনা থেকে শুরু করে: আপনি ধাপে ধাপে পরিবর্তনীয় ভেরিয়েবলের সামগ্রী পরিবর্তন করে একটি ফলাফল গণনা করুন (পার্শ্ব প্রতিক্রিয়া দ্বারা গণনা)।

আপনি যদি কার্যত চিন্তা করেন, আপনি অপরিবর্তনীয় অবস্থা থাকতে চান এবং কোনও সিস্টেমের পরবর্তী অবস্থাগুলিকে ফাংশন প্রয়োগ করে এবং পুরানোগুলি থেকে নতুন মান তৈরি করে প্রতিনিধিত্ব করতে পারেন।

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

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

সুতরাং, কেন অনেক প্রোগ্রামার মিউটেবল অবজেক্ট ব্যবহার করেন? আইএমএইচও দুটি কারণে:

1. অনেক প্রগ্রেমার শিখেছে যে কীভাবে একটি অত্যাবশ্যক (পদ্ধতিগত বা অবজেক্ট-ভিত্তিক) দৃষ্টান্ত ব্যবহার করে প্রোগ্রাম করা যায়, অতএব পরিবর্তনকে গণনার সংজ্ঞা দেওয়ার জন্য তাদের মৌলিক পন্থা, অর্থাৎ কখন এবং কীভাবে অপরিবর্তনীয়তা ব্যবহার করতে হয় তা তারা জানে না কারণ তারা এর সাথে পরিচিত নয়।
2. অনেক প্রোগ্রামাররা খুব তাড়াতাড়ি পারফরম্যান্স সম্পর্কে চিন্তিত হন তবে কার্যত সঠিকভাবে এমন কোনও প্রোগ্রাম লেখার ক্ষেত্রে প্রথমে ফোকাস করা আরও কার্যকর হয় এবং তারপরে বাধা খুঁজে বের করার চেষ্টা করে এবং এটি সর্বোত্তম করে তোলার চেষ্টা করে।

Comments

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

— সুপারক্যাট

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

— জর্জিও

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

— জর্জিও

(২) অপরিবর্তনীয় অবস্থা ব্যবহার না করার কারণ হিসাবে আমি ইতিমধ্যে কর্মক্ষমতা তালিকাভুক্ত করেছি। (1) সম্পর্কিত, অবশ্যই যে প্রক্রিয়াটি থ্রেডগুলির মধ্যে যোগাযোগকে কার্যকর করে তার জন্য কিছু পরিবর্তনযোগ্য অবস্থা প্রয়োজন, তবে আপনি এটি আপনার প্রোগ্রামিং মডেল থেকে আড়াল করতে পারেন, উদাহরণস্বরূপ অভিনেতা মডেল ( en.wikedia.org/wiki/Actor_model )। সুতরাং এমনকি যদি নিম্ন স্তরে আপনার যোগাযোগটি বাস্তবায়নের জন্য পরিবর্তনের প্রয়োজন হয় তবে আপনার একটি উচ্চ বিমূর্ত স্তর থাকতে পারে যেখানে আপনি অপরিবর্তনীয় বস্তুগুলি পিছনে পিছনে প্রেরণ করে থ্রেডগুলির মধ্যে যোগাযোগ করেন।

— জর্জিও

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

— জর্জিও

Answer 19

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

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

সুতরাং: আপনি অবজেক্টের সাথে কী করার পরিকল্পনা করছেন তার উপর নির্ভরশীল, পারফরম্যান্সের ক্ষেত্রে পরিবর্তনীয় বনাম অপরিবর্তনীয় বেছে নেওয়া একটি বিশাল পার্থক্য আনতে পারে।

Answer 20

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

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

case class Person(id: String, firstName: String, lastName: String)

val joe = Person("123", "Joe", "Doe")
val spouse = Person(id = "124", firstName = "Mary", lastName = "Moe")
val joeMarried = joe.copy(lastName = "Doe-Moe")

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

Comments

এই কিছু সারগর্ভ যোগ করার জন্য উপরে পয়েন্ট হয়েছে এবং পূর্বে 24 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না

— মশা

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

— হ্যান্স-পিটার স্টার

এই এক উদাহরণস্বরূপ জাভা এই সমস্যা ব্যাখ্যা গভীরতা যায়। এবং কমপক্ষে আরও 3 টি উত্তর অপ্রত্যক্ষভাবে এর সাথে সম্পর্কিত

— gnat

Answer 21

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

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

public abstract class FinalBase {

    private final int variable; // Unset

    /* if final really means immutable than
     * I shouldn't be able to set the variable
     * but I can.
     */
    public FinalBase(int variable) { 
        this.variable = variable;
    }

    public int getVariable() {
        return variable;
    }

    public abstract void method();
}

// This is not fully necessary for this example
// but helps you see how to set the final value 
// in a sub class.
public class FinalSubclass extends FinalBase {

    public FinalSubclass(int variable) {
        super(variable);
    }

    @Override
    public void method() {
        System.out.println( getVariable() );
    }

    @Override
    public int getVariable() {

        return super.getVariable();
    }

    public static void main(String[] args) {
        FinalSubclass subclass = new FinalSubclass(10);
        subclass.method();
    }
}

Answer 22

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

Comments

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

— আলেক্সি

Answer 23

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

Comments

finalবাস্তবে অপরিবর্তনীয়তার দিকে এক ধাপের প্রায় 1/4 আপনি কেন এটি উল্লেখ করছেন তা দেখছেন না।

— সিএইচও

আপনি কি আসলে আমার পোস্ট পড়েছেন?

— রাল্ফ এইচ

আপনি আসলে প্রশ্নটি পড়েছেন? :) এটির সাথে একেবারেই করার কিছুই ছিল না final। এ প্রসঙ্গে এটিকে final"বিবর্তনযোগ্য" এর সাথে সত্যই এক অদ্ভুত সংশ্লেষের বিষয়টি finalবোঝায় , যখন নির্দিষ্ট ধরণের রূপান্তরকে রোধ করা হয় । (

— বিটিডাব্লু

আমি বলছি না যে এখানে কোথাও আপনার কোনও বৈধ পয়েন্ট নেই। আমি বলছি আপনি এটি খুব ভালভাবে ব্যাখ্যা করছেন না। আমি সেমিটি দেখি যে আপনি সম্ভবত এটি নিয়ে কোথায় যাচ্ছেন তবে আপনাকে আরও এগিয়ে যাওয়া দরকার। যেমনটি, এটি কেবল বিভ্রান্ত দেখায়।

— সিএওও

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

— সিএওও