সি # ডিফল্টরূপে অ-ভার্চুয়াল হিসাবে পদ্ধতিগুলি কেন প্রয়োগ করে?


105

জাভা থেকে ভিন্ন, সি # কেন পদ্ধতিগুলি ডিফল্টরূপে অ-ভার্চুয়াল ফাংশন হিসাবে বিবেচনা করে? এটি অন্যান্য সম্ভাব্য ফলাফলের চেয়ে পারফরম্যান্সের সমস্যা হওয়ার সম্ভাবনা কি বেশি?

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


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

সত্য! কল আইএল নির্দেশনা বেশিরভাগ স্থির পদ্ধতিতে করা কলগুলির জন্য।
আরবিটি

1
সি # এর স্থপতি আন্ডার হেজলসবার্গের চিন্তাভাবনা এখানে এবং এখানে
আরবিটি

উত্তর:


98

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

virtualপদ্ধতিগুলির মধ্যে কিছুটা পারফরম্যান্সও থাকতে পারে। তবে এটি প্রাথমিক কারণ হওয়ার সম্ভাবনা নেই।


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

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

71
সিল করা ক্লাসগুলি আমাকে বাচ্চাদের খোঁচা দিতে চায়।
এমএক্সমিসাইল

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

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

89

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

যুক্তিটির যুক্তি "যদি আমরা আপনাকে শক্তি দিয়ে থাকি তবে আপনি নিজের ক্ষতি করতে পারেন" এর মতো বেশিরভাগ সমর্থনযোগ্যতা আমার কাছে পড়ে। প্রোগ্রামারদের কাছ থেকে ?!

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

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

অ-ভার্চুয়াল-বাই-ডিফল্ট আমার জীবনকে আরও শক্ত করে তোলে।

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

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

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

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

এখন আমি অনুমান করি যে তারা ঠিক সেই কারণেই সিদ্ধান্ত নিয়েছিল যে আমরা কখনই করব না .... ওহ, অপেক্ষা করুন! কথোপকথনের প্রতিলিপি!

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

(তবে তারা কি কেবল ভার্চুয়াল-বাই-ডিফল্ট বাছাই করতে পারে নি এবং তারপর কোডবেসের মাধ্যমে "চূড়ান্ত" পেপার্ড করতে পেরেছিল? সম্ভবত এটি বেশ একই রকম নয় .. এবং অ্যান্ডার্স আমার চেয়ে স্পষ্টতই চৌকস তাই আমি এটিকে মিথ্যা কথা বলতে যাচ্ছি।)


2
এর থেকে বেশি একমত হতে পারতাম না. তৃতীয় পক্ষের এপিআই গ্রহণ করার সময় এবং কিছু আচরণকে ওভাররাইড করতে এবং সক্ষম না হওয়ায় খুব হতাশাগ্রস্থ।
অ্যান্ডি

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

2
এখন যদি ভিজ্যুয়াল স্টুডিওতে কেবলমাত্র সম্পাদকীয় বৈশিষ্ট্যটি ছিল যে সমস্ত পদ্ধতি / বৈশিষ্ট্যগুলিকে স্বয়ংক্রিয়ভাবে ট্যাগ করার জন্য virtual... ভিজ্যুয়াল স্টুডিওর অ্যাড-ইন কারও?
কেভিনার্পে

1
আমি যখন আন্তরিকভাবে আপনার সাথে একমত হয়েছি, এটি ঠিক কোনও উত্তর নয়।
ক্রিস মরগান

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

17

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


12

অন্যেরা যা বলেছিল তার সংক্ষিপ্তসার জন্য কয়েকটি কারণ রয়েছে:

1- সি # তে সিনট্যাক্স এবং শব্দার্থবিজ্ঞানের অনেকগুলি বিষয় রয়েছে যা সরাসরি সি ++ থেকে আসে। সি ++ এ ডিফল্টরূপে ভার্চুয়াল নয় এমন পদ্ধতিগুলি সি # তে প্রভাবিত করে।

2- ডিফল্টরূপে প্রতিটি পদ্ধতি ভার্চুয়াল থাকা একটি পারফরম্যান্স উদ্বেগ কারণ প্রতিটি পদ্ধতি কলটিতে অবশ্যই অবজেক্টের ভার্চুয়াল সারণী ব্যবহার করা উচিত। তদ্ব্যতীত, এটি জাস্ট-ইন-টাইম সংকলকটির পদ্ধতিগুলিকে ইনলাইন করতে এবং অন্যান্য ধরণের অপ্টিমাইজেশান সম্পাদনের ক্ষমতা দৃ strongly়ভাবে সীমাবদ্ধ করে।

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

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


