ইন্টারফেসে সুরক্ষিত

111

interfaceসংজ্ঞায়িত সমস্ত পদ্ধতি কেন অন্তর্নিহিত public? কেন এটি কোনও protectedপদ্ধতির অনুমতি দেয় না ?

java interface

22

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

— মার্কাস এ।

4

@MarkusA। তবে ইন্টারফেসগুলি দ্বিমুখীভাবে কাজ করে, যেমন সেগুলি বর্তমান প্যাকেজের বাইরের ক্লাসগুলির দ্বারা প্রয়োগ করা যেতে পারে (এবং তারপরে সম্ভবত এই প্যাকেজের অভ্যন্তরের পদ্ধতির পক্ষে যুক্তি হিসাবে পাস করা হবে)। বর্তমান প্যাকেজের বাইরের কোনও শ্রেণি কীভাবে কিছু পাবলিক ইন্টারফেসের "সুরক্ষিত" পদ্ধতিগুলি প্রয়োগ করতে সক্ষম হবে?

— মার্টিনস্টেটনার

8

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

— সুপারক্যাট

1

@MarkusA। আপনি একটি ভাল বিষয় উত্থাপন করেছেন, আপনি জাভা 9 এর মডিউল সিস্টেমের মাধ্যমে

— নীর আলফাসি

1

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

— অমরনাথ হরিশ

67

কারণ একটি ইন্টারফেসের অর্থ "শ্রেণীর বাইরে থেকে আপনি কী দেখতে পাচ্ছেন" বোঝার কথা। অ-জনসাধারণের পদ্ধতি যুক্ত করার অর্থ হবে না।

— Raveline
সূত্র

16

তবে কেন কেবল ইন্টারফেসের মতো একই প্যাকেজের সদস্যরা "শ্রেণীর বাইরে থেকে দেখতে পাবে" এমন ফাংশন নেই? আমার বেশ কয়েকটি ব্যবহারের মামলা হয়েছে যেখানে আমি এটির জন্য আগ্রহী ছিলাম।

— মার্কাস এ।

5

@MarkusA। আমি বুঝতে পেরেছি যে এটি দেরি হয়ে গেছে, তবে তারপরে আপনি একটি সম্পূর্ণরূপে তৈরি করতে পারবেন abstract classযা interfaceসবগুলিই রয়েছে এবং আপনি যেভাবে অ্যাক্সেস চান তা নির্দিষ্ট করে দিতে পারেন। অনুমোদিত যে interfaceএটি জাভাতে পাওয়া একাধিক বাস্তবায়নের সুবিধা হারিয়ে ফেলেছে , তবে সত্যই কোনও চুক্তি স্থাপন করা হয়েছে যা অন্য কোনও প্যাকেজের সীমাবদ্ধতা মেনে চলে না, কারণ আপনি ব্যবহারিকভাবে সেই প্যাকেজের বাইরে নিজের প্রয়োগের পদ্ধতি অ্যাক্সেস করতে সক্ষম হবেন না ।

— পিকপিজি

10

@ পিকপিজি তবে ইন্টারফেসটি কার্যকর করার জন্য ক্লাসটি যদি ইতিমধ্যে অন্য শ্রেণিকে প্রসারিত করে তবে আপনি এটিকে অন্য শ্রেণীর প্রসারিত করতে পারবেন না। আমি এটি কোনও ইন্টারফেসের জন্য বিভ্রান্তিকর খুঁজে পাই না যা কেবল প্যাকেজের অভ্যন্তরে ব্যবহৃত হয়।

— ফ্ল্যামমা

24

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

— পেসারিয়ার

8

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

— ফু বার

55

যদিও প্রায়শই উদ্ধৃত কারণ হ'ল "ইন্টারফেসগুলি পাবলিক এপিআইগুলি সংজ্ঞায়িত করে", আমি মনে করি এটি একটি অতি-সরলকরণ। (এবং এটি বিজ্ঞপ্তিযুক্ত যুক্তির "গন্ধ"))

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

প্রকৃতপক্ষে, আমি মনে করি যে কোনও ইন্টারফেসের সদস্যকে স্পষ্টতই জনসাধারণ করার পিছনে যুক্তির অংশটি জাভা ভাষাকে আরও সহজ করে তুলেছে :

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

"ইন্টারফেসগুলি পাবলিক এপিআইগুলি সংজ্ঞায়িত করে" এমন ভাবনার রেখাটি তাত্ক্ষণিকভাবে ভাষা নকশা সিদ্ধান্তের সরলকরণের একটি পরিণতি (বা বৈশিষ্ট্যযুক্ত) ... অন্যভাবে নয়। তবে বাস্তবে, জাভা ডিজাইনারদের মনে সমান্তরালে সম্ভবত দুটি विचारের বিকাশ ঘটেছে।

