উত্তরাধিকার বনাম অতিরিক্ত সম্পত্তি নাল মান সহ


12

Fieldsচ্ছিক ক্ষেত্র সহ শ্রেণীর জন্য, উত্তরাধিকার বা একটি অযোগ্য সম্পত্তি ব্যবহার করা কি ভাল? এই উদাহরণ বিবেচনা করুন:

class Book {
    private String name;
}
class BookWithColor extends Book {
    private String color;
}

অথবা

class Book {
    private String name;
    private String color; 
    //when this is null then it is "Book" otherwise "BookWithColor"
}

অথবা

class Book {
    private String name;
    private Optional<String> color;
    //when isPresent() is false it is "Book" otherwise "BookWithColor"
}

এই 3 টি বিকল্পের উপর নির্ভর করে কোডটি হ'ল:

if (book instanceof BookWithColor) { ((BookWithColor)book).getColor(); }

অথবা

if (book.getColor() != null) { book.getColor(); }

অথবা

if (book.getColor().isPresent()) { book.getColor(); }

প্রথম পদ্ধতিরটি আমার কাছে আরও প্রাকৃতিক দেখায় তবে কাস্টিংয়ের প্রয়োজনীয়তার কারণে এটি কম পাঠযোগ্য able এই আচরণ অর্জনের অন্য কোনও উপায় আছে কি?


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

এটিকে কিছুটা আরও সুনির্দিষ্ট করে তুলতে - এখানে 2 ধরণের বই রয়েছে - একটি রঙযুক্ত এবং একটি ছাড়া। সুতরাং সমস্ত বইয়ের রঙ নাও থাকতে পারে।
বোজন ভুকাসোভিচটেষ্ট

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

4
রঙিন সহ বইগুলি থেকে আপনি কী এমন আচরণটি সনাক্ত করতে পারেন? রঙিন সহ এবং বইয়ের মাঝে আপনি কী এমন সাধারণ আচরণ খুঁজে পেতে পারেন, যেখানে রঙিন রঙের বইগুলি কিছুটা আলাদাভাবে আচরণ করবে? যদি তা হয় তবে বিভিন্ন ধরণের ওওপি-র পক্ষে এটি একটি ভাল ক্ষেত্রে এবং বিবেচনাটি হ'ল বহিরাগতভাবে সম্পত্তি উপস্থিতি এবং মূল্য জিজ্ঞাসাবাদ না করে আচরণগুলি ক্লাসে স্থানান্তরিত করা।
এরিক tদ

1
যদি সম্ভাব্য বইয়ের রঙগুলি আগে সময়ের আগে জানা থাকে তবে বুককালার জন্য কোনও বিকল্পযুক্ত বুককালারের জন্য এনাম ক্ষেত্রটি কীভাবে হবে না?
গ্রাহাম

উত্তর:


7

এটা পরিস্থিতির উপর নির্ভর করে। নির্দিষ্ট উদাহরণটি অবাস্তব since যেহেতু আপনার কাছে BookWithColorএকটি আসল প্রোগ্রামে ডাকা সাবক্লাস নেই ।

তবে সাধারণভাবে, এমন একটি সম্পত্তি যা নির্দিষ্ট কিছু সাবক্লাসের জন্য কেবল বোঝায় সেগুলি কেবল সেই সাবক্লাসগুলিতেই থাকা উচিত।

উদাহরণস্বরূপ, যদি Bookহয়েছে PhysicalBookএবং DigialBookসন্তান হিসাবে, তারপর PhysicalBookএকটি থাকতে পারে weightসম্পত্তি এবং DigitalBookএকটি sizeInKbসম্পত্তি। তবে এর বিপরীতে DigitalBookথাকবে না weightBookকোনও শ্রেণীর কেবলমাত্র সমস্ত বংশধরদের দ্বারা ভাগ করা সম্পত্তি থাকতে হবে, কারণ সম্পত্তি থাকবে না।

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


অথবা আপনি উভয় প্রতিফলিত করতে সক্ষম হতে ওজন হ্রাস করতে পারে, কিন্তু এটি সম্ভবত খুব বেশি much
ওয়ালফ্র্যাট

3
@ ওয়ালফ্র্যাট: একই ক্ষেত্রটি বিভিন্ন সাবক্লাসে সম্পূর্ণ ভিন্ন জিনিস উপস্থাপন করা সত্যিই খারাপ ধারণা হবে।
জ্যাকবিবি 2:57

