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


144

কালেকশন.রেভ (অবজেক্ট ও) জেনেরিক কেন নয় ?

মনে Collection<E>হতে পারেboolean remove(E o);

তারপরে, আপনি যখন দুর্ঘটনাক্রমে Set<String>প্রতিটি পৃথক স্ট্রিং এ এর ​​পরিবর্তে (উদাহরণস্বরূপ) অপসারণের চেষ্টা করবেন Collection<String>, এটি পরে ডিবাগিং সমস্যার পরিবর্তে একটি সংকলন সময় ত্রুটি হবে।


13
আপনি যখন এটি অটোবক্সিংয়ের সাথে একত্রিত করেন এটি আপনাকে সত্যিই কামড় দিতে পারে। আপনি যদি কোনও তালিকা থেকে কিছু সরিয়ে ফেলার চেষ্টা করেন এবং আপনি এটি কোনও int এর পরিবর্তে একটি পূর্ণসংখ্যা পাস করেন এটি রিমুভ (অবজেক্ট) পদ্ধতিটিকে কল করে।
ScArcher2

2
: মানচিত্রে সংক্রান্ত একই প্রশ্ন stackoverflow.com/questions/857420/...
AlikElzin-kilaka

উত্তর:


73

জোশ ব্লচ এবং বিল পুঘ এই সমস্যাটি জাভা পাজলার্স IV-তে উল্লেখ করেছেন: দ্য ফ্যান্টম রেফারেন্স মেনেস, ক্লোন আক্রমণ এবং দ্য শিফ্টের প্রতিশোধ

জোশ ব্লচ বলেছেন (:4:৪১) যে তারা মানচিত্রের প্রাপ্তির পদ্ধতিটি উদারকরণ, পদ্ধতি এবং অন্য কিছু সরানোর চেষ্টা করেছিল, তবে "এটি কার্যকরভাবে কার্যকর হয়নি"।

অনেকগুলি যুক্তিসঙ্গত প্রোগ্রাম রয়েছে যা আপনি জেনেরিক ধরণের সংগ্রহটিকে প্যারামিটার ধরণের হিসাবে অনুমতি দিলে উত্সাহ দেওয়া যায় না। উদাহরণস্বরূপ তাকে দ্বারা প্রদত্ত একজন ছেদ হয় Listএর Numbers এবং একটি Listএর Longগুলি।


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

2
ক্রিস - জাভা জেনেরিকস টিউটোরিয়াল পিডিএফ পড়ুন, এটি কেন তা ব্যাখ্যা করবে।
জিবিবি

42
আসলে, এটা খুব সহজ! যদি যোগ () কোনও ভুল বস্তু নিয়ে থাকে তবে এটি সংগ্রহটি ভেঙে দেবে। এটি এমন জিনিসগুলিকে ধারণ করবে যা এটি করা উচিত নয়! এটি মুছে ফেলার ক্ষেত্রে নয় (), বা () রয়েছে।
কেভিন বোউরিলিয়ন

12
ঘটনাচক্রে, সেই মৌলিক নিয়ম - কেবলমাত্র সংগ্রহের প্রকৃত ক্ষতি রোধ করতে টাইপ পরামিতি ব্যবহার করে - পুরো লাইব্রেরিতে একেবারে ধারাবাহিকভাবে অনুসরণ করা হয়।
কেভিন বোউরিলিয়ন

