জাভাতে যখনই প্রযোজ্য "চূড়ান্ত" সংশোধক ব্যবহার করুন [বন্ধ]

194

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

7 বছর আগে বন্ধ ছিল ।

জাভাতে, প্রতিটি ভেরিয়েবল (স্থানীয় বা শ্রেণি), প্যারামিটার চূড়ান্ত যদি তারা হয় তবে তা ঘোষণা করার অনুশীলন রয়েছে।

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

এ সম্পর্কে আপনার মতামত কী এবং আপনি কী অনুসরণ করেন?

java oop

— surajs
সূত্র

13

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

— পিটার লরে

আমি বুঝতে পারি যদি লোকেরা তাদের কোড ফাইনালের সাথে আঁকড়ে থাকতে পছন্দ করে না। তবে এটি এমন একটি সমস্যা যা একটি ভাল সম্পাদক সমাধান করতে পারে: bugs.eclipse.org/bugs/show_bug.cgi?id=409379

— ওবারলিস

সম্পর্কিত স্ট্যাকওভারফ্লো

— অ্যাড্রিয়েন

184

আমি মনে করি এটির সবগুলি ভাল কোডিং শৈলীর সাথে করা উচিত। অবশ্যই আপনি finalকোথাও প্রচুর সংশোধক ব্যবহার না করে ভাল, শক্তিশালী প্রোগ্রামগুলি লিখতে পারেন , তবে আপনি যখন এটি সম্পর্কে ভাবেন ...

যোগ করা হচ্ছে finalসব কিছু যা করা উচিত নয় কেবল পরিবর্তন সম্ভাবনার যে আপনি (বা পরবর্তী প্রোগ্রামার আপনার কোড নিয়ে কাজ) ভুল ব্যাখ্যা বা চিন্তার প্রক্রিয়া যাতে আপনার কোডটি ফলে অপব্যবহার হবে নিচে সরু। কমপক্ষে কিছু ঘণ্টা বাজানো উচিত যখন তারা এখন আপনার আগের অপরিবর্তনীয় জিনিসটি পরিবর্তন করতে চায়।

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

আমি মনে করি এটি ভাল অনুশীলন। আমি এটি সবসময় ব্যবহার করছি না, তবে যখন আমি এটি করতে পারি এবং এটির কিছু বুঝায় finalআমি তা করব।

— জোহান পেলগ্রিম
সূত্র

16

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

— টিমো ওয়েস্টক্যাম্পার

20

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

— মাইক

9

finalযখনই আপনি সংরক্ষণ করবেন তখন গ্রহগ্রহের কাছে যতটা সম্ভব (যে পরিবর্তনগুলি পরিবর্তন হয় না) যুক্ত করার বিকল্প রয়েছে ।

— বার্ট এফ

22

+1 আমি ভালবাসি final। সময়ের 98% এটি কোনও তাত্পর্যপূর্ণ করে না, এটি সময়ের 1% অসুবিধা, কিন্তু 1% সময়টি আমাকে বোকা বা অনিচ্ছাকৃত কিছু থেকে বাঁচায় এটি উপযুক্ত worth

— বার্ট এফ

14

@ বার্টএফ হ্যাঁ, আমি finalযখনই আমার কোড "ক্লিন আপ ..." রাখি তখন আমি সবসময়ই গ্রহপত্রে সর্বত্র Modifier যোগ করতে দিয়েছি। সর্বত্র অর্থ এমনকি ক্যাচ () ব্লকগুলিও রয়েছে এবং যেমনটি বলা হয়েছে, আপনি কিছুক্ষণ পরে তাদের লক্ষ্য করবেন না। অবশ্যই, যদি আমি একটি ভাষা তৈরি করি তবে finalএটি ডিফল্ট হবে এবং একটি varবা or modifiableচ্ছিক কীওয়ার্ড হবে।

— মার্টেন বোদেউয়েস

191

অবসান:

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

বিবেচনা করুন কিন্তু বিচার্যভাবে ব্যবহার করুন:

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

পায়খানা অনুভব না করা অবহেলা করুন:

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

— অ্যালেক্স মিলার
সূত্র

8

এই চূড়ান্ত বিষয়ে একাধিক প্রশ্নের মধ্যে এখনও সেরা উত্তর

— গ্যাব্রিয়েল ŠčerbŠčk

4

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

— nyxz

32

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

আমি আরও তথ্যের জন্য নীচের সাথে লিঙ্কিত নিবন্ধটি চেক করার পরামর্শ দেব।

