ম্যাপ.জেট (অবজেক্ট কী) জেনেরিক না হওয়ার কারণ কী

Question

এর ইন্টারফেসে পুরোপুরি জেনেরিক পদ্ধতি না পাওয়ার সিদ্ধান্তের পিছনে কী কারণ রয়েছে java.util.Map<K, V>?

প্রশ্নটি পরিষ্কার করতে, পদ্ধতির স্বাক্ষরটি

V get(Object key)

পরিবর্তে

V get(K key)

এবং আমি ভাবছি কেন (একই জিনিস remove, containsKey, containsValue)।

Comments

: সংগ্রহ সংক্রান্ত একই প্রশ্ন stackoverflow.com/questions/104799/...

— AlikElzin-kilaka

জাভা সংগ্রহগুলি কেন জেনেরিক পদ্ধতিগুলি মুছে ফেলছে না

— ওলে ভিভি

অ্যামেজিং। আমি 20+ বছর ধরে জাভা ব্যবহার করছি এবং আজ আমি এই সমস্যাটি বুঝতে পারি।

— ঘোস্টট্যাগ

Answer 1

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

যদিও এটি সাধারণত সত্য হতে পারে যে অনেকগুলি ক্লাস equals()সংজ্ঞায়িত করেছে যাতে এটির বস্তুগুলি কেবল তার নিজস্ব বর্গের বস্তুর সমান হতে পারে, জাভাতে এমন অনেক জায়গা রয়েছে যেখানে এটি ঘটেনি। উদাহরণস্বরূপ, এর স্পেসিফিকেশনটি List.equals()বলে যে দুটি তালিকা অবজেক্ট সমান যদি তারা উভয় তালিকান থাকে এবং একই বিষয়বস্তু থাকে তবে সেগুলি বিভিন্ন বাস্তবায়ন হলেও List। সুতরাং এই প্রশ্নের উদাহরণটিতে ফিরে আসা, পদ্ধতির স্পেসিফিকেশন অনুসারে Map<ArrayList, Something>আমার কাছে ফোন করা এবং পাওয়া সম্ভবget()LinkedList যুক্তি হিসাবে করা এবং এটি একই বিষয়বস্তু সহ একটি তালিকা থাকা কীটি পুনরুদ্ধার করা উচিত। get()জেনেরিক এবং এর যুক্তির ধরণটি সীমাবদ্ধ রাখলে এটি সম্ভব হবে না ।

Comments

তাহলে V Get(K k)সি # তে কেন ?

প্রশ্নটি হল, আপনি যদি কল করতে চান তবে m.get(linkedList)কেন আপনি mএর ধরণের সংজ্ঞা দেননি Map<List,Something>? আমি এমন কোনও ইউজকেসের কথা ভাবতে পারি না যেখানে ইন্টারফেস পাওয়ার m.get(HappensToBeEqual)জন্য Mapটাইপ পরিবর্তন না করে কল করা অর্থপূর্ণ হয় ।

— এলাজার লাইবোভিচ

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

— MMM

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

— স্যাম গোল্ডবার্গ

@ নতুনাক্যাক্ট: "নিখুঁতভাবে নিরাপদ টাইপ করুন" এমন একটি নির্মাণের একটি দৃ claim় দাবি যা রানটাইমটিতে অনাকাঙ্ক্ষিতভাবে ব্যর্থ হতে পারে। আপনার দৃষ্টিভঙ্গি হ্যাশ ম্যাপগুলিতে সংকুচিত করবেন না যা এর সাথে কাজ করে। TreeMapআপনি যদি ভুল ধরণের অবজেক্টগুলিকে getপদ্ধতিতে পাস করেন তবে ব্যর্থ হতে পারে তবে মাঝেমধ্যে পাস হতে পারে, যেমন যখন মানচিত্রটি খালি থাকে। এমনকি খারাপ, একটি ক্ষেত্রে সরবরাহকৃত পদ্ধতি (যা একটি জেনেরিক স্বাক্ষর আছে!) কোন অবারিত সতর্কবাণী ছাড়াই ভুল ধরনের আর্গ্যুমেন্টগুলির সাথে ডাকা হতে পারে। এই হল ভাঙা আচরণ। Comparatorcompare

