আপনি যখন পরামিতিগুলির সাথে একটি তৈরি করেন তখন ডিফল্ট প্যারামিটারলেস কনস্ট্রাক্টর কেন চলে যায়

Question

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

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

Comments

এমন আচরণের ভাষাগুলির তালিকায় আপনি সি ++ যুক্ত করতে পারেন।

— হেন্ক হলটারম্যান

এবং সি ++ এ আপনি এখন Foo() = default;ডিফল্টটিকে ফিরে পেতে বলতে পারেন।

— এমসাল্টারস

যদি প্যারামিটার সহ আপনার কনস্ট্রাক্টরের সমস্ত পরামিতিগুলির জন্য ডিফল্ট আর্গুমেন্ট থাকতে পারে তবে এটি বিল্ট-ইন প্যারামিটারলেস কনস্ট্রাক্টরের সাথে বিরোধ করবে, সুতরাং আপনি নিজের তৈরি করার সময় এটি মুছতে হবে।

— মরউভেন

ডিফল্ট নির্মাণকারীর প্রয়োজনীয়তা তৈরি করার জন্য প্রথম সংকলকটির প্রতিষ্ঠাতা এবং এটির উত্তপ্ত আলোচনার অনুপ্রেরণা ঘটবে বলে এই বিতর্কটির জন্য উপস্থিত থাকার কথা কল্পনা করুন।

— কিংডাংগো

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

— জন হান্না

Answer 1

কোনও কারণ নেই যে সংকলক নির্মাণকারীর সংযোজন করতে পারেননি যদি আপনি নিজের নিজস্ব যুক্ত করেন - সংকলকটি যা খুশি তাই করতে পারে! যাইহোক, আপনি কী সর্বাধিক অর্থপূর্ণ তা দেখতে হবে:

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

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

Comments

আমি মনে করি আপনার উত্তর বাকী বেশিরভাগ ক্ষেত্রে আপনার প্রথম বাক্যটি ভুল প্রমাণ করে।

— কনরাড রুডল্ফ

@ কনরাড রুডল্ফ, প্রথম বাক্যে বলা হয়েছে যে একটি সংকলক এই দৃশ্যে একজন কনস্ট্রাক্টর যুক্ত করতে পারে - বাকী উত্তরটি কেন তা না করে তা ব্যাখ্যা করে (প্রশ্নে বর্ণিত ভাষার জন্য)

— জনল

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

— জন হান্না

Answer 2

ভাষাটি কেন এইভাবে ডিজাইন করা হয়েছে তার কোনও প্রযুক্তিগত কারণ অবশ্যই নেই ।

চারটি কিছু বাস্তব-বাস্তব বিকল্প রয়েছে যা আমি দেখতে পাচ্ছি:

1. কোনও ডিফল্ট নির্মাণকারী নেই
2. বর্তমান পরিস্থিতি
3. সর্বদা ডিফল্টরূপে একটি ডিফল্ট নির্মাতা সরবরাহ করে তবে এটি স্পষ্টভাবে দমন করতে দেয়
4. সর্বদা ডিফল্ট নির্মাতাকে এটি দমন করার অনুমতি না দিয়ে সরবরাহ করে

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

বিকল্প 2 আমি ভাল আছি।

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

বিকল্প 4 ভয়াবহ - আপনি একেবারে নির্দিষ্ট পরামিতিগুলির সাথে নির্মাণকে জোর করতে সক্ষম হতে চান। এর new FileStream()অর্থ কি?

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

Comments

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

— পেটর মেনসিক

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

— জন স্কিটে

@ পেটারমেনসিক: দুঃখিত, আমার ভুল, হ্যাঁ এটি অবশ্যই আমার অভিজ্ঞতার বিপরীতে - এবং আমি যুক্তি দিয়েছিলাম যে কোনও কিছু স্বয়ংক্রিয়ভাবে অন্তর্ভুক্ত করাও এটি আরও বিপজ্জনক বিকল্প ... যদি আপনি দুর্ঘটনাক্রমে এটিকে বাদ না দিয়ে থাকেন তবে আপনি আপনার আক্রমণকারীদের ফাঁকি দিতে পারেন ইত্যাদি।

