কীভাবে সংজ্ঞায়িত করা যায় যে কোনও পদ্ধতিটি বলা যেতে পারে তার সংজ্ঞা নির্ধারণের চেয়ে একটি দৃ commitment় প্রতিজ্ঞাকে ওভাররাইড করা যায়?


36

থেকে: http://www.artima.com/lejava/articles/designprصولles4.html

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

আমি তার অর্থ বুঝতে পারছি না। কেউ দয়া করে এটি ব্যাখ্যা করতে পারেন?

উত্তর:


63

একটি প্রতিশ্রুতিবদ্ধ এমন জিনিস যা আপনার ভবিষ্যতের বিকল্পগুলি হ্রাস করে। কোনও পদ্ধতি প্রকাশের মাধ্যমে বোঝানো হয় যে ব্যবহারকারীরা এটি কল করবে, সুতরাং আপনি সামঞ্জস্যতা ভঙ্গ না করে এই পদ্ধতিটি সরাতে পারবেন না। আপনি যদি এটি রাখতেন তবে privateতারা (সরাসরি) এটি কল করতে পারেনি এবং কোনও দিন কোনও সমস্যা ছাড়াই আপনি এটি দূরে সরিয়ে ফেলতে পারেন। অতএব, কোনও পদ্ধতি প্রকাশ করা না প্রকাশের চেয়ে দৃ commitment় প্রতিশ্রুতি। একটি প্রকাশ করা overridable পদ্ধতি একটি এমনকি শক্তিশালী অঙ্গীকার। আপনার ব্যবহারকারীরা এটি কল করতে পারে এবং তারা নতুন ক্লাস তৈরি করতে পারে যেখানে পদ্ধতিটি আপনার যা মনে করে তা তা করে না!

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

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


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

5
@ ডেভিড আর্নো আমার মনে হয় না এটি উত্তরাধিকারের বিরুদ্ধে যুক্তি। আমি মনে করি এটি "ডিফল্টরূপে সমস্ত কিছুকে ওভাররিডযোগ্য করে তুলুন" এর বিরুদ্ধে যুক্তি। উত্তরাধিকার সূত্রপাত নিজেই বিপজ্জনক নয়, চিন্তাভাবনা ছাড়াই এটি ব্যবহার করা।
সুইভ

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

4
আপনি সহজেই সেই যুক্তিটিকে চারদিকে পরিণত করতে পারেন: প্রথম কোডার একটি ক্লিনআপ আর্গুমেন্ট তৈরি করে, তবে ভুল করে এবং সমস্ত কিছু পরিষ্কার করে না doesn't দ্বিতীয় কোডার ক্লিনআপ পদ্ধতিটিকে ওভাররাইড করে এবং একটি ভাল কাজ করে এবং কোডার # 3 ক্লাসটি ব্যবহার করে এবং কোডার # 1 এর মধ্যে গোলমাল করার পরেও কোনও রিসোর্স লিক নেই।
পিটার বি

6
পছন্দ করুন যে কারণে এটি ট্র্যাভেস্টি যে উত্তরাধিকার হ'ল প্রতিটি প্রারম্ভিক ওওপি বই এবং ক্লাসের মধ্যে পাঠের এক নম্বর।
কেভিন ক্রামউইদে

30

আপনি যদি কোনও সাধারণ ফাংশন প্রকাশ করেন তবে আপনি একতরফা চুক্তি দেন:
ডাকা হলে ফাংশনটি কী করে?

আপনি যদি কলব্যাক প্রকাশ করেন তবে আপনি একতরফা চুক্তিও দেন:
কখন এবং কীভাবে ডাকা হবে?

এবং যদি আপনি একটি ওভাররিড ফাংশন প্রকাশ করেন তবে এটি উভয়ই একবারে, তাই আপনি দ্বিমুখী চুক্তিটি দেন:
কখন ডাকা হবে এবং ডাকা হলে এটি করা আবশ্যক?

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

যেমন একটি দ্বি-পার্শ্বযুক্ত চুক্তি উপর reneging একটি উদাহরণ থেকে পদক্ষেপ showএবং hideকরতে setVisible(boolean)মধ্যে java.awt.Component