— 20:44

Answer 2

গুগলের এক বিস্ময়কর জাভা কোডার, কেভিন বোউরিলিয়ান কিছুক্ষণ আগে একটি ব্লগ পোস্টে ঠিক এই বিষয়টি সম্পর্কে লিখেছিলেন (স্বীকার করেছেন Setপরিবর্তে এর প্রসঙ্গে Map)। সর্বাধিক প্রাসঙ্গিক বাক্য:

অভিন্নভাবে, জাভা সংগ্রহ ফ্রেমওয়ার্কের পদ্ধতিগুলি (এবং গুগল সংগ্রহ সংগ্রহশালাও) কখনই তাদের প্যারামিটারগুলির প্রকারগুলি সীমাবদ্ধ করে না যখন সংগ্রহটি ভাঙ্গা থেকে রোধ করার জন্য প্রয়োজনীয় হয় except

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

Comments

অ্যাপোক্যালিস্প: এটি সত্য নয়, পরিস্থিতি এখনও একইরকম।

— কেভিন বোউরিলিয়ন

@ user102008 না, পোস্টটি ভুল নয়। যদিও একটি Integerএবং একটি Doubleকখনই একে অপরের সমতুল্য হতে পারে না, এটির একটি Set<? extends Number>মান রয়েছে কিনা তা জিজ্ঞাসা করা এখনও একটি যথাযথ প্রশ্ন new Integer(5)।

— কেভিন বোউরিলিয়ন

আমি একবারও এ-তে সদস্যতা চেক করতে চাইনি Set<? extends Foo>। আমি খুব ঘন ঘন একটি মানচিত্রের মূল ধরণের পরিবর্তন করেছি এবং তারপরে হতাশ হয়েছি যে সংকলকটি কোডটি আপডেট করার প্রয়োজনীয় সমস্ত জায়গাগুলি খুঁজে পেল না। আমি সত্যই নিশ্চিত নই যে এটিই সঠিক বাণিজ্য off

— পোরকুলাস

@ আর্থ আর্থাইন: এটি সর্বদা ভেঙে গেছে। এটি পুরো পয়েন্ট - কোডটি নষ্ট হয়ে গেছে, তবে সংকলক এটি ধরতে পারে না।

— জন স্কিটি

এবং এটি এখনও ভাঙা, এবং কেবল আমাদের একটি বাগ তৈরি করেছে ... দুর্দান্ত উত্তর।

— ঘোস্টটাগি 9:58

Answer 3

চুক্তিটি এভাবে প্রকাশ করা হয়:

আরও আনুষ্ঠানিকভাবে, যদি এই মানচিত্রে একটি কী কে থেকে কোনও মান v এর (মান == নাল? কে == নাল: কী.ইক্যুয়ালস (কে) ) ম্যাপিং থাকে তবে এই পদ্ধতিটি v ফেরায় ; অন্যথায় এটি শূন্য ফিরে। (সর্বাধিক এমন একটি ম্যাপিং থাকতে পারে))

(আমার জোর)

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

Comments

এটিও নির্ভর করে hashCode()। হ্যাশকোড () এর যথাযথ প্রয়োগ না করে এক্ষেত্রে খুব সুন্দরভাবে প্রয়োগ equals()করা ব্যর্থ।

— রুডলফসন

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

— বিল মিশেল

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

— রব

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

— BeeOnRope

Answer 4

এটি পোষ্টেলের আইনের প্রয়োগ , "আপনি যা করেন তাতে রক্ষণশীল হন, আপনি অন্যের কাছ থেকে যা গ্রহণ করেন তাতে উদার হন।"

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

যখন কোনও মানচিত্র মূল মানগুলি ফেরত দেয়, তখন এটি টাইপ পরামিতি ব্যবহার করে যতটা প্রকারের তথ্য সংরক্ষণ করতে পারে।

Comments