3
@ কেভিনবউরিলিয়ন: আমি জেনেরিকের সাথে কয়েক বছর ধরে কাজ করেছি (জাভা এবং সি # উভয় ক্ষেত্রেই) "সত্যিকারের ক্ষতির" বিধিটি এমনকি বিদ্যমান রয়েছে তা বুঝতে না পেরে ... তবে এখন আমি এটি প্রত্যক্ষভাবে দেখেছি যে এটি 100% নিখুঁত ধারণা তৈরি করে। মাছের জন্য ধন্যবাদ !!! এখন ব্যতীত আমি ফিরে যেতে এবং আমার প্রয়োগগুলি সন্ধান করতে বাধ্য হচ্ছি, এটি দেখার জন্য যে কোনও পদ্ধতি অবনমিত হতে পারে। দীর্ঘশ্বাস.
Corlettk

74

remove()( Mapপাশাপাশি পাশাপাশি Collection) জেনারিক নয় কারণ আপনার কোনও ধরণের অবজেক্টে পাস করতে সক্ষম হওয়া উচিত remove()। অপসারণ করা বস্তুটি আপনি যে বস্তুটিতে প্রবেশ করেছেন তার মতো ধরণের হওয়া উচিত নয় remove(); এটি কেবল তাদের সমান হওয়া প্রয়োজন। এর স্পেসিফিকেশন থেকে remove(), remove(o)বস্তু সরিয়ে ফেলা হবে eযেমন যে (o==null ? e==null : o.equals(e))হয় true। উল্লেখ্য প্রয়োজন কিছুই নেই যে oএবং eএকই ধরনের হতে হবে। এটি এই বিষয়টি থেকে অনুসরণ করে যে equals()পদ্ধতিটি Objectকেবলমাত্র বস্তুর মতো একই ধরণের নয়, পরামিতি হিসাবে গ্রহণ করে।

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


1
তবে আপনি যদি মানচিত্রটিকে মানচিত্র <তালিকা, কিছু কিছু> (অ্যারেলিস্টের পরিবর্তে) হিসাবে সংজ্ঞায়িত করতে চান তবে লিংকডলিস্ট ব্যবহার করে মুছে ফেলা সম্ভব হত। আমি মনে করি এই উত্তরটি ভুল।
অ্যালিক্লিজিন-কিলাকা

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

2
@ কেলোগস: " equals()পদ্ধতিটি জেনারাইজাইজ করা" বলতে কী বোঝায় ?
newacct

5
@ ম্যাটবাল: "যেখানে টি হ'ল ঘোষণাকারী শ্রেণি" তবে জাভাতে এ জাতীয় সিনট্যাক্স নেই। Tক্লাসে একটি প্রকারের প্যারামিটার হিসাবে ঘোষণা করতে হবে এবং Objectকোনও ধরণের পরামিতি নেই। "ঘোষিত শ্রেণি" বোঝায় এমন ধরণের কোনও উপায় নেই।
নিউএ্যাক্যাক্ট

3
আমি মনে করি কেলোগগুলি কি বলছে যদি সাম্যতা একটি জেনেরিক ইন্টারফেস Equality<T>ছিল equals(T other)। তারপরে আপনি থাকতে পারেন remove(Equality<T> o)এবং oঅন্য কিছুটির সাথে তুলনা করা যেতে পারে এমন কিছু অবজেক্ট T
ওয়েস্টন

11

কারণ আপনার ধরণের পরামিতি যদি ওয়াইল্ডকার্ড হয় তবে আপনি জেনেরিক অপসারণ পদ্ধতিটি ব্যবহার করতে পারবেন না।

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

আমি সম্ভবত এটি খুব ভাল ব্যাখ্যা করিনি, তবে এটি আমার পক্ষে যথেষ্ট যৌক্তিক বলে মনে হয়।


1
আপনি কি এই একটু বিস্তারিত বলতে পারেন?
টমাস

6

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

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

removeমুল বক্তব্যটি যে equalsপদ্ধতিতে প্রেরণ করা হচ্ছে তা পদ্ধতিটি সংজ্ঞায়িত করার জন্য দায়ী । বিল্ডিং পূর্বাভাস এইভাবে খুব সহজ হয়ে যায়।


বিনিয়োগকারী? (ফিলার ফিলার ফিলার)
ম্যাট আর

3
yourObject.equals(developer)সংগ্রহগুলি এপিআই-তে ডকুমেন্ট হিসাবে তালিকাটি কার্যকর করা হয়েছে : java.sun.com/javase/6/docs/api/java/util/…
হোসাম আলে

13
এটি আমার কাছে আপত্তিজনক বলে মনে হচ্ছে
RAY

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

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

5

ধরে এক একটি সংগ্রহ রয়েছে Cat, এবং ধরনের কিছু বস্তু রেফারেন্স Animal, Cat, SiameseCat, এবং Dog। সংগ্রহটি জিজ্ঞাসা করা যাতে এতে রেফারেন্স Catবা SiameseCatরেফারেন্স দ্বারা রেফার করা অবজেক্টটি যুক্তিযুক্ত মনে হয়। এতে Animalরেফারেন্স দ্বারা উল্লেখ করা অবজেক্টটি রয়েছে কিনা তা জিজ্ঞাসা করা খারাপ লাগবে তবে এটি এখনও পুরোপুরি যুক্তিসঙ্গত। প্রশ্নে থাকা অবজেক্টটি সর্বোপরি একটি Catহতে পারে এবং সংগ্রহের মধ্যে উপস্থিত হতে পারে।

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


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

"অদ্ভুত মনে হতে পারে তবে এটি এখনও পুরোপুরি যুক্তিসঙ্গত" তাই না? এমন এক পৃথিবীর কথা বিবেচনা করুন যেখানে এক প্রকারের অবজেক্টটি সর্বদা অন্য ধরণের একটি সামগ্রীর সাথে সমতার জন্য যাচাই করা যায় না, কারণ এটি কোন ধরণের সমান হতে পারে তা প্যারামিটারাইজড ( Comparableআপনি যে ধরণের সাথে তুলনা করতে পারেন তার জন্য কীভাবে পরামিতি করা হয়) এর সমান )। তারপরে লোকেরা কোনও সম্পর্কহীন ধরণের কিছু পাস করার অনুমতি দেওয়া যুক্তিসঙ্গত হবে না।
newacct