যে কোনও হারে, JDK-8179193 এর আরএফই - এর সরকারী প্রতিক্রিয়া এটিকে পরিষ্কার করে দেয় যে জাভা ডিজাইনের দলটি ^{2 টি} সিদ্ধান্ত নিয়েছিল যা protectedইন্টারফেসের মাধ্যমে অনুমতি দেওয়া সামান্য সত্যিকারের সুবিধার জন্য জটিলতা যুক্ত করে। সাক্ষ্য প্রমাণের জন্য কুডোস @ এসকোমিসায় ।

আরএফইতে থাকা প্রমাণগুলি বিষয়টি নিষ্পত্তি করে। এটি যুক্ত করা হয়নি বলেই সরকারী কারণ।

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

^{2 - আপনি তাদের সিদ্ধান্ত বা তাদের বর্ণিত যুক্তির সাথে একমত হতে পারেন তবে তা মূল কথা।}

— স্টিফেন সি
সূত্র

21

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

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

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

— মাইকেল ওবারলিন
সূত্র

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

— ফ্রি জেরেমি ক্রিগ

10

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

আপনি সুরক্ষিত বিমূর্ত পদ্ধতি সহ বিমূর্ত ক্লাস ব্যবহার করতে পারেন, তবে ইন্টারফেসগুলি সর্বজনীন পদ্ধতি এবং পাবলিক স্ট্যাটিক চূড়ান্ত ক্ষেত্রে সীমাবদ্ধ।

— শন প্যাট্রিক ফ্লয়েড
সূত্র

5

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

— পেসারিয়ার 19

1

জাভা 8 এর ডিফল্ট পদ্ধতিগুলির সাথে আর সত্য নয়।

— মারিও রসি

@ মারিওরোসি এবং জাভা 9 এর ব্যক্তিগত ইন্টারফেস পদ্ধতিগুলির সাথে আর সত্য নয়।

— স্কোমিসা

7

সম্ভবত, কারণ এটি একটি ইন্টারফেস , অর্থাত্ ক্লায়েন্টরা তারা উদাহরণস্বরূপ কী করতে পারে তা জানানোর চেয়ে তারা কী করতে পারে না তা জানান।

— ইঙ্গো
সূত্র

1

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

— ফ্রি জেরেমি ক্রিগ

6

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

— IntelliData
সূত্র

এটি প্রশ্নের উত্তর দেয় না।

— স্টিফেন সি

5

ইন্টারফেসের পদ্ধতিগুলি কেন সুরক্ষিত করা যায় না তা ব্যাখ্যা করার জন্য এখানে বেশ কয়েকটি উত্তর বিজ্ঞপ্তিযুক্ত যুক্তি ব্যবহার করে: কারণ এটি জনসাধারণের, তাই স্পষ্টতই তারা সুরক্ষিত হতে পারে না!

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

ইন্টারফেসে সুরক্ষিত পদ্ধতি: প্যাকেজগুলির মধ্যে ভাগ করুন

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

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

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

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

এবং এটি সেই বর্ধনের অনুরোধের প্রতিক্রিয়া, যা স্থিতি সহ বন্ধ ছিল Won't fix:

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

জাভা 9-তে শুরু হওয়া বিকল্পটি হ'ল ক্লাস এবং পদ্ধতিগুলি জনসাধারণ্য করে তোলা, তবে একটি মডিউলের মধ্যে যা সাধারণের কাছে রফতানি না করে নির্দিষ্ট "বন্ধু" মডিউলগুলিতে যোগ্য-রফতানি করে।

সুতরাং সেই বাগ রিপোর্টটি থেকে অনুমোদনের বিষয়টি হ'ল:

বর্তমান পরিস্থিতি বদলাচ্ছে না; ইন্টারফেসগুলি কখনও protectedপদ্ধতিগুলি সমর্থন করার সম্ভাবনা কম ।
সমর্থন না যৌক্তিকতা protectedইন্টারফেসগুলি পদ্ধতি এটি "হয় সামান্য প্রকৃত লাভ জন্য জটিলতা এবং বিশেষ ক্ষেত্রে যোগ করে "।
জাভা 9 এর পর থেকে পদ্ধতিগুলিতে প্যাকেজ স্তরের অ্যাক্সেস সরবরাহের জন্য বিকল্প পদ্ধতি রয়েছে। " ক্লাস এবং পদ্ধতিগুলি জনসাধারণ্যে তৈরি করতে জাভা প্ল্যাটফর্ম মডিউল সিস্টেম (জেপিএমএস) ব্যবহার করুন তবে সাধারণের কাছে রফতানি না করে নির্দিষ্ট" বন্ধু "মডিউলগুলিতে যোগ্য-রফতানি রয়েছে এমন একটি মডিউলে "।

— skomisa
সূত্র

4

যেহেতু একটি প্রয়োগকারী শ্রেণি অবশ্যই আপনার ইন্টারফেসে ঘোষিত সমস্ত পদ্ধতি প্রয়োগ করে, তাই আপনার বাস্তবায়নকারী শ্রেণি অন্য প্যাকেজের মধ্যে থাকলে কী হবে?

— dm76
সূত্র

2