— জোন স্কেট

# 4 হ'ল সি # structএস এর ক্ষেত্রে আরও ভাল বা খারাপ।

— জে বাজুজি

আমি বিকল্প 1 পছন্দ করি কারণ এটি বোঝা সহজ। এমন কোনও "যাদু" নির্মাতা যা আপনি কোডটিতে দেখতে পাচ্ছেন না। বিকল্প 1 সহ সংকলকটির যখন একটি সতর্কীকরণ নির্গত করা উচিত (বা সম্ভবত এমনকি তাও অস্বীকার করবেন?) একটি অ স্থিত শ্রেণীর কোনও উদাহরণ নির্মাণকারী নেই। কীভাবে: "<TYPE> শ্রেণীর জন্য কোনও কনস্ট্যান্ট কনস্ট্রাক্টর পাওয়া যায় নি you আপনি কি ক্লাসটিকে স্থির ঘোষণা করার অর্থ দিয়েছিলেন?"

— জেপ্পে স্টিগ নীলসন

Answer 3

সম্পাদনা করুন। প্রকৃতপক্ষে, আমি আমার প্রথম উত্তরে যা বলি তা বৈধ, তবে এটিই আসল কারণ .:

শুরুতে সি ছিল বস্তু-ভিত্তিক নয় (আপনি একটি ওও পদ্ধতির গ্রহণ করতে পারেন তবে এটি আপনাকে কোনও কিছু কার্যকর করতে বা প্রয়োগ করতে পারে না)।

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

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

তবে সি ++ এর সাথে একটি লক্ষ্য সিটির সাথে সামঞ্জস্যপূর্ণ হওয়া যে যতটা সম্ভব, সমস্ত বৈধ সি প্রোগ্রামগুলিও বৈধ সি ++ প্রোগ্রাম ছিল (আর লক্ষ্য হিসাবে তত সক্রিয় নয়, এবং সি + এর সাথে বি বিবর্তনের অর্থ এটি আর ধারণ করে না )।

এর একটা প্রভাব মধ্যে কার্যকারিতা অনুলিপি ছিল structএবং class। পূর্বের কাজগুলি সি ওয়ে (ডিফল্টরূপে সর্বজনীন সর্বজনীন) এবং পরবর্তীকর্মগুলি ভাল ওও উপায়ে কাজগুলি করে (ডিফল্টরূপে ব্যক্তিগতভাবে সমস্ত কিছু, বিকাশকারী সক্রিয়ভাবে তারা কী প্রকাশ্যে চায় তা প্রকাশ করে)।

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

সমস্ত সি structsএখন বৈধ সি ++ structs, (যার অর্থ তারা সি ++ এর মতো classesসমস্ত কিছুর সাথে একই ছিল - সদস্য এবং উত্তরাধিকার - পাবলিক) বাইরে থেকে চিকিত্সা করা হয়েছিল যেন এটিতে একটি একক, প্যারামিটারলেস কনস্ট্রাক্টর রয়েছে।

তবে আপনি যদি কোনও classবা structএকটিতে কনস্ট্রাক্টর রেখেছিলেন তবে আপনি সি উপায়ের পরিবর্তে সি ++ / ওও পদ্ধতিতে কাজ করছিলেন এবং কোনও ডিফল্ট কনস্ট্রাক্টরের প্রয়োজন ছিল না।

যেহেতু এটি একটি শর্টহ্যান্ড হিসাবে পরিবেশন করেছে, সামঞ্জস্যতা অন্যথায় সম্ভব না হলেও এমনকি লোকেরা এটি ব্যবহার করে চলেছে (এটি অন্যান্য সি ++ বৈশিষ্ট্যগুলি সি তে নয়) ব্যবহার করে।

সুতরাং জাভা যখন বিভিন্ন উপায়ে সি ++ এর উপর ভিত্তি করে এসেছিল এবং পরে সি # (বিভিন্ন উপায়ে সি ++ এবং জাভা ভিত্তিক) তখন তারা এই পদ্ধতির এমন কিছু রেখেছিল যেহেতু কোডার ইতিমধ্যে অভ্যস্ত হতে পারে।

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