@newacct: প্রদত্ত বস্তু: মাত্রার তুলনা এবং সমতা তুলনা মধ্যে একটি মৌলিক পার্থক্য নেই Aএবং Bএক ধরনের, এবং Xএবং Yযেমন যে অন্যের, A> B, এবং X> Y। হয় A> Yএবং Y< A, বা X> Bএবং B< X। এই সম্পর্কগুলি কেবল তখনই বিদ্যমান থাকতে পারে যখন প্রস্থের তুলনাগুলি উভয় প্রকারের সম্পর্কে জানতে পারে। বিপরীতে, কোনও বস্তুর সাম্যতা তুলনা পদ্ধতিটি অন্য প্রকারের প্রশ্ন সম্পর্কিত অন্য কিছু সম্পর্কে জেনেও কেবল নিজেকে অন্য যে কোনও কিছুর সাথে অসম ঘোষণা করতে পারে। কোনও ধরণের একটি অবজেক্টের Catএটি কোনও ধারণা থাকতে পারে না ...
সুপারক্যাট

... "ধরণের" থেকে বড় "বা" চেয়ে কম " FordMustang, তবে এটি এমন কোনও বস্তুর সমান কিনা তা বলতে কোনও অসুবিধা হওয়া উচিত নয় (উত্তরটি সম্ভবত স্পষ্টতই" না ")।
সুপারক্যাট

4

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


0

এটি একটি আপস ছিল। উভয় পদ্ধতির তাদের সুবিধা রয়েছে:

  • remove(Object o)
    • আরও নমনীয়। উদাহরণস্বরূপ এটি সংখ্যার একটি তালিকা দিয়ে পুনরাবৃত্তি করতে এবং দীর্ঘস্থানের তালিকা থেকে এগুলি সরাতে দেয়।
    • এই নমনীয়তাটি ব্যবহার করে এমন কোডগুলি আরও সহজে জেনারেট করা যেতে পারে
  • remove(E e) সংকলনের সময় সূক্ষ্ম বাগগুলি সনাক্ত করে, ভুলভাবে শর্টসের তালিকা থেকে কোনও পূর্ণসংখ্যা অপসারণ করার চেষ্টা করার মতো বেশিরভাগ প্রোগ্রাম কী করতে চান তার আরও ধরণের সুরক্ষা এনে দেয়।

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


-1

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

বিস্তারিত জানার জন্য http://www.ibm.com/developerworks/java/library/j-jtp01255.html দেখুন ।

সম্পাদনা: একজন মন্তব্যকারী জিজ্ঞাসা করেন কেন অ্যাড পদ্ধতিটি জেনেরিক। [... আমার ব্যাখ্যা মুছে ফেলা হয়েছে ...] দ্বিতীয় মন্তব্যকারী আমার থেকে ফায়ার বার্ড 84 এর প্রশ্নের উত্তর দিয়েছেন।


2
তাহলে অ্যাড পদ্ধতিটি জেনেরিক কেন?
বব গেটিস

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

: শ্রাগ: - রানটাইম আচরণ পরিবর্তন করা হয় না ; সংকলন ত্রুটি রানটাইম আচরণ নয়। অ্যাড পদ্ধতির "আচরণ" এভাবে পরিবর্তিত হয়।
জেসন এস

-2

আর একটি কারণ ইন্টারফেসের কারণে। এটি দেখানোর জন্য এখানে একটি উদাহরণ রয়েছে:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

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

-3

কারণ এটি বিদ্যমান (প্রাক জাভা 5) কোডটি ভঙ্গ করবে। যেমন,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

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


4
যদি আমি একটি তালিকা ইনস্ট্যান্ট করি <স্ট্রিং> আমি কেবলমাত্র তালিকা.রেমভ (সামার স্ট্রিং) কল করতে সক্ষম হবেন বলে আশা করব; যদি আমার পশ্চাদপটে সামঞ্জস্যতা সমর্থন করার প্রয়োজন হয় তবে আমি একটি কাঁচা তালিকা - তালিকা <?> ব্যবহার করব তবে আমি তালিকাটি কল করতে পারি remআমি (কোনও অবজেক্ট), না?
ক্রিস মাজ্জোলা

5
যদি আপনি "যোগ" এর সাথে "অপসারণ" প্রতিস্থাপন করেন তবে সেই কোডটি ঠিক জাভা 5 এ যা করা হয়েছিল তার দ্বারা ঠিক ততটাই ভাঙা হবে
ডিজেক্লেওয়ার্থ
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.