যদি কোনও বইয়ের দৈহিক এবং ডিজিটাল সংস্করণ উভয়ই থাকে? প্রতিটি alচ্ছিক ক্ষেত্র থাকার বা না থাকার প্রতিটি অনুক্রমের জন্য আপনাকে আলাদা শ্রেণি তৈরি করতে হবে। আমি মনে করি সেরা সমাধানটি কেবলমাত্র কিছু ক্ষেত্র বাদ দেওয়া বা বইয়ের উপর নির্ভর করে না করার অনুমতি দেবে। আপনি সম্পূর্ণ ভিন্ন পরিস্থিতি উদ্ধৃত করেছেন যেখানে দুটি শ্রেণি বিভিন্নভাবে কার্যকরভাবে আচরণ করবে। এই প্রশ্নটি ইঙ্গিত দেয় না। তাদের কেবল একটি ডেটা স্ট্রাকচারের মডেল করা দরকার।
ক্যাসেল

@ ৪ ক্যাসেল: আপনার প্রতি সংস্করণে আলাদা ক্লাসের প্রয়োজন হবে যেহেতু প্রতিটি সংস্করণের আলাদা আলাদা দামও থাকতে পারে। আপনি এটি alচ্ছিক ক্ষেত্রগুলি দিয়ে সমাধান করতে পারবেন না। তবে আমরা উদাহরণ থেকে জানি না যে অপার রঙ বা "বর্ণহীন বই" সহ বইগুলির জন্য আলাদা আচরণ চান, তাই এই ক্ষেত্রে সঠিক মডেলিংটি কী তা জানা অসম্ভব।
জ্যাকবিবি 3:51

3
@ জ্যাককসবি এর সাথে একমত আপনি "মডেলিং বই" এর জন্য সর্বজনীনভাবে সঠিক সমাধান দিতে পারবেন না, কারণ আপনি কোন সমস্যা সমাধানের চেষ্টা করছেন এবং আপনার ব্যবসা কী তা তার উপর নির্ভর করে। আমি মনে করি এটি নিরাপদে বলেছি যে আপনি যেখানে লস্কভের লঙ্ঘন করেছেন সেখানে শ্রেণিক্রমের শ্রেণিবদ্ধতা সংজ্ঞায়িতভাবে ভুল (টিএম) যদিও (হ্যাঁ হ্যাঁ, আপনার কেসটি সম্ভবত খুব বিশেষ এবং এটি পরোয়ানা দিয়েছে)
সারার

5

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

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


এটি সত্যিই একটি গুরুত্বপূর্ণ বিষয়! এটি শ্রেণিবদ্ধ বৈশিষ্ট্যের পরিবর্তে oneচ্ছিক বৈশিষ্ট্যগুলির সংগ্রহ বিবেচনা করা উচিত কিনা তা নির্ধারণ করে।
ক্রোমানয়েড

1

একটি জাভাবিয়ানকে (আপনার মতো Book) একটি ডেটাবেজে রেকর্ড হিসাবে ভাবেন । nullNo চ্ছিক কলামগুলি যখন তাদের কোনও মূল্য থাকে না তবে এটি পুরোপুরি আইনী। অতএব, আপনার দ্বিতীয় বিকল্প:

class Book {
    private String name;
    private String color; // null when not applicable
}

সবচেয়ে যুক্তিসঙ্গত। 1

আপনি Optionalক্লাসটি কীভাবে ব্যবহার করবেন তা সতর্ক থাকুন । উদাহরণস্বরূপ, এটি হয় না Serializable, যা সাধারণত জাভাবীনের একটি বৈশিষ্ট্য। এখানে স্টিফেন কোলবর্ন থেকে কিছু টিপস দেওয়া হয়েছে :

  1. কোনও ধরণের ভেরিয়েবল ঘোষনা করবেন না Optional
  2. nullকোনও শ্রেণীর ব্যক্তিগত স্কোপের মধ্যে alচ্ছিক ডেটা নির্দেশ করতে ব্যবহার করুন ।
  3. OptionalTersচ্ছিক ক্ষেত্রে অ্যাক্সেসকারীদের জন্য ব্যবহার করুন ।
  4. Optionalসেটার বা কনস্ট্রাক্টর ব্যবহার করবেন না ।
  5. OptionalAnyচ্ছিক ফলাফল রয়েছে এমন অন্যান্য ব্যবসায়ের যুক্তিযুক্ত পদ্ধতির জন্য রিটার্ন টাইপ হিসাবে ব্যবহার করুন ।

অতএব, আপনার শ্রেণীর মধ্যে আপনার nullক্ষেত্রটি উপস্থিত নেই তা উপস্থাপন করার জন্য ব্যবহার করা উচিত , তবে যখন color পাতাটিBook (ফিরতি টাইপ হিসাবে) ছেড়ে যায় তখন এটি একটি দিয়ে আবৃত করা উচিত Optional