=== আসল উত্তর ===

যাক বলুন এটি ঘটেনি।

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

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

যা ভাষাটিকে আরও জটিল করে তোলে। না করাই ভাল।

সব মিলিয়ে ডিফল্ট অপসারণ হিসাবে কনস্ট্রাক্টর যুক্ত করার কথা না ভাবা ভাল, প্যারামিটারলেস কনস্ট্রাক্টর যা কিছু না করে যোগ করার জন্য সিনট্যাকটিক চিনির মতো কোনও কনস্ট্রাক্টর না থাকার কথা ভাবাই ভাল।

Comments

এবং আবারও, আমি দেখছি যে কেউ এটিকে ভোট দেওয়ার পক্ষে এটি একটি খারাপ উত্তর, তবে আমার বা অন্য কাউকে আলোকিত করে বিরক্ত করা যায় না। যা হতে পারে, আপনি জানেন, দরকারী।

— জন হান্না

আমার উত্তর একই। ভাল আমি এখানে কিছু ভুল দেখছি না তাই আমার কাছ থেকে +1 করুন।

— বটজ 3000

@ বটজ ৩০০০ আমি স্কোর সম্পর্কে চিন্তা করি না তবে তাদের যদি সমালোচনা হয় তবে আমি এটি পড়তে পারি। তবুও, এটি আমাকে উপরের কিছু যুক্ত করার জন্য ভাবিয়ে তোলে।

— জন হানা

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

— জন হান্না

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

— জন হান্না

Answer 4

অবজেক্ট তৈরির উপর নিয়ন্ত্রণ রাখতে আপনি যদি নিজে কিছু না করেন তবে ডিফল্ট, প্যারামিটারলেস কনস্ট্রাক্টর যুক্ত হয়। একবার আপনি নিয়ন্ত্রণ নেওয়ার জন্য একক নির্মাণকারী তৈরি করলে, সংকলকটি "ব্যাক অফ" হয়ে যায় এবং আপনাকে সম্পূর্ণ নিয়ন্ত্রণ রাখতে দেয়।

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

Comments

আপনার কাছে আসলে সেই বিকল্প আছে। প্যারামিটারলেস কনস্ট্রাক্টরকে ব্যক্তিগত তৈরি করা

— mw_21

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

— অ্যান্ডারস আবেল

Answer 5

এটি সংকলকের একটি সুবিধাজনক ফাংশন। আপনি যদি প্যারামিটার সহ কোনও কনস্ট্রাক্টর সংজ্ঞায়িত করেন তবে প্যারামিটারলেস কনস্ট্রাক্টর সংজ্ঞায়িত না করেন তবে আপনি প্যারামিটারলেস কনস্ট্রাক্টরকে অনুমতি দিতে চান না এমন সম্ভাবনা অনেক বেশি।

এটি এমন অনেকগুলি অবজেক্টের ক্ষেত্রে যা খালি কন্সট্রাক্টর দিয়ে আরম্ভ করার অর্থ দেয় না।

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

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

Answer 6

আমার মনে হয় প্রশ্নটি অন্যভাবে হওয়া উচিত: আপনি যদি অন্য কোনও কনস্ট্রাক্টর সংজ্ঞায়িত না করে থাকেন তবে কেন আপনাকে ডিফল্ট কনস্ট্রাক্টর ঘোষণা করার দরকার নেই?

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

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

Answer 7

ডিফল্ট কনস্ট্রাক্টর কেবল তখনই তৈরি করা যায় যখন ক্লাসে কনস্ট্রাক্টর না থাকে। সংযোজকগুলি এমনভাবে লিখিত হয় যাতে এটি কেবলমাত্র ব্যাকআপ প্রক্রিয়া হিসাবে সরবরাহ করে।

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

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

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

Answer 8

প্রতিজ্ঞা

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

ডিফল্ট কনস্ট্রাক্টর সরানোর উপায়