1
আমি ডিফল্টরূপেও সিল করা ক্লাস পছন্দ করতাম। তাহলে এটি ধারাবাহিক হবে।
অ্যান্ডি

9

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

পারফরম্যান্স ইস্যুতে "হ্যাঁ" বা "না" বলতে এত সহজ নয়। এর কারণ হ'ল জাস্ট ইন টাইম (জেআইটি) সংকলন যা সি # তে রান টাইম অপ্টিমাইজেশন।

" ভার্চুয়াল কলগুলির গতি .. " সম্পর্কে অন্য একটি অনুরূপ প্রশ্ন


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

1
আসলে, আমি মনে করি এটি সি ++ এর চেয়ে জাভা দ্বারা বেশি প্রভাবিত যা এটি ডিফল্টরূপে করে।
মেহরদাদ আফশারি

5

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

একটি অ-ভার্চুয়াল পদ্ধতিতে আপনার সম্পূর্ণ নিয়ন্ত্রণ রয়েছে। যে কোনও কিছু ভুল হয়ে যায় সেটাই মূল লেখকের দোষ। কোডটি সম্পর্কে तर्क করা অনেক সহজ।


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

2

সমস্ত সি # পদ্ধতি যদি ভার্চুয়াল হয় তবে ভিটিবিএল অনেক বড় হবে।

C # অবজেক্টের কেবল ভার্চুয়াল পদ্ধতি রয়েছে যদি শ্রেণিতে ভার্চুয়াল পদ্ধতিগুলি সংজ্ঞায়িত করা হয়। এটি সত্য যে সমস্ত বস্তুর কাছে এমন তথ্য রয়েছে যা একটি ভিটিবিএল সমতুল্য অন্তর্ভুক্ত করে, তবে যদি কোনও ভার্চুয়াল পদ্ধতিগুলি সংজ্ঞায়িত না হয় তবে কেবলমাত্র বেস অবজেক্টের পদ্ধতি উপস্থিত থাকবে।

@ টম হাটিন: সম্ভবত এটি বলা আরও সঠিক যে সি ++, সি # এবং জাভা সবগুলি ভাষার সি পরিবার থেকে এসেছে :)


1
ভিটিবেলটি আরও বড় হওয়ার জন্য কেন সমস্যা হবে? প্রতি ক্লাসে কেবল 1 টি vtable রয়েছে (এবং উদাহরণ অনুসারে নয়), সুতরাং এর আকারটি পুরোপুরি আলাদা করে না।
মাধ্যাকর্ষণ

1

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

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

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


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

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

আমি আপনার বক্তব্যটি বুঝতে পেরেছি বলে মনে করি, তবে সরবরাহ করা কংক্রিটের উদাহরণে: 'ব্যাকডলিস্ট' কেবল 'আইলিস্ট' ইন্টারফেসটি বাস্তবায়িত করতে পারে এবং ক্লায়েন্ট কেবল ইন্টারফেস সম্পর্কে জানেন। ঠিক আছে? আমি কিছু অনুপস্থিত করছি? তবে আপনি যে বিস্তৃত বিন্দুটি তৈরি করার চেষ্টা করছেন তা আমি বুঝতে পারি।
ভেট্রাস

0

এটি অবশ্যই কোনও পারফরম্যান্সের বিষয় নয়। সূর্যের জাভা দোভাষী তার প্রেরণের জন্য একই কোড ব্যবহার করেন ( invokevirtualবাইটকোড) এবং হটস্পট ঠিক একই কোড উত্পন্ন করে কিনা finalতা নির্ধারণ করে। আমি বিশ্বাস করি যে সমস্ত সি # অবজেক্টের (তবে স্ট্রাক্ট নয়) ভার্চুয়াল পদ্ধতি রয়েছে, সুতরাং আপনার সর্বদা প্রয়োজন হবেvtbl / রানটাইম শ্রেণীর সনাক্তকরণ প্রয়োজন। সি # হ'ল "জাভা-জাতীয় ভাষাগুলির" একটি উপভাষা। এটি সি ++ থেকে আসে তা বোঝাতে সম্পূর্ণ সৎ নয়।

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


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

@YairHalberstadt হটস্পট বিভিন্ন কারণে বিভিন্ন কারণে সংকলিত কোড ব্যাক আউট করতে সক্ষম হতে হবে। বহু বছর ধরে আমি উত্সটি দেখেছি তবে finalকার্যকর finalপদ্ধতিগুলির মধ্যে পার্থক্যটি নগণ্য। এটি লক্ষ্য করার মতো বিষয় যে এটি দ্বি-বিভক্ত ইনলাইনিং করতে পারে, এটি দুটি পৃথক বাস্তবায়ন সহ ইনলাইন পদ্ধতি।
টম হাটিন - ২:16
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.