তাহলে V Get(K k)সি # তে কেন ?

এটি V Get(K k)সি # তে রয়েছে কারণ এটিও বোঝা যায়। জাভা এবং .NET পদ্ধতির মধ্যে পার্থক্যটি কেবলমাত্র যারা নন-ম্যাচিং স্টাফগুলি বন্ধ করে দেয়। সি # তে এটি সংকলক, জাভাতে এটি সংগ্রহ। আমি একবার NET এর অসামঞ্জস্যপূর্ণ সংগ্রহের ক্লাসগুলি নিয়ে একবারে ক্রুদ্ধ হয়েছি, তবে Get()এবং Remove()কেবল একটি মিলের

— ধরণটি

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

— বিচারক মানসিক

অবশ্যই তা হওয়া উচিত ছিল contains : K -> boolean।

— বিচারক মানসিক

পোষ্টেল ভুল ছিল ।

— আলনিটাক

Answer 5

আমি মনে করি জেনারিক্স টিউটোরিয়ালের এই বিভাগটি পরিস্থিতি (আমার জোর) ব্যাখ্যা করে:

"আপনাকে অবশ্যই নিশ্চিত করতে হবে যে জেনেরিক এপিআই অযৌক্তিকভাবে সীমাবদ্ধ নয়; এটি অবশ্যই এপিআই এর মূল চুক্তিকে সমর্থন করে চলতে হবে j জাভা.ইটিল.ক্লেকশন থেকে কিছু উদাহরণ আবার বিবেচনা করুন The প্রাক-জেনেরিক এপিআই দেখে মনে হচ্ছে:

interface Collection { 
  public boolean containsAll(Collection c);
  ...
}

এটিকে উদার করার একটি নিরপেক্ষ প্রচেষ্টা হ'ল:

interface Collection<E> { 
  public boolean containsAll(Collection<E> c);
  ...
}

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

• আগত সংকলনের স্থিতিশীল প্রকারটি পৃথক হতে পারে, সম্ভবত কলার সংগ্রহের সঠিক প্রকারটি জানেন না কারণ বা সম্ভবত এটি একটি সংগ্রহ <S>, যেখানে এস ইয়ের একটি সাব টাইপ because
• এটি বিভিন্ন ধরণের সংকলন সহ সমস্ত () রয়েছে বলে কল করা পুরোপুরি বৈধ। রুটিন কাজ করা উচিত, মিথ্যা ফিরে। "

Comments

তাহলে কেন নয় containsAll( Collection< ? extends E > c )?

— বিচারক মেন্টাল

@JudgeMental, যদিও একটি উদাহরণ হিসাবে উপরে এটি করার অনুমতি প্রয়োজন দেয়া containsAllএকটি সঙ্গে Collection<S>যেখানে Sএকটি হল supertype এর E। এটি থাকলে অনুমতি দেওয়া হত না containsAll( Collection< ? extends E > c )। উপরন্তু, যেমন হয় স্পষ্টভাবে উদাহরণে বিবৃত, এটা (ফেরত মান তারপর হচ্ছে একটি ভিন্ন ধরনের একটি সংগ্রহ পাস বৈধ এর false)।

— ডেভম্যাক

সুপারির ধরণের ই এর সংকলন সহ সমস্ত কন্ট্রোলের অনুমতি দেওয়ার প্রয়োজন হবে না I আমি যুক্তি দিচ্ছি যে কোনও ত্রুটি রোধ করতে স্ট্যাটিক টাইপের চেক দিয়ে that কলটি বাতিল করা প্রয়োজন। এটি একটি নির্বোধ চুক্তি, যা আমি মনে করি মূল প্রশ্নের মূল বিষয়।

— বিচারক মানসিক

Answer 6

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