এটি অনুসরণ করে যে ডিফল্ট পাবলিক প্যারামিটারলেস কনস্ট্রাক্টর অপসারণ করার একটি উপায় থাকতে হবে। এই অপসারণ নিম্নলিখিত উপায়ে সম্পন্ন করা যেতে পারে:

1. একটি জন-সরকারী পরামিতিহীন নির্মাতা ঘোষণা করুন
2. প্যারামিটারযুক্ত কনস্ট্রাক্টর ঘোষিত হলে প্যারামিটারলেস কনস্ট্রাক্টর স্বয়ংক্রিয়ভাবে সরান
3. প্যারামিটারলেস কনস্ট্রাক্টর অপসারণ করার জন্য সংকলকটিকে নির্দিষ্ট করার জন্য কিছু কীওয়ার্ড / বৈশিষ্ট্য (এটিকে অস্বীকার করার পক্ষে যথেষ্ট বিশ্রী)

সেরা সমাধান নির্বাচন করা

এখন আমরা নিজেরাই জিজ্ঞাসা করি: যদি প্যারামিটারলেস কনস্ট্রাক্টর না থাকে তবে এটি কী দ্বারা প্রতিস্থাপন করা উচিত? এবং কোন ধরণের পরিস্থিতিতে আমরা ডিফল্ট পাবলিক প্যারামিটারলেস কনস্ট্রাক্টর সরিয়ে নিতে চাই?

জিনিসগুলি জায়গায় পড়তে শুরু করে। প্রথমত, এটি হয় পরামিতিগুলির সাথে কনস্ট্রাক্টর, বা একটি জন-পাবলিক কনস্ট্রাক্টরের সাথে প্রতিস্থাপন করতে হবে। দ্বিতীয়ত, আপনি যে পরিমাপের অধীনে প্যারামিটারলেস কনস্ট্রাক্টর চান না তা হ'ল:

1. আমরা ক্লাসটি একেবারেই ইনস্ট্যান্ট করা চাই না, বা আমরা নির্মাণকারীর দৃশ্যমানতা নিয়ন্ত্রণ করতে চাই: একটি জনসাধারণ নির্মাতা ঘোষণা করুন
2. আমরা প্যারামিটারগুলিকে নির্মাণের জন্য সরবরাহ করতে বাধ্য করতে চাই: পরামিতিগুলির সাথে একজন নির্মাতা ঘোষণা করুন

উপসংহার

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

Comments

পরিষ্কারভাবে কাঠামোগত এবং অনুসরণ করা সহজ, +1। তবে উপরে (৩) সম্পর্কিত: আমি মনে করি না যে নির্মাণকারীর অপসারণের জন্য একটি বিশেষ কীওয়ার্ডটি এমন একটি বিশ্রী ধারণা, এবং আসলে সি ++ 11 = deleteএই উদ্দেশ্যে প্রবর্তন করেছে।

— jogojapan

Answer 9

আমি মনে করি এটি সংকলক দ্বারা পরিচালিত হয়েছে। আপনি খুলতে পারেন .netসমাবেশ ILDASMআপনাকে ডিফল্ট কন্সট্রাকটর দেখতে হবে, যদিও তা কোডে নয়। আপনি যদি একটি প্যারামিটারাইজড কনস্ট্রাক্টর সংজ্ঞায়িত করেন তবে ডিফল্ট কনস্ট্রাক্টর দেখা যায় না।

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

Answer 10

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

Answer 11

একটি শ্রেণীর একজন কনস্ট্রাক্টর দরকার। এটি বাধ্যতামূলক প্রয়োজনীয়তা।

• আপনি যদি এটি তৈরি না করেন তবে প্যারামিটারলেস কনস্ট্রাক্টর আপনাকে স্বয়ংক্রিয়ভাবে দেওয়া হবে।
• আপনি যদি প্যারামিটারলেস কনস্ট্রাক্টর না চান তবে আপনার নিজের তৈরি করতে হবে।
• আপনার যদি উভয়ই প্রয়োজন হয় তবে প্যারামিটারলেস কনস্ট্রাক্টর এবং প্যারামিটার ভিত্তিক-কনস্ট্রাক্টর আপনি এগুলি ম্যানুয়ালি যুক্ত করতে পারেন।

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