ইন্টারফেস যদি আপনি বর্ণিত মতো কিছু ব্যবহার করতে চান তবে অ্যাবস্ট্রাক্ট ক্লাস বা নেস্টেড ইন্টারফেস দিয়ে যান।

ইন্টারফেস ভেরিয়েবল সম্পর্কে কোড স্টাইলের একটি অংশ , তবে এখনও পদ্ধতিগুলিতে প্রয়োগ করুন:

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

— ঘুসরবর্ণ
সূত্র

2

অভ্যন্তরীণ সাবিনটারফেসগুলি ঘোষণা করা একটি ভাল অনুশীলন, তবে আপনি নিজের অভ্যন্তরীণ পদ্ধতিগুলি হিসাবে এটি ঘোষণা করতে পারবেন না protected প্রযুক্তিগতভাবে জাভাতে একটি ইন্টারফেস ।

অবশ্যই, আপনি অভ্যন্তরীণ ব্যবহারের জন্য অন্য একটি ইন্টারফেস তৈরি করতে পারেন যা পাবলিক ইন্টারফেসকে প্রসারিত করে:

package yourpackage;

public interface PublicInterface {

    public void doThing1();

    public void doThing2();

    public void doThing3();

}

package yourpackage;

interface InternalInterface extends PublicInterface {

    void doAnyInternalThing1();

    void doAnyInternalThing2();

}

আপনি InternalInterfaceপ্যাকেজের ভিতরে ইন্টারফেসটি ব্যবহার করতে পারেন তবে আপনার কোনও উপ-টাইপ PublicInterface(জনসাধারণের পদ্ধতিতে) গ্রহণ করা উচিত :

package yourpackage;

public class SomeClass {

    public void someMethod(PublicInterface param) {
        if (param instanceof InternalInterface) {
            // run the optimized code
        } else {
            // run the general code
        }
    }

}

প্যাকেজের বাইরে ব্যবহারকারীরা PublicInterfaceসমস্যা ছাড়াই ব্যবহার করতে পারবেন ।

সাধারণত প্রোগ্রামাররা একই পরিস্থিতিতে বিমূর্ত ক্লাস তৈরি করে। তবে এক্ষেত্রে আমরা একাধিক উত্তরাধিকারের সুযোগগুলি হারাব lose

— ডেভিড হরভথ
সূত্র

1

প্যাকেজের বাইরেও ব্যবহারকারীরা ব্যবহার করতে পারেন YourPublicInterface.Internal। নেস্টেড ইন্টারফেস সহ একটি ইন্টারফেসের সমস্ত publicকিওয়ার্ডের উপস্থিতি বা অনুপস্থিতি নির্বিশেষে সর্বজনীন ।

— গ্রেগ Roelofs

1

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

এমনকি প্যাকেজের দৃশ্যপটটি আসলে ইন্টারফেসগুলি কী তা নয়।

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

— biziclop
সূত্র

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

— সুপারক্যাট

0

সুরক্ষিত পদ্ধতিগুলি কেবল সাব-ক্লাসের মাধ্যমে সর্বদা অ্যাক্সেসযোগ্য যদি কেবল সাবক্লাসটি বেস শ্রেণিকে প্রসারিত করে।

ইন্টারফেসের ক্ষেত্রে, সাবক্লাস কখনও ইন্টারফেস প্রসারিত করে না। এটি ইন্টারফেস প্রয়োগ করে।

সুরক্ষিত পদ্ধতিগুলি প্রসারিতের মাধ্যমে অ্যাক্সেসযোগ্য এবং বাস্তবায়নের মাধ্যমে নয় ।

— আফতাব সিদ্দিকী
সূত্র

কি ওয়ার্ড কি পার্থক্য, এটা কোন ব্যাপার না।

— অ্যালেক্স 78191

0

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

public interface MyInterface {
    public void publicMethod(); // needs to be public
}

public abstract class MyAbstractClass implements MyInterface {
    @Override
    public void publicMethod() {
        protectedMethod(); // you can call protected method here
        // do other stuff
    }
    protected abstract void protectedMethod(); // can be protected
}

public class MyClass extends MyAbstractClass {
    @Override
    protected void protectedMethod() {
        // implement protected method here, without exposing it as public
    }
}

— স্টেফানোস কার্গাস
সূত্র

2

তবে যে ব্যক্তিগত পদ্ধতিগুলি কেউ দেখবে না সেগুলি ইন্টারফেসগুলিতে অনুমোদিত।

— অ্যালেক্স 78191

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

— অ্যালেক্স 78191

তুমি ঠিক. জাভা 9 হিসাবে ব্যক্তিগত পদ্ধতি ইন্টারফেসে অনুমোদিত। এগুলি বিমূর্ত হতে পারে না এবং এগুলি ইন্টারফেসের মধ্যে প্রয়োগ করা হয় এবং ব্যবহৃত হয়, প্রধানত অন্যান্য ডিফল্ট বা স্থির পদ্ধতি দ্বারা (যদি তারা নিজেরাই স্থির থাকে)।

— স্টেফানোস কার্গাস

1

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

— স্কোমিসা