return Optional.ofNullable(color); // inside the class

book.getColor().orElse("No color"); // outside the class

এটি পরিষ্কার নকশা এবং আরও পঠনযোগ্য কোড সরবরাহ করে।


1 আপনি যদি অন্য কোনও বইয়ের BookWithColorতুলনায় বিশেষ দক্ষতা সম্পন্ন বইয়ের পুরো "শ্রেণি" সজ্জিত করার উদ্দেশ্যে থাকেন তবে উত্তরাধিকারটি ব্যবহার করা বোধগম্য হবে।


1
কে একটি ডাটাবেস সম্পর্কে কিছু বলেছেন? সমস্ত ওও নিদর্শনগুলিকে যদি কোনও সম্পর্কিত ডেটাবেস দৃষ্টান্তের সাথে মানিয়ে নিতে হয় তবে আমাদের প্রচুর ওও নিদর্শনগুলি পরিবর্তন করতে হবে।
আলেকজানবার্ড

আমি যুক্তিযুক্ত যুক্তি যুক্ত করব যে "কেবলমাত্র ক্ষেত্রে" অব্যবহৃত বৈশিষ্ট্য যুক্ত করা স্বল্পতম বিকল্প। যেমনটি অন্যরা বলেছে, এটি ব্যবহারের ক্ষেত্রে নির্ভর করে তবে সর্বাধিক আকাঙ্ক্ষিত পরিস্থিতি হ'ল সম্পত্তি বহন করা নয় যেখানে কোনও বহিরাগত প্রয়োগের প্রয়োজন আছে যে বাস্তবে বিদ্যমান কোন সম্পত্তি ব্যবহৃত হচ্ছে কিনা তা জানতে হবে।
ভোলকার কুয়েফেল

@ ভোলকার আসুন আমরা দ্বিমত পোষণ করতে সম্মত হই, কারণ আমি Optionalএই সঠিক উদ্দেশ্যে জাভাতে ক্লাস যুক্ত করার ক্ষেত্রে বেশ কয়েকজন ব্যক্তিকে হাতছাড়া করে উদ্ধৃত করতে পারি । এটি ওও নাও হতে পারে তবে এটি অবশ্যই একটি কার্যকর মতামত।
ক্যাসেল

@ আলেকজান্দারবার্ড আমি বিশেষত একটি জাভাবীনের মোকাবেলা করছি, যা সিরিয়ালাইজযোগ্য হতে হবে। আমি যদি জাভাবিয়ান আনার মাধ্যমে বিষয় থেকে দূরে থাকি তবে তা আমার ভুল ছিল।
ক্যাসেল

@ আলেকজান্দ্রবার্ড আমি সমস্ত নিদর্শনগুলি একটি সম্পর্কিত ডেটাবেসটির সাথে মেলে আশা করি না তবে আমি জাভা বিনের আশা করি
ক্যাসেল

0

আপনি হয় একটি ইন্টারফেস (উত্তরাধিকার নয়) বা কিছু ধরণের সম্পত্তি মেকানিক ব্যবহার করা উচিত (এমনকি এমন কিছু যা সম্পদ বিবরণ কাঠামোর মতো কাজ করে)।

তাই হয়

interface Colored {
  Color getColor();
}
class ColoredBook extends Book implements Colored {
  ...
}

অথবা

class PropertiesHolder {
  <T> extends Property<?>> Optional<T> getProperty( Class<T> propertyClass ) { ... }
  <V, T extends Property<V>> Optional<V> getPropertyValue( Class<T> propertyClass ) { ... }
}
interface Property<T> {
  String getName();
  T getValue();
}
class ColorProperty implements Property<Color> {
  public Color getValue() { ... }
  public String getName() { return "color"; }
}
class Book extends PropertiesHolder {
}

স্পষ্টকরণ (সম্পাদনা):

সত্তা শ্রেণিতে কেবল alচ্ছিক ক্ষেত্রগুলি যুক্ত করা

বিশেষত ptionচ্ছিক -র‌্যাপার সহ (সম্পাদনা করুন: 4 ক্যাসলের উত্তর দেখুন) আমি মনে করি এটি (মূল সত্তায় ক্ষেত্র যুক্ত করা) একটি ছোট স্কলে নতুন বৈশিষ্ট্য যুক্ত করার একটি কার্যকর উপায়। এই পদ্ধতির সাথে সবচেয়ে বড় সমস্যাটি হ'ল এটি কম সংশ্লেষের বিরুদ্ধে কাজ করতে পারে।

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

অতিরিক্ত সম্পত্তি সরবরাহ করার উপায়ের ক্ষেত্রে উত্তরাধিকার কেন সমস্যাযুক্ত?

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

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