চূড়ান্ত কীওয়ার্ডে ফাইনাল ওয়ার্ড

— HowardSP
সূত্র

29

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

final FileInputStream in;
if(test)
  in = new FileInputStream("foo.txt");
else
  System.out.println("test failed");
in.read(); // Compiler error because variable 'in' might be unassigned

কোনও ভেরিয়েবলকে একাধিকবার নিযুক্ত হওয়ার হাত থেকে বাঁচিয়ে আপনি ওভারড্রোড স্কোপিংকে নিরুৎসাহিত করেন। এর পরিবর্তে:

 String msg = null;
 for(int i = 0; i < 10; i++) {
     msg = "We are at position " + i;
     System.out.println(msg);
 }
 msg = null;

আপনি এটি ব্যবহার করতে উত্সাহিত:

 for(int i = 0; i < 10; i++) {
     final String msg = "We are at position " + i;
     System.out.println(msg);
 }

কিছু লিঙ্ক:

চূড়ান্ত গল্প ("হার্ড জাভা" বইয়ের বিনামূল্যে অধ্যায়)
কিছু চূড়ান্ত নিদর্শন
নির্দিষ্ট কাজ

— ব্রুনো ডি ফ্রেইন
সূত্র

1

— ওভারড্রোড

সংক্ষেপে বলতে গেলে আপনি মূলত আপনি ব্যবহার করতে পারেন করতে পারেন finalথেকে জাভা আরো ভিত্তিক অঙ্গভঙ্গি করো ।

— অ্যাডাম জেন্ট

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

— nyholku

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

— ব্রুনো ডি ফ্রেইন

20

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

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

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

— রায়ান রান্সফোর্ড
সূত্র

2

finalভেরিয়েবল এবং পদ্ধতির পরামিতিগুলির কার্য সম্পাদনে কোনও প্রভাব নেই কারণ এটি বাইকোডে প্রকাশ করা হয়নি।

— স্টিভ কুও

পরিবর্তনশীল: = ল্যাটিন: ভ্যারিয়াস> বিভিন্ন> সংশোধনযোগ্য

— ডাইটার

17

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

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

— লার্স ওয়েস্টারগ্রেন
সূত্র

15

সাবধান - চূড়ান্ত এবং অপরিবর্তনীয় সম্পূর্ণ ভিন্ন ধারণা। চূড়ান্ত পরিবর্তনযোগ্য অবজেক্ট থাকা সহজ - চূড়ান্তটি রেফারেন্স সম্পর্কে, পরিবর্তনের বিষয়টি বস্তুর উদাহরণটি সম্পর্কে। চূড়ান্ত ব্যক্তি olaf = নতুন ব্যক্তি (); olaf.setName ( "ওলাফ");

— ওলাফ কক

1

অবিকল - অপরিবর্তনীয় বস্তু হ'ল এক জিনিস, অপরিবর্তনীয় উল্লেখগুলি (অর্থাত্ চূড়ান্ত) সম্পূর্ণ অন্য কিছু।

— এসসিডিএফ

2

তবে তারা নিবিড়ভাবে সম্পর্কিত যেহেতু আপনি পার্সন.নাম ক্ষেত্রটিকে চূড়ান্ত হিসাবে ঘোষণা করে (এবং ক্লাস ফাইনাল ঘোষণা করে এবং ...) ব্যক্তির অবজেক্টটিকে চূড়ান্ত করে তুলতে পারেন। এটি কেবল "চূড়ান্ত ব্যক্তি" করার মতো সহজ নয় ...

— সেবাস্তিয়ান গ্যানসাল্ট 18

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

— রবিন

12

আমি কখনই এমন পরিস্থিতিতে পড়িনি যেখানে ভেরিয়েবলের একটি চূড়ান্ত কীওয়ার্ড থাকা আমাকে ভুল করতে বাধা দেয়, তাই এই মুহুর্তে আমি মনে করি এটি সময়ের অপব্যয়।

এটি না করার সত্যিকারের কারণ না থাকলে (আপনি যেমন পরিবর্তনশীল চূড়ান্ত হওয়ার বিষয়ে একটি নির্দিষ্ট পয়েন্ট তৈরি করতে চান) আমি কোডটি কম পাঠযোগ্য বলে মনে করি বরং এটি করব না।

তবে, আপনি যদি এটি খুঁজে না পান যে কোডটি পড়া আরও কঠিন বা আরও দীর্ঘায়িত করে তোলে তবে তা যেকোন উপায়েই এর জন্য যান।

