কোনও ডেটা অবজেক্টের ধরনটি অপরিবর্তনীয় হওয়ার জন্য ডিজাইন করা উচিত কিনা তা কীভাবে সিদ্ধান্ত নেওয়া যায়?

Question

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

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

Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");

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

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

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

Comments

এরলং-এ প্রোগ্রাম এবং পুরো সমস্যার সমাধান হয়ে যায়, সবকিছু স্থাবর

— জ্যাকারি কে

@ জাচার্যেকে আমি আসলে ফাংশনাল প্রোগ্রামিং সম্পর্কে কিছু উল্লেখ করার কথা ভাবছিলাম, তবে ক্রিয়ামূলক প্রোগ্রামিং ভাষার সাথে আমার সীমিত অভিজ্ঞতার কারণে বিরত থাকি।

— রিকিট

Answer 1

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

Answer 2

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

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

Comments

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

— 9000

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

— ডোভাল

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

— রবার্ট হার্ভে

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

— ডোভাল

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

— রবার্ট হার্ভে

Answer 3

কোনও বস্তু অপরিবর্তনীয় কিনা তা সিদ্ধান্ত নেওয়ার দুটি প্রধান উপায় রয়েছে।

ক) বস্তুর প্রকৃতির উপর ভিত্তি করে

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

খ) নকশা পছন্দ, বাহ্যিক কারণের উপর ভিত্তি করে

এটি java.lang.String উদাহরণের মতো। স্ট্রিংগুলি সময়ের সাথে সাথে আসলে পরিবর্তিত হতে পারে তবে নকশা অনুসারে, তারা ক্যাচিং / স্ট্রিং পুল / একযোগিতাপূর্ণ কারণের কারণে একে অপরিবর্তনীয় করে তুলেছে। ক্যাচিং / সমঝোতা ইত্যাদির অনুরূপ হ'ল অ্যাপ্লিকেশনটির ক্ষেত্রে ক্যাচিং / সমঝোতা এবং সম্পর্কিত পারফরম্যান্স অত্যাবশ্যক হলে কোনও অব্যবস্থা স্থল করে তুলতে ভাল ভূমিকা নিতে পারে। তবে এই প্রভাবটি সমস্ত প্রভাব প্রভাবিত করার পরে খুব সাবধানে নেওয়া উচিত।

অপরিবর্তনীয় অবজেক্টের প্রধান সুবিধা হ'ল এগুলি টমপ-ওয়েড প্যাটার্নের শিকার হয় না ie বস্তুটি জীবনের সময়কালে কোনও পরিবর্তন গ্রহণ করবে না এবং এটি কোডিং এবং রক্ষণাবেক্ষণকে খুব সহজ করে তোলে।

Answer 4

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

একটি প্রোগ্রামের অবস্থা হ্রাস করা অত্যন্ত উপকারী।

তারা যদি আপনার ক্লায়েন্টের ক্লাস থেকে অস্থায়ী স্টোরেজ করার জন্য আপনার ক্লাসগুলির মধ্যে একটিতে পরিবর্তনীয় মান ধরণের ব্যবহার করতে চান তবে তাদের জিজ্ঞাসা করুন।

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

Answer 5

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

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

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

বৃহত্তর মান অবজেক্টের জন্য, যদি এগুলি অপরিবর্তনীয় করে তুলতে অসুবিধা হয় তবে তাদের অনুলিপি করা সহজ করুন।

Comments

সি বা সি ++ লেখার সময় স্ট্যাক এবং হিপগুলির মধ্যে কীভাবে বেছে নেওয়ার মতো অনেকটা মনে হচ্ছে :)

— রিকিট

@ রিকিট: এতটা আইএমও নয়। স্ট্যাক / হিপ বস্তুর আজীবন নির্ভর করে। স্ট্যাকের মধ্যে পারস্পরিক পরিবর্তনযোগ্য জিনিস রাখা সি ++ তে খুব সাধারণ।

— কেভিন ক্লিন

Answer 6

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

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

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

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

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

Comments

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

— সুপারক্যাট

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

— সুপারক্যাট

Answer 7

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

উদাহরণস্বরূপ, এটি অত্যন্ত ব্যয়বহুল হতে পারে:

/// @return A new mesh whose vertices have been transformed
/// by the specified transformation matrix.
Mesh transform(Mesh mesh, Matrix4f matrix);

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

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

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

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

/// @return The v1 * v2.
Vector3f vec_mul(Vector3f v1, Vector3f v2);

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

Answer 8

Foo a = new Foo();
a.setProperty1("asdf");
a.setProperty2("bcde");

যদি ফু এর কেবল দুটি বৈশিষ্ট্য থাকে, তবে এমন দুটি কনট্রাক্টর লেখার পক্ষে এটি লিখতে সহজ write তবে ধরুন আপনি অন্য সম্পত্তি যুক্ত করেছেন। তারপরে আপনাকে আরও একটি কনস্ট্রাক্টর যুক্ত করতে হবে:

public Foo(String a, String b, SomethingElse c)

এই মুহুর্তে, এটি এখনও পরিচালনাযোগ্য able তবে 10 টি সম্পত্তি থাকলে কী হবে? আপনি 10 টি যুক্তি সহ কোনও কনস্ট্রাক্টর চান না। দৃষ্টান্ত তৈরি করতে আপনি বিল্ডার প্যাটার্নটি ব্যবহার করতে পারেন তবে এতে জটিলতা যুক্ত হয়। এই সময়ের মধ্যে, আপনি ভাবতে থাকবেন "কেন আমি সাধারণ মানুষের মতো সমস্ত সম্পত্তিগুলির জন্য কেবল সেটারগুলি যুক্ত করিনি"?

Comments

10 টি যুক্তিযুক্ত কোনও কনস্ট্রাক্টর কি নলপয়েন্টারএক্সেপশনের চেয়েও খারাপ যেটি যখন সম্পত্তি 7 সেট করা হয়নি? বিল্ডার প্যাটার্ন কি প্রতিটি পদ্ধতিতে অবিচ্ছিন্ন বৈশিষ্ট্যগুলি পরীক্ষা করার কোডের চেয়ে জটিল? অবজেক্টটি তৈরি হয়ে গেলে একবার পরীক্ষা করা ভাল।

— কেভিন ক্লাইনে

যেমনটি দশকের আগে ঠিক এই ক্ষেত্রে বলা হয়েছিল, "দশটি পরামিতি সহ আপনার যদি কোনও পদ্ধতি থাকে তবে আপনি সম্ভবত কিছুটি মিস করেছেন missed"

— 9000

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

— রিকিট

@ রিকিট: কারণ এটি যুক্তিগুলিকে ভুল ক্রমে রাখার ঝুঁকি বাড়ায় । যদি আপনি সেটার বা বিল্ডার প্যাটার্ন ব্যবহার করেন তবে এটির সম্ভাবনা খুব কম।

— মাইক বারানজাক

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

— অ্যাডাম শিখুন