উত্তরাধিকার প্রায়শই কেন একটি সমস্যাযুক্ত ধারণা:

ওওপি সমর্থকরা সাধারণত উত্তরাধিকারকে কেন খারাপ জিনিস হিসাবে দেখেন

জাভা ওয়ার্ল্ড: কেন প্রসারিত করা খারাপ

বৈশিষ্ট্যের একটি সেট রচনা করতে ইন্টারফেসের একটি সেট বাস্তবায়নে সমস্যা

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

সম্পাদনা করুন: gnasher729 দ্বারা আরেকটি গুরুত্বপূর্ণ দিক উল্লেখ করা হয়েছে । আপনি প্রায়শই একটি বিদ্যমান অবজেক্টে গতিশীল optionচ্ছিক বৈশিষ্ট্য যুক্ত করতে চান। উত্তরাধিকার বা ইন্টারফেসের সাথে আপনাকে পুরো বিষয়টিকে অন্য শ্রেণীর সাথে পুনরায় তৈরি করতে হবে যা fromচ্ছিক থেকে অনেক দূরে।

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

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


এবং এটি "এই বিকল্পগুলির মধ্যে কীভাবে সিদ্ধান্ত নেবে" এই প্রশ্নের সমাধান করেনি, এটি কেবল অন্য একটি বিকল্প। ওপি উপস্থাপিত সমস্ত বিকল্পগুলির চেয়ে কেন এটি সর্বদা ভাল?
আলেকজানবার্ড

আপনারা ঠিক বলেছেন, আমি উত্তরটি উন্নত করব।
ক্রোমানয়েড

@ 4 ক্যাসল জাভা ইন্টারফেসে উত্তরাধিকার নয়! ইন্টারফেস বাস্তবায়ন একটি চুক্তি মেনে চলার একটি উপায় যখন কোনও শ্রেণীর উত্তরাধিকার সূত্রে প্রাপ্ত হয় মূলত তার আচরণকে প্রসারিত করে। আপনি এক শ্রেণিতে একাধিক ক্লাস প্রসারিত করতে না পারার সময় আপনি একাধিক ইন্টারফেস প্রয়োগ করতে পারেন। আমার উদাহরণে আপনি মূল সত্তার আচরণের উত্তরাধিকার হিসাবে উত্তরাধিকার ব্যবহার করার সময় আপনি ইন্টারফেসগুলি দিয়ে প্রসারিত করেন।
ক্রোমানয়েড

বোধ হয়। আপনার উদাহরণে PropertiesHolderসম্ভবত একটি বিমূর্ত শ্রেণি হবে। কিন্তু আপনি কি সুপারিশ করবে জন্য একটি বাস্তবায়ন হতে getPropertyবা getPropertyValue? তথ্যটি কোথাও কোথাও কোথাও কোনও ধরণের উদাহরণ ক্ষেত্রে সংরক্ষণ করতে হবে। অথবা আপনি Collection<Property>ক্ষেত্রগুলি ব্যবহার না করে বৈশিষ্ট্যগুলি সংরক্ষণ করতে একটি ব্যবহার করবেন?
ক্যাসেল

1
আমি স্পষ্টতার কারণে Bookপ্রসারিত করেছি PropertiesHolderPropertiesHolderসাধারণত সমস্ত শ্রেণিতে সাধারণত এই সদস্যের সদস্য হওয়া উচিত যা এই কার্যকারিতা প্রয়োজন। বাস্তবায়নের একটি Map<Class<? extends Property<?>>,Property<?>>বা এই জাতীয় কিছু রাখা হবে । এটি বাস্তবায়নের কুৎসিত অংশ তবে এটি জ্যাকএক্সবি এবং জেপিএর সাথে কাজ করে এমন একটি দুর্দান্ত ফ্রেমওয়ার্ক সরবরাহ করে।
ক্রোমানয়েড

-1

যদি Bookবর্গ নিচের মত রঙ সম্পত্তি ছাড়া derivable হয়

class E_Book extends Book{
   private String type;
}

তাহলে উত্তরাধিকার যুক্তিসঙ্গত।


আমি নিশ্চিত না যে আমি আপনার উদাহরণটি বুঝতে পেরেছি? যদি colorব্যক্তিগত হয় তবে যে কোনও উত্পন্ন শ্রেণীর যে colorকোনওভাবেই উদ্বিগ্ন হওয়া উচিত নয় । সম্পূর্ণ Bookউপেক্ষা colorকরে কিছু কনস্ট্রাক্টর যুক্ত করুন এবং এটি ডিফল্ট হবে null
ক্যাসেল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.