সম্পাদনা: একটি স্পষ্টতা হিসাবে (এবং ডাউন-ভোটে জয়ের প্রচেষ্টা) হিসাবে, আমি বলছি না ধ্রুবকগুলিকে চূড়ান্ত হিসাবে চিহ্নিত করবেন না, আমি বলছি যে স্টাফ করবেন না:

public String doSomething() {
  final String first = someReallyComplicatedExpressionToGetTheString();
  final String second = anotherReallyComplicatedExpressionToGetAnother();

  return first+second;
}

এটি কেবল কোড (আমার মতে) পড়া আরও কঠিন করে তোলে।

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

— SCdF
সূত্র

1

বিবৃতিটিকে তার মাথায় ঘুরিয়ে দেওয়া: আমি প্রচুর পরিস্থিতিতে পড়েছি যেখানে ব্যাগগুলির সংখ্যা এবং প্রভাবের ক্ষেত্রে (এবং সাধারণভাবে অপরিবর্তনীয় বস্তু) ব্যবহার না করা finalএকটি গুরুত্বপূর্ণ অবদানকারী কারণ ছিল had

— ক্রিস ভেস্ট

3

আমি সব অপরিবর্তনীয় বস্তুর জন্য, আমি কেবল কখনও এমন পরিস্থিতিতে পড়িনি যেখানে অপরিবর্তনীয় বস্তুর ফাইনাল চিহ্নিত করা আমাকে সহায়তা করেছে has

— এসসিডিএফ

2

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

— rmaruszewski

@ ক্রিসভেস্ট, আপনার ফাংশনগুলি খুব দীর্ঘ হতে পারে

— পেসারিয়ার

8

চূড়ান্ত সর্বদা ধ্রুবকগুলির জন্য ব্যবহার করা উচিত। ভেরিয়েবল সংজ্ঞায়নের নিয়মগুলি জটিল হলে এটি স্বল্প-স্থায়ী ভেরিয়েবলগুলির জন্যও (একক পদ্ধতির মধ্যে) দরকারী।

উদাহরণ স্বরূপ:

final int foo;
if (a)
    foo = 1;
else if (b)
    foo = 2;
else if (c)
    foo = 3;
if (d)        // Compile error:  forgot the 'else'
    foo = 4;
else
    foo = -1;

— ডেভিড লেপপিক
সূত্র

6

চূড়ান্ত কীওয়ার্ডটি ব্যবহার করার বিরুদ্ধে সবচেয়ে বড় যুক্তির মতো মনে হচ্ছে এটি "এটি অপ্রয়োজনীয়" এবং এটি "স্থান অপচয় করে"।

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

— রশ্মি
সূত্র

1

ডাউনভোটার্স, বোঝানোর যত্ন?

— রে

একে ভেরিয়েবল বলতে আজব লাগছে, তাই না?

— অ্যালান

2

এখানে হাজার হাজার ইংরেজি শব্দ বেছে নেওয়া হয়েছে।

— RAY

এটি নিখুঁত। final"লেখার পক্ষে দীর্ঘ", "কোড ক্ল্যামিয়ার তৈরি করে" ব্যতীত কোনও যুক্তি নেই । জন্য বিভিন্ন যুক্তি আছে final। এবং যদি আপনি এটি নিজের হাতে টাইপ করতে না চান তবে আমরা এটি সংরক্ষণে স্বয়ংক্রিয়ভাবে যুক্ত করতে পারি।

— দিমিত্রি পোপভ

5

আমি finalঅবজেক্ট বৈশিষ্ট্যের জন্য সমস্ত সময় ব্যবহার করি ।

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

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

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

আমি অনুমান করি আমার বেশিরভাগ ক্লাসকে চূড়ান্ত করা উচিত, তবে আমি এখনও অভ্যাসে প্রবেশ করি নি।

— ক্রিস ভেস্ট
সূত্র

4

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

— টম হাটিন - ট্যাকলাইন
সূত্র

কেন এমন হাতিয়ার ব্যবহার করবেন না যা বিশৃঙ্খলা হ্রাস করে?

— পেসারিয়ার

@ পেসারিয়ার এমন একজন সম্পাদক হিসাবে যা কোডটির ভুল ব্যাখ্যা করে?

— টম হাটিন -

3

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

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

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

— DJClayworth
সূত্র

3