+1 টি। আমি নিশ্চিত নই যে অন্য উত্তরটি কেন গৃহীত হয়েছিল; এটি কিছু আকর্ষণীয় বিষয়বস্তু তোলে, তবে এটি অবশ্যই এই প্রশ্নের সঠিক উত্তর নয় , এটি অবশ্যই উদ্ধৃত প্যাসেজের অর্থ বোঝায় না।
রুখ

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

3
@ ইগেনশিপ: showএবং hideএখনও আছে, তারা ঠিক আছে @Deprecated। সুতরাং পরিবর্তনটি এমন কোনও কোড ভঙ্গ করে না যা কেবলমাত্র তাদের অনুরোধ করে। তবে আপনি যদি সেগুলি ওভাররাইড করে থাকেন তবে আপনার ওভাররাইডগুলি ক্লায়েন্টদের দ্বারা কল করা হবে না যারা নতুন 'সেটভিজিবল' তে মাইগ্রেট করে। (আমি কখনই সুইং ব্যবহার করিনি, সুতরাং আমি জানি না যে এগুলি ওভাররাইড করা কতটা সাধারণ; তবে এটি যেহেতু অনেক দিন আগে ঘটেছিল, তাই আমি অনুভব করেছি যে অনুদানকারীর মনে আছে যে এটি তাকে / তার জন্য বেদনাদায়কভাবে কাটায়))
রুখ

12

কিলিয়ান ফথের উত্তরটি দুর্দান্ত। এই সমস্যাটি কেন, এর ক্যানোনিকাল উদাহরণ * আমি যুক্ত করতে চাই। একটি পূর্ণসংখ্যা পয়েন্ট শ্রেণীর কল্পনা করুন:

class Point2D {
    public int x;
    public int y;

    // constructor
    public Point2D(int theX, int theY) { x = theX; y = theY; }

    public int hashCode() { return x + y; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point2D) ) { return false; }

        Point2D that = (Point2D) o;

        return (x == that.x) &&
               (y == that.y);
    }
}

এখন এটি একটি 3 ডি পয়েন্ট হতে সাব-শ্রেণীর করা যাক।

class Point3D extends Point2D {
    public int z;

    // constructor
    public Point3D(int theX, int theY, int theZ) {
        super(x, y); z = theZ;
    }

    public int hashCode() { return super.hashCode() + z; }

    public boolean equals(Object o) {
        if (this == o) { return true; }
        if ( !(o instanceof Point3D) ) { return false; }

        Point3D that = (Point3D) o;

        return super.equals(that) &&
               (z == that.z);
    }
}

সুপার সরল! আসুন আমাদের পয়েন্টগুলি ব্যবহার করুন:

Point2D p2a = new Point2D(3, 5);
Point2D p2b = new Point2D(3, 5);
Point2D p2c = new Point2D(3, 7);

p2a.equals(p2b); // true
p2b.equals(p2a); // true
p2a.equals(p2c); // false

Point3D p3a = new Point3D(3, 5, 7);
Point3D p3b = new Point3D(3, 5, 7);
Point3D p3c = new Point3D(3, 7, 11);

p3a.equals(p3b); // true
p3b.equals(p3a); // true
p3a.equals(p3c); // false

আপনি সম্ভবত ভাবছেন যে কেন আমি এত সহজ উদাহরণ পোস্ট করছি। এখানে ধরা আছে:

p2a.equals(p3a); // true
p3a.equals(p2a); // FALSE!

আমরা যখন 2 ডি পয়েন্টটির সমতুল্য 3 ডি পয়েন্টের সাথে তুলনা করি তখন আমরা সত্য হয়ে উঠি, কিন্তু আমরা যখন তুলনাটি উল্টো করি তখন আমরা মিথ্যা হয়ে যাই (কারণ পি 2 এ ব্যর্থ হয় instanceof Point3D)।

উপসংহার

  1. একটি সাবক্লাসে কোনও পদ্ধতি এমনভাবে প্রয়োগ করা সাধারণত সম্ভব যে এটি সুপার-ক্লাসটি কীভাবে কাজ করবে আশা করে তার সাথে আর সুসংগত নয়।

  2. সাধারণত পিতা-মাতার শ্রেণীর সাথে সামঞ্জস্যপূর্ণ এমন উপাখণ্ডে সমান () সমান প্রয়োগ করা অসম্ভব।

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