জাভা টাইপ-নিরাপদ হ্যাশ টেবিল এবং সমতার আছে একমাত্র উপায় পরিহার হয় Object.equalsএবং Object.hashCodeএবং একটি জেনেরিক বিকল্প ব্যবহার করুন। কার্যকরী জাভা টাইপ ক্লাস নিয়ে আসে কেবল এই উদ্দেশ্যে: Hash<A>এবং Equal<A>। জন্য একটি মোড়কHashMap<K, V> সরবরাহ করা হয় যা এটি দেয় Hash<K>এবং Equal<K>এটির নির্মাতাকে। এই শ্রেণীর getএবং containsপদ্ধতিগুলি প্রকারের একটি সাধারণ আর্গুমেন্ট গ্রহণ করে K।

উদাহরণ:

HashMap<String, Integer> h =
  new HashMap<String, Integer>(Equal.stringEqual, Hash.stringHash);

h.add("one", 1);

h.get("one"); // All good

h.get(Integer.valueOf(1)); // Compiler error

Comments

এটি নিজেই 'ভি' (কে কী) হিসাবে ঘোষণার থেকে 'গেট' ধরণের প্রতিরোধ করে না, কারণ 'অবজেক্ট' সর্বদা কে-এর পূর্বপুরুষ, সুতরাং "কী.হ্যাশকোড ()" এখনও বৈধ থাকবে।

— ফিনউইউ

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

— cgp

Answer 7

সামঞ্জস্যের।

জেনেরিকগুলি উপলভ্য হওয়ার আগে সবেমাত্র পেয়েছিল (অবজেক্ট ও)।

যদি তারা (<K> ও) পেতে এই পদ্ধতিটি পরিবর্তন করে থাকে তবে জাভা ব্যবহারকারীদের উপর কেবলমাত্র কোডিং কোডটি পুনরায় সংকলন করার জন্য এটি সম্ভাব্যভাবে বিশাল কোড রক্ষণাবেক্ষণকে বাধ্য করেছিল।

তারা একটি অতিরিক্ত পদ্ধতি প্রবর্তন করতে পারত , get_checked (<K> o) বলুন এবং পুরাতন get () পদ্ধতিটিকে অবমূল্যায়ন করতে পারতেন যাতে একটি হালকা উত্তোলনের পথ ছিল। কিন্তু কোনও কারণে, এটি করা হয়নি। (আমরা বর্তমানে যে পরিস্থিতিটি করছি তা হ'ল get () আর্গুমেন্ট এবং মানচিত্রে ঘোষিত মূল প্রকারের <K> এর মধ্যে ধরণের সামঞ্জস্যতা পরীক্ষা করার জন্য ফাইন্ডব্যাগের মতো সরঞ্জামগুলি ইনস্টল করতে হবে))

.Equals () এর শব্দার্থক সম্পর্কিত যুক্তিগুলি বোগাস, আমি মনে করি। (প্রযুক্তিগতভাবে তারা সঠিক, তবে আমি এখনও মনে করি যে তারা বগুছ his তার সঠিক মনের কোনও ডিজাইনার কখনওই o1.equals (o2) সত্য তৈরি করতে যাবেন না যদি ও 1 এবং o2 এর কোনও সাধারণ সুপারক্লাস না থাকে))

Answer 8

আরও একটি গুরুতর কারণ আছে, এটি প্রযুক্তিগতভাবে করা যায় না, কারণ এটি মানচিত্রকে ব্রোক করে।

জাভাতে পলিমারফিক জেনেরিক নির্মাণের মতো রয়েছে <? extends SomeClass>। চিহ্নিত রেফারেন্সটি স্বাক্ষরিত টাইপকে নির্দেশ করতে পারে <AnySubclassOfSomeClass>। তবে পলিমারফিক জেনেরিক সেই উল্লেখটি কেবল পঠনযোগ্য করে তোলে । সংকলকটি আপনাকে জেনেরিক প্রকারগুলি কেবল পদ্ধতি (রিটার্নিং টাইপ মেথড) হিসাবে ব্যবহার করতে দেয় তবে এমন পদ্ধতি ব্যবহার করে ব্লক করে যেখানে জেনেরিক প্রকারটি আর্গুমেন্ট হয় (সাধারণ সেটটারের মতো)। এর অর্থ আপনি যদি লিখেন Map<? extends KeyType, ValueType>তবে সংকলক আপনাকে কল করার পদ্ধতিটি অনুমতি দেয় না get(<? extends KeyType>)এবং মানচিত্রটি অকেজো হবে। একমাত্র সমাধান এই পদ্ধতি জেনেরিক না করা: get(Object)।