আরেকটি সতর্কতাই হ'ল অনেকে চূড়ান্ত বিভ্রান্তিকে বোঝায় যে উদাহরণটি পরিবর্তনশীলের বিষয়বস্তু পরিবর্তন করতে পারে না, তার পরিবর্তে উল্লেখটি পরিবর্তন করতে পারে না।

— উরি
সূত্র

এবং এই পোস্টটি এটির একটি বড় প্রমাণ।

— ইনজিগড

2

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

— Diastrophism
সূত্র

2

finalপ্রতিটি পদ্ধতিতে প্রতিটি প্যারামিটারের জন্য টাইপ করা বাছাই করা কোডার এবং কোড পাঠকদের উভয়ের জন্যই এত জ্বালা তৈরি করে।

জ্বালা একবার স্ক্যালায় যুক্তিসঙ্গত স্যুইচ ছাড়িয়ে যায় যেখানে ডিফল্টর সাথে যুক্তি চূড়ান্ত হয়।

অথবা, আপনি সর্বদা কোড স্টাইলিং সরঞ্জামগুলি ব্যবহার করতে পারেন যা আপনার জন্য স্বয়ংক্রিয়ভাবে তা করবে। সমস্ত আইডিই সেগুলি প্রয়োগ করেছে বা প্লাগইন হিসাবে।

— ওলেগ মিখিভ
সূত্র

1

চূড়ান্ত যখন জাভাতে ভেরিয়েবলের সাথে ব্যবহার করা হয় তখন সি ++ এ ধ্রুবকের বিকল্প সরবরাহ করে। সুতরাং যখন চূড়ান্ত এবং স্থির পরিবর্তনশীল জন্য ব্যবহৃত হয় তা পরিবর্তনযোগ্য হয়ে যায় becomes একই সাথে মাইগ্রেটেড সি ++ প্রোগ্রামারদের বেশ আনন্দিত করে তোলে ;-)

রেফারেন্স ভেরিয়েবলের সাথে ব্যবহার করার সময় এটি আপনাকে বস্তুকে পুনরায় রেফারেন্স করার অনুমতি দেয় না, যদিও বস্তুটি ম্যানিপুলেট করা যায়।

চূড়ান্ত যখন কোনও পদ্ধতির সাথে ব্যবহার করা হয়, তখন এটি উপশ্রেণী দ্বারা পদ্ধতিটিকে অতিরিক্ত-চালিত হতে দেয় না।

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

যখন আপনি নিশ্চিত হন যে ভেরিয়েবলের মান / কখনই পরিবর্তন করা উচিত নয় তখনই কেবল এটির পরিবর্তনশীলগুলির জন্য ব্যবহার করা উচিত। এছাড়াও আপনি সুনের দ্বারা উত্সাহিত কোডিং কনভেনশন অনুসরণ করেছেন তা নিশ্চিত করুন eg উদাহরণস্বরূপ: চূড়ান্ত INCOLOR_RED = 1; (আন্ডারস্কোর দ্বারা উচ্চতর কেস পৃথক করা)

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

পঠনযোগ্যতা অংশ সম্পর্কে, নিশ্চিত করুন যে চূড়ান্ত সংশোধক ব্যবহার করার সময় মন্তব্যগুলি খুব গুরুত্বপূর্ণ ভূমিকা পালন করে।

— সর্বশক্তিমত্তা
সূত্র

কেউ আমাকে বলতে পারেন কেন এই ভোট কেন নিচে ??? শুধু কৌতূহলী ..

— সর্বশক্তিমান

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

— আউটলা প্রোগ্রামার

1

এটি সি ++ কনট কীওয়ার্ডের কোনও বিকল্প নয় not -1।

— tmj

1

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

স্থির ক্ষেত্রে ব্যতীত তারা খুব কমই সদস্য ভেরিয়েবলগুলিতে প্রযোজ্য, কারণ তারা সামান্য সুবিধা দেয়।

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

তবে আরে, এটাই আমার মতামত :-)

— পক্ষীবিশেষ
সূত্র

1

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

অত্যন্ত বাঞ্ছনীয়.

পরীক্ষা করে দেখুন আমার ব্লগ পোস্ট পদক্ষেপ অন্ধকার সংরক্ষণ করুন।

— zvikico
সূত্র

1

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

চূড়ান্ত লালগ্রহণকে রঙিন করে দেওয়ার বিষয়টি কোডে ভেরিয়েবলের ঘোষণাকে স্পষ্ট করা সহজ করে তোলে যা আমি মনে করি বেশিরভাগ সময়ই পাঠকের দক্ষতা উন্নত করে।

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

