জাভা সংগ্রহগুলির প্যাকেজিং কাঠামো (java.util) - কেন জাভা.লাংয়ে ইটেবলযোগ্য বসে?

নীচের চিত্র অনুসারে, ইন্টারফেস বাদে Iterableবাকী সমস্ত নির্মাণ (ইন্টারফেস / শ্রেণি / বিমূর্ত শ্রেণি) একই প্যাকেজে বসেjava.util

এখানে চিত্র বর্ণনা লিখুন

কেন প্যাকেজে Iterableবসে java.lang?

দ্রষ্টব্য: জাভা প্রোগ্রামিংয়ের প্যাকেজিংয়ের দিকটি বোঝার উদ্দেশ্য।

— overexchange
সূত্র

কেন এটিকে জাভা 8 ট্যাগ করা হয় তা অবাক করে , এখানে জিজ্ঞাসিত সমস্ত এপিআই অনেক বেশি বয়স্ক। ইটেবারেবল জাভা সংস্করণ 1.5 তে প্রবর্তিত হয়েছিল, সংগ্রহের কাঠামোটি 1.2

— gnat

উত্তর:

এর জাভাদকটিতে যেমন ব্যাখ্যা করা হয়েছে , এর উদ্দেশ্য Iterableহ'ল নির্দিষ্ট ভাষার বাক্য গঠনকে সমর্থন করা :

এই ইন্টারফেসটি প্রয়োগ করে কোনও বিষয়টিকে "ফোরচ" স্টেটমেন্টের লক্ষ্য হতে দেয়

যেমনটি এটি ল্যাং প্যাকেজের অন্তর্ভুক্ত , যা

জাভা প্রোগ্রামিং ভাষার নকশার জন্য মৌলিক এমন ক্লাস সরবরাহ করে।

ডায়াগ্রাম এ অন্য ক্লাসের অন্তর্গত JCF তাই, হয় util প্যাকেজ যা

সংগ্রহের কাঠামো ধারণ করে ...

— মশা
সূত্র

+1 টি। আমি মনে করি, যদিও এটি Iteratorআদর্শভাবে হওয়া উচিত java.lang, যেহেতু Iterableরয়েছে। অবশ্যই, এটি java.utilপশ্চাদপদ-সামঞ্জস্যতার কারণে থাকতে হবে (এটি "ফরচ" নির্মাণের ভাষায় যথাযথ ভূমিকা রাখার অনেক আগে জেডিকে প্রবর্তিত হয়েছিল)।

— রুখ

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

— gnat

আমার বক্তব্যটি এটি সুবিধাজনক নয়, তবে উপযুক্ত ভাষা এখন এটির উপর নির্ভর করে। (নোট যে, সরাইয়া এর নির্ভরতা থেকে Iterableউপর Iterator , java.langপ্যাকেজ সাধারণত ক্লাস উপর নির্ভর করে না java.util।)

— ruakh

@ruakh আমি দেখছি এটি একটি খুব ভাল পয়েন্ট, ধন্যবাদ। আমি বুঝতে পারি যে এপিআই ডিজাইনাররা কেন "পুনরুক্তি সম্পাদনকারী কোনও বস্তু" প্রকাশ করতে ইটেবল চেয়েছিলেন তবে তারা যেভাবে এটি বেছে নিয়েছেন তা মার্জিত মনে হয় না

— gnat

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

বাস্তবায়নকারী ক্লাসগুলি হ'ল:

java.util
- AbstractCollection
- AbstractList
- AbstractQueue
- AbstractSequentialList
- AbstractSet
- ...
- সহগামী
  - ArrayBlockingQueue
  - ConcurrentLinkedDeque
  - ...
java.beancontext
- BeanContextServicesSupport
- BeanContextSupport
- ...
java.sql
- BatchUpdateException
- DataTruncation
- ...
javax.management
- AttributeList
javax.print.attribute.standard
- JobStateReasons
- ...
...

এটি একটি বিশাল তালিকা। এবং এটি সমস্ত ধরণের প্যাকেজগুলিকে স্পর্শ করে।

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

এর সমাধানটি হ'ল "হ্যাঁ, পরিবেশনযোগ্য ইন্টারফেসটি এমন কিছু যা জাভা এবং জাভাক্স কাঠামোর পুরোপুরি বিভিন্ন শ্রেণীর এবং প্যাকেজগুলির উপর নির্ভরশীল It এটি ভাষা লাইব্রেরির সবচেয়ে বেসে থাকা উচিত - জাভা .lang। "

এবং এটিই এটি খুঁজে পাবেন।

সম্পর্কিত পড়া:

— সম্প্রদায়
সূত্র