একটি ভাল বানানযুক্ত চুক্তির একটি দুর্দান্ত উদাহরণ হল তুলনামূলক.equals()উপরে বর্ণিত কারণে এটি কী বলে তা কেবল উপেক্ষা করুন । তুলনামূলক কীভাবে জিনিসগুলি .equals()করতে পারে না তার একটি উদাহরণ এখানে ।

নোট

  1. জোশ ব্লচের "কার্যকর জাভা" আইটেম 8 এই উদাহরণটির উত্স ছিল তবে ব্লচ একটি রঙিন পয়েন্ট ব্যবহার করেছে যা তৃতীয় অক্ষের পরিবর্তে একটি রঙ যুক্ত করে এবং ইনটগুলির পরিবর্তে ডাবল ব্যবহার করে। ব্লচের জাভা উদাহরণটি মূলত ওডারস্কি / চামচ / ভেনার্স দ্বারা নকল করা হয়েছে যারা তাদের উদাহরণ অনলাইনে উপলব্ধ করেছেন।

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

বোনাস

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


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

1
@ ব্যবহারকারী 2357112 আপনি ঠিক বলেছেন এবং আমি সেই উদাহরণটি সরিয়েছি। সোর্টার্ডম্যাপ.ইক্যুয়ালস () মানচিত্রের সাথে সামঞ্জস্যপূর্ণ হওয়া একটি পৃথক সমস্যা, যার বিষয়ে আমি অভিযোগ করার জন্য এগিয়ে যাব। সোর্টার্ডম্যাপটি সাধারণত ও (লগ 2 এন) হয় এবং হ্যাশম্যাপ (মানচিত্রের মূল প্ররোচনা) ও (1) হয়। অতএব, আপনি শুধুমাত্র একটি SortedMap যদি আপনি ব্যবহার করেন সত্যিই ক্রম যত্নশীল। সেই কারণে আমি বিশ্বাস করি অর্ডারটি সোর্টার্ড ম্যাপ বাস্তবায়নে সমান () পরীক্ষার একটি সমালোচনামূলক উপাদান হওয়ার জন্য যথেষ্ট গুরুত্বপূর্ণ। তাদের মানচিত্রের সাথে সমান () বাস্তবায়ন ভাগ করা উচিত নয় (তারা জাভায় অ্যাবস্ট্রাকম্যাপের মাধ্যমে করে)।
GlenPeterson

3
"উত্তরাধিকার খারাপ বা ভুল নয়, এটি কেবল কৌশল" " আপনি যা বলছেন তা আমি বুঝতে পেরেছি, তবে কৃপণ জিনিসগুলি সাধারণত ত্রুটি, বাগ এবং সমস্যাগুলির দিকে পরিচালিত করে। আপনি যদি একটি অধিক নির্ভরযোগ্য ভাবে একই জিনিস (বা প্রায় সব একই জিনিস) সাধন করতে পারেন, তখন আরো চতুর উপায় হল খারাপ।
jpmc26

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

3
লিসকোভের সাবস্টিটিউন নীতিমালার ই ​​এলআই 5 বলেছেন: কোনও শ্রেণি যদি কোনও শ্রেণীর Bসন্তান হতে পারে Aএবং আপনি যদি কোনও শ্রেণীর কোনও বিষয় তাত্ক্ষণিক করে তোলেন B, আপনি ক্লাস Bঅবজেক্টটি তার পিতামাতার কাছে নিক্ষেপ করতে সক্ষম হবেন এবং কোনও প্রয়োগের বিশদ না হারিয়ে কাস্টেড ভেরিয়েবলের এপিআই ব্যবহার করতে পারবেন শিশু. আপনি তৃতীয় সম্পত্তি প্রদান করে নিয়ম ভঙ্গ করলেন। ভেরিয়েবলটি zকাস্ট করার পরে আপনি কীভাবে সমন্বয় অ্যাক্সেস করার পরিকল্পনা করেন , যখন বেস ক্লাসের কোনও ধারণা নেই যে এই জাতীয় সম্পত্তি রয়েছে? যদি কোনও শিশু শ্রেণিকে তার বেসে ফেলে দিয়ে আপনি সর্বজনীন এপিআই ভেঙে দেন তবে আপনার বিমূর্ততাটি ভুল। Point3DPoint2D
অ্যান্ডি