আমি এখন একদিনে চূড়ান্তভাবে চূড়ান্ত নয় এমন চারিদিকে ঘাবড়ে যাচ্ছি। এটি আপনার মাথার উপরে সুতোর সাথে একটি ছুরি ঝুলানো বা কেবল আপনার রান্নাঘরের ড্রয়ারের মধ্যে পার্থক্যের মতো ...

একটি চূড়ান্ত পরিবর্তনশীল মানগুলি lable করার একটি দুর্দান্ত উপায়।

একটি চূড়ান্ত নয় এমন ভেরিয়েবল কিছু বাগ প্রবণ অ্যালগরিদমের অংশে আবদ্ধ।

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

— জন নিলসন
সূত্র

1

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

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

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

আমার যখন প্রয়োজন হয় তখন অবিবেচনাযোগ্য তালিকা তৈরি করতে আমি সংগ্রহও.আনমোডিফাইয়েবল ... ব্যবহার করি।

— রবি ওয়ালাউ
সূত্র

0

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

তবে, আপনি যদি নিজের কোডটিতে নিজেকে চূড়ান্ত বিবৃতি দেবেন বলে মনে করেন। এটি কোনও ভাল ইঙ্গিত হতে পারে আপনি কিছু ভুল করছেন।

উপরের পোস্ট নিবন্ধটি এই উদাহরণ দেয়:

public void doSomething(int i, int j) {
    final int n = i + j; // must be declared final

    Comparator comp = new Comparator() {
        public int compare(Object left, Object right) {
            return n; // return copy of a local variable
        }
    };
}

— হান্স সানজুনসন
সূত্র

0

আমি এটি ভিতরে এবং বাইরের পদ্ধতির ধ্রুবকগুলির জন্য ব্যবহার করি।

আমি কেবল কখনও কখনও এটি পদ্ধতির জন্য ব্যবহার করি কারণ আমি জানি না যে একটি উপশ্রেণী কোনও প্রদত্ত পদ্ধতি (যে কারণেই হোক না কেন) ওভাররাইড করতে চাইবে না।

ক্লাস হিসাবে, শুধুমাত্র কিছু পরিকাঠামো ক্লাসের জন্য, আমি চূড়ান্ত শ্রেণি ব্যবহার করেছি।

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

— anjanb
সূত্র

0

আমি পদ্ধতি বা ক্লাসে চূড়ান্তভাবে চূড়ান্ত ব্যবহার করি কারণ আমি লোকদের সেগুলি ওভাররাইড করার অনুমতি দিতে পছন্দ করি।

অন্যথায়, আমি কেবল অবশেষে ব্যবহার করি যদি এটি হয় public/private static final type SOME_CONSTANT;

— jjnguy
সূত্র

হুম..এক স্থানে সম্পাদিত..এখনও দ্বিতীয় লাইনে শেষ পর্যন্ত বলা হয়েছে ;-)

— সর্বশক্তিমান

লোকেদের মানগুলিকে ওভাররাইড করার অনুমতি দেওয়া হ'ল বিস্ময়ের একমাত্র বৃহত্তম উত্স এবং হার্ড-টু-ফিগার বাগগুলি

— RAY

0

ক্লাস ফাইনাল চিহ্নিত করে রানটাইমের পরিবর্তে সংকলন সময়ে কিছু পদ্ধতির বাইন্ডিংগুলি ঘটতে পারে। নীচে "v2.foo ()" বিবেচনা করুন - সংকলক জানে যে বি একটি সাবক্লাস থাকতে পারে না, সুতরাং foo () ওভাররাইড করা যায় না তাই কল করার বাস্তবায়নটি সংকলন সময়ে জানা যায়। যদি ক্লাস বি চূড়ান্ত হিসাবে চিহ্নিত না হয়, তবে এটি সম্ভব হয় যে প্রকৃত ধরণের ভি 2 এমন কিছু শ্রেণি যা বি প্রসারিত করে এবং ফু () কে ওভাররাইড করে।

class A {
    void foo() {
        //do something
    }
}
final class B extends A {
    void foo() {
    }
}
class Test {
    public void t(A v1, B v2) {
        v1.foo();
        v2.foo();
    }
}

— ইউজিন
সূত্র

-1

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

— পাওয়ে হাজদান
সূত্র

এটি টেস্টিংকে শক্ত করে না কারণ আপনার যেভাবেই ইন্টারফেস ব্যবহার করা উচিত।

— ক্রিস ভেস্ট