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