Comments

কেন সেট পদ্ধতিটি দৃ strongly়ভাবে টাইপ করা হয়?

— সেনটেনজা

যদি আপনি 'পুট' বলতে চান: পুট () পদ্ধতিটি মানচিত্র পরিবর্তন করে এবং <এর মতো জেনেরিকের সাথে এটি সহজলভ্য হবে না? সামার ক্লাস> প্রসারিত করে। আপনি যদি এটি কল করেন তবে আপনি সংকলন ব্যতিক্রম পেয়েছেন। এই জাতীয় মানচিত্রটি "কেবলমাত্র পঠনযোগ্য" হবে

— ওহিই

Answer 9

পিছনে সামঞ্জস্য, আমি অনুমান। Map(বা HashMap) এখনও সমর্থন প্রয়োজন get(Object)।

Comments

তবে একই যুক্তি put(যা জেনেরিক ধরণের সীমাবদ্ধ করে না) এর জন্য তৈরি করা যেতে পারে । কাঁচা ধরণের ব্যবহার করে আপনি পিছনের দিকে সামঞ্জস্য পাবেন। জেনারিক্স "অপ্ট-ইন"।

— থিলো

ব্যক্তিগতভাবে, আমি মনে করি এই নকশার সিদ্ধান্তের সর্বাধিক সম্ভাব্য কারণটি পিছনের দিকের সামঞ্জস্য।

— geekdenz

Answer 10

আমি এটি তাকিয়ে ছিলাম এবং ভাবছিলাম কেন তারা এইভাবে এটি করেছে। আমি মনে করি না যে বিদ্যমান জবাবগুলির কোনও ব্যাখ্যা করে যে তারা কেবল নতুন জেনেরিক ইন্টারফেসটি কীটির জন্য কেবল সঠিক প্রকারটি গ্রহণ করতে পারেনি। আসল কারণটি হ'ল তারা জেনেরিকগুলি চালু করার পরেও তারা কোনও নতুন ইন্টারফেস তৈরি করেনি। মানচিত্র ইন্টারফেসটি একই পুরানো নন-জেনেরিক মানচিত্র, এটি কেবল জেনেরিক এবং নন-জেনেরিক সংস্করণ হিসাবে কাজ করে। এইভাবে যদি আপনার এমন কোনও পদ্ধতি থাকে যা অ জেনেরিক মানচিত্র গ্রহণ করে তবে আপনি এটি পাস করতে পারেন Map<String, Customer>এবং এটি এখনও কার্যকর হবে। একই সাথে পেতে চুক্তিটি অবজেক্টকে গ্রহণ করে যাতে নতুন ইন্টারফেসটিও এই চুক্তিকে সমর্থন করে।

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

Answer 11

আমরা এখনই বড় রিপ্যাক্টরিং করছি এবং আমরা পুরানো টাইপ সহ কিছু পেতে () মিস করিনি তা পরীক্ষা করার জন্য এই দৃ strongly়ভাবে টাইপ করা গেট () মিস করছি।

তবে সংকলনের সময় যাচাইয়ের জন্য আমি কার্যনির্বাহী / কুৎসিত কৌশল পেয়েছি: দৃ strongly়ভাবে টাইপ করা গেট, কন্টিকে, মুছে ফেলুন ... এবং আপনার প্রকল্পের জাভা.ইউটি প্যাকেজে এটি রেখে ম্যাপ ইন্টারফেস তৈরি করুন put

আপনি কেবল গেট (), ... ভুল প্রকারের সাথে কল করার জন্য সংকলন ত্রুটিগুলি পেয়ে যাবেন, অন্য সমস্ত কিছু সংকলকের জন্য ঠিক মনে হয় (কমপক্ষে গ্রহগ্রহের কেপলারের অভ্যন্তরে)।

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