4

উত্তরাধিকার হ'ল এনক্যাপসুলেশন দুর্বল

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

নীচে জাভা সংগ্রহ কাঠামো থেকে পিটার নরভিগের সৌজন্যে ( http://norvig.com/java-iaq.html ) একটি বাস্তব (সরলীকৃত) উদাহরণ দেওয়া আছে ।

Public Class HashTable{
    ...
    Public Object put(K key, V value){
        try{
            //add object to table;
        }catch(TableFullException e){
            increaseTableSize();
            put(key,value);
        }
    }
}

সুতরাং আমরা কি এটি সাবক্লাস যদি হয়?

/** A version of Hashtable that lets you do
 * table.put("dog", "canine");, and then have
 * table.get("dogs") return "canine". **/

public class HashtableWithPlurals extends Hashtable {

    /** Make the table map both key and key + "s" to value. **/
    public Object put(Object key, Object value) {
        super.put(key + "s", value);
        return super.put(key, value);
    }
}

আমাদের একটি বাগ আছে: মাঝেমধ্যে আমরা "কুকুর" যুক্ত করি এবং হ্যাশ টেবিল "কুকুর" এর জন্য একটি এন্ট্রি পায়। কারণটি হ'ল ছাদ শ্রেণীর নকশা করা ব্যক্তিটি প্রত্যাশা করেনি এমন কোনও একটি প্রয়োগের সরবরাহ করছিল।

উত্তরাধিকার এক্সটেনসিবিলিটি বিরতি দেয়

আপনি যদি আপনার ক্লাসকে সাবক্লাস করার অনুমতি দেন তবে আপনি আপনার ক্লাসে কোনও পদ্ধতি যুক্ত না করার প্রতিশ্রুতি দিচ্ছেন। এটি অন্যথায় কিছু না ভঙ্গ করেই করা যেতে পারে।

আপনি যখন কোনও ইন্টারফেসে নতুন পদ্ধতি যুক্ত করেন, আপনার ক্লাস থেকে উত্তরাধিকার সূত্রে প্রাপ্ত যে কোনও ব্যক্তিকে সেই পদ্ধতিগুলি প্রয়োগ করতে হবে।


3

যদি কোনও পদ্ধতি বলতে বলা হয়, আপনাকে কেবল এটি সঠিকভাবে কাজ করছে তা নিশ্চিত করতে হবে। এটাই. সম্পন্ন.

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

সুতরাং প্যারেন্ট পদ্ধতির স্রষ্টাকে ভবিষ্যতে শ্রেণি এবং এর পদ্ধতিগুলি কীভাবে ওভাররাইড করা যেতে পারে সে সম্পর্কে অনুমান করা দরকার।

তবে লেখক উদ্ধৃত পাঠ্যে একটি ভিন্ন ইস্যু নিয়ে কথা বলছেন:

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

পদ্ধতিটি aযা সাধারণত পদ্ধতি থেকে আহ্বান করা হয় তা বিবেচনা করুন bতবে কিছু বিরল এবং অ-সুস্পষ্ট ক্ষেত্রে পদ্ধতি থেকে c। ওভাররাইডিং পদ্ধতির লেখক যদি cপদ্ধতি এবং এর প্রত্যাশাগুলি উপেক্ষা করে থাকেন তবে aবিষয়গুলি কীভাবে ভুল হতে পারে তা স্পষ্ট।

সুতরাং এটি আরও গুরুত্বপূর্ণ যা aস্পষ্টভাবে এবং দ্ব্যর্থহীনভাবে সংজ্ঞায়িত করা হয়েছে, ভালভাবে নথিভুক্ত করা হয়েছে, "একটি কাজ করে এবং এটি ভালভাবে করে" - তার চেয়েও বেশি বলা যায় যে এটি কেবল ডাকাতির জন্য তৈরি একটি পদ্ধতি ছিল কিনা।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.