জাভা 8 ইন্টারফেস পদ্ধতিতে কেন "চূড়ান্ত" অনুমোদিত নয়?

Question

জাভা 8 এর অন্যতম দরকারী বৈশিষ্ট্য হ'ল defaultইন্টারফেসে নতুন পদ্ধতি। কেন তাদের পরিচয় করানো হয়েছে তার মূলত দুটি কারণ রয়েছে (অন্যরা থাকতে পারে):

• প্রকৃত ডিফল্ট বাস্তবায়ন সরবরাহ করা। উদাহরণ:Iterator.remove()
• জেডিকে এপিআই বিবর্তনের অনুমতি দেওয়া হচ্ছে। উদাহরণ:Iterable.forEach()

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

interface Sender {

    // Convenience method to send an empty message
    default final void send() {
        send(null);
    }

    // Implementations should only implement this method
    void send(String message);
}

উপরোক্ত ইতিমধ্যে সাধারণ অনুশীলন যদি Senderকোনও শ্রেণি হত:

abstract class Sender {

    // Convenience method to send an empty message
    final void send() {
        send(null);
    }

    // Implementations should only implement this method
    abstract void send(String message);
}

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

কিছু সময়, ব্রায়ান গয়েটসের উদ্ধৃতি দিয়ে , ইন্টারফেস পদ্ধতিগুলির মতো staticএবং পরিবর্তিত সংশোধনকারীদের পক্ষে সমর্থন finalএখনও পুরোপুরি অনুসন্ধান করা হয়নি :

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

২০১১ সালের শেষের দিকে, স্পষ্টতই, staticইন্টারফেসগুলিতে পদ্ধতিগুলির জন্য সমর্থন যুক্ত করা হয়েছিল। স্পষ্টতই, এটি জেডিকে গ্রন্থাগারগুলিতে নিজের মতো প্রচুর মান যুক্ত করেছে Comparator.comparing()।

প্রশ্ন:

কারণটি কী final(এবং এছাড়াও static final) জাভা 8 ইন্টারফেসে কখনও তৈরি করেনি?

Comments

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

— লার্নের মারকুইস

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

— ভিন্স এমি

@ ইজেপি: "আমি যদি তা করতে পারি তবে আপনিও করতে পারেন এবং আপনার নিজের প্রশ্নের উত্তর দিতে পারেন, যার জন্য জিজ্ঞাসা করার দরকার পড়েনি " " এই ঠিক এই ফোরামে সব প্রশ্নের জন্য প্রযোজ্য হবে, ডান? আমি সর্বদা গুগলকে নিজের কাছে 5 ঘন্টা কোনও বিষয় রাখতে পারি এবং তারপরে এমন কিছু শিখতে পারি যা প্রত্যেকেরই সমানভাবে হার্ড উপায় শিখতে হয়। অথবা আমরা আরও কয়েক মিনিটের জন্য অপেক্ষা করি যার থেকে আরও ভাল উত্তর দেওয়া যে ভবিষ্যতে প্রত্যেকে (এখন পর্যন্ত 12 টি উপস্থাপনা এবং 8 টি তারকা সহ) উপকৃত হতে পারে, কারণ গুগলে এসও এত ভালভাবে উল্লেখ করা হয়েছে। তাই হ্যাঁ. এই প্রশ্নটি SO এর প্রশ্নোত্তর ফর্মের সাথে পুরোপুরি ফিট করতে পারে।

— লুকাশ এডার

@ ভিনসেমিগ " ... আপনি কীভাবে ইন্টারফেসগুলি থেকে উত্তরাধিকার সূত্রে প্রাপ্ত পদ্ধতিগুলিকে ওভাররাইড করতে হবে তা দেখে ... " জাভা ৮-তে এটি সত্য নয় Java জাভা 8 আপনাকে ইন্টারফেসে পদ্ধতিগুলি প্রয়োগ করতে দেয়, যার অর্থ আপনার বাস্তবায়নের ক্ষেত্রে এগুলি প্রয়োগ করতে হবে না means ক্লাস। এখানে, finalপ্রয়োগকারী ক্লাসগুলিকে একটি ইন্টারফেস পদ্ধতির ডিফল্ট বাস্তবায়নকে ওভাররাইড করা থেকে বিরত রাখার একটি ব্যবহার রয়েছে।

— awsp

@ ইজেপি আপনি জানেন না: ব্রায়ান গোয়েজ উত্তর দিতে পারে !

— Assylias

Answer 1

এই প্রশ্নটি কিছুটা হলেও জাভা 8 ইন্টারফেস পদ্ধতিতে "সিঙ্ক্রোনাইজড" না হওয়ার কারণ কী?

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

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

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

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

interface A { 
    default void foo() { ... }
}

interface B { 
}

class C implements A, B { 
}

এখানে, সবকিছু ভাল; থেকে Cউত্তরাধিকারী । এখন মনে করুন একটি ডিফল্ট সহ একটি পদ্ধতিতে পরিবর্তন করা হয়েছে :foo()ABfoo

interface B { 
    default void foo() { ... }
}

এখন, যখন আমরা পুনরায় Cসংকলন করতে যাই, সংকলকটি আমাদের বলবে যে উত্তরাধিকার সূত্রে কী আচরণ করা উচিত তা তা জানে না foo(), সুতরাং Cএটির ওভাররাইড করতে হবে (এবং A.super.foo()যদি একই আচরণটি ধরে রাখতে চায় তবে তার প্রতিনিধি নির্বাচন করতে পারে could ) তবে কী যদি Bএটির ডিফল্ট তৈরি হয়েছে final, এবং Aএর লেখকের নিয়ন্ত্রণে নেই C? এখন Cঅপ্রয়োজনীয়ভাবে ভেঙে গেছে; এটি ওভাররাইড ছাড়া সংকলন করতে পারে না foo(), তবে এটি foo()চূড়ান্ত হলে এটি ওভাররাইড করতে পারে নাB ।

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

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

Comments

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

— কর্তিত

@ শর্ন স্টুয়ার্ট মার্কস জাভা -8 ট্যাগটিতে সক্রিয় রয়েছে। জেরেমি ম্যানসন অতীতে পোস্ট করেছেন। আমি জোশুয়া ব্লচের বার্তাগুলি দেখতে পেয়েছি তবে এখনই সেগুলি খুঁজে পাচ্ছি না।

— Assylias

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

— মাইক নাকিস

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

— মাইক নাকিস

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

— ব্রায়ান গোয়েটস

Answer 2

ল্যামডা মেইলিং তালিকায় এটি সম্পর্কে আলোচনা প্রচুর আছে । এই সমস্ত স্টাফ সম্পর্কে প্রচুর আলোচনা রয়েছে বলে মনে হয় তাদের মধ্যে একটি হ'ল: বৈচিত্রপূর্ণ ইন্টারফেসের পদ্ধতিতে দৃশ্যমানতা (ফাইনাল ডিফেন্ডার ছিল) ।

এই আলোচনায়, মূল প্রশ্নের লেখক ট্যালডেন আপনার প্রশ্নের সাথে খুব অনুরূপ কিছু জিজ্ঞাসা করেছেন:

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

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

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

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

এটি এমনকি কোনও সম্ভাব্য ইন-স্কোপ আলোচনা হতে পারে কিনা সে সম্পর্কে কোনও স্পষ্ট যোগাযোগ রয়েছে? যদি তা না হয় তবে এটি অন্য কোথাও অনুষ্ঠিত উচিত।

অবশেষে ব্রায়ান গয়েটসের উত্তর ছিল:

হ্যাঁ, এটি ইতিমধ্যে অন্বেষণ করা হচ্ছে।

যাইহোক, আমাকে কিছু বাস্তব প্রত্যাশা সেট করতে দিন - ভাষা / ভিএম বৈশিষ্ট্যগুলির একটি দীর্ঘ নেতৃত্বের সময় থাকে, এমনকি এর মতো তুচ্ছ-মনে হয়। জাভা এসই 8 এর জন্য নতুন ভাষার বৈশিষ্ট্য আইডিয়াগুলির প্রস্তাব দেওয়ার সময়টি বেশ অনেকটা পেরিয়ে গেছে।

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

অন্য উত্তপ্ত আলোচনায় চূড়ান্ত ডিফেন্ডার পদ্ধতিগুলির বিষয়ে, ব্রায়ান আবার বলেন :

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

সুতরাং এটি আমার তত্ত্বকে আরও শক্তিশালী করে যে এটি কেবল তাদের নকশার সুযোগ বা অংশের অংশ ছিল না। তারা যা করেছিল তা হ'ল এপিআই বিবর্তনের সমস্যাগুলি মোকাবেলায় পর্যাপ্ত কার্যকারিতা সরবরাহ করা।

Comments

আমি দেখতে পাচ্ছি যে আজ সকালে আমার গুগলিং ওডিসিতে আমার পুরানো নাম "ডিফেন্ডার পদ্ধতি" অন্তর্ভুক্ত করা উচিত ছিল। এটি খননের জন্য +1

— মার্কো 13

Historicতিহাসিক তথ্য খনন করে ভাল লাগছে। আপনার সিদ্ধান্তগুলি সরকারী উত্তরের

— লুকাশ এডার

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

— মিমি

Answer 3

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

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

এবং তুচ্ছ তথ্য যেমন একটি পদ্ধতি সহজভাবে একটি (সত্য) চূড়ান্ত পদ্ধতি হিসাবে বিবেচনা করা হয় না যখন defaultবর্তমানে পদ্ধতি হিসাবে প্রয়োগ করা হয় :: is_final_method পদ্ধতিতে ।

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

Comments

আকর্ষণীয় অন্তর্দৃষ্টি জন্য ধন্যবাদ। জন রোজের টুকরোটি একটি আকর্ষণীয় ট্রেস। যদিও আমি এখনও @EJP এর সাথে একমত নই। একটি পাল্টা উদাহরণ হিসাবে, একটি আমার উত্তর খুঁজে বার করো পিটার Lawrey দ্বারা খুব আকর্ষণীয়, একেবারে অনুরূপ শৈলী প্রশ্ন । এটা তোলে হয় ঐতিহাসিক ঘটনা খনন করা সম্ভব, এবং আমি সবসময় এখানে স্ট্যাক ওভারফ্লো সেগুলিকে খুঁজে পেতে খুশি (যেখানে অন্য?)। অবশ্যই, আপনার উত্তরটি এখনও অনুমানমূলক, এবং আমি 100% বিশ্বাস করি না যে জেভিএম বাস্তবায়ন বিবরণগুলি জেএলএসকে এক বা অন্য উপায়ে লিখিত হওয়ার চূড়ান্ত কারণ (পাং উদ্দেশ্যে) হবে ...

— লুকাশ এদার

@LukasEder নিশ্চিত, প্রশ্ন এই ধরনের হয় আকর্ষণীয় এবং Q & A- প্যাটার্ন মধ্যে এই প্রোগ্রামটিতে ফিট। আমি মনে করি যে এখানে দুটি জটিল পয়েন্ট রয়েছে যা এখানে বিতর্ক সৃষ্টি করেছিল: প্রথমটি হল আপনি "কারণ" চেয়েছিলেন। এটি অনেক ক্ষেত্রে কেবল সরকারীভাবে নথিভুক্ত করা যায় না। যেমন কোন "যুক্তি" JLS উল্লেখ কেন স্বাক্ষরবিহীন এখানে সেখানে intএস, দেখার মত এখনও stackoverflow.com/questions/430346 ... ...

— Marco13

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

— মার্কো 13

আমি এখনও আমার মামলা বিশ্রাম। দেখুন আমার উত্তরে হচ্ছে অন্য প্রশ্ন :-) এটা এখন চিরতরে স্পষ্ট একটি প্রামাণিক উত্তর সঙ্গে, এখানে স্ট্যাক ওভারফ্লো হবে কেন এটা সমর্থন না করার সিদ্ধান্ত হয় synchronizedউপর defaultপদ্ধতি।

— লুকাস এদার

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

— মার্কো 13

Answer 4

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

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

যে কেউ Collectionইন্টারফেসের সাথে মেনে চলে এমন একটি লিখতে পারে এবং তারপরে পদ্ধতিগুলির মধ্যে এমন জিনিসগুলি করে যা একেবারে স্বজ্ঞাত পাল্টা হয়, বিস্তৃত ইউনিট পরীক্ষাগুলি লেখার ব্যতীত নিজেকে এ থেকে নিজেকে রক্ষা করার উপায় নেই।

Comments

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

— লুকাশ এডার

Answer 5

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

1. একটি default finalপদ্ধতি যুক্ত করুন।
2. একটি staticপদ্ধতি যুক্ত করুন।

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