আমরা যদি সেটউইথথ এবং সেটহাইটের পদ্ধতিগুলিকে ওভাররাইড করি তবে আয়তক্ষেত্র থেকে স্কয়ার উত্তরাধিকারসূত্রে সমস্যা কেন হবে?


105

স্কোয়ারটি যদি এক ধরণের আয়তক্ষেত্র হয় তবে এর চেয়ে কেন একটি বর্গক্ষেত্রটি আয়তক্ষেত্র থেকে উত্তরাধিকারী হতে পারে না? বা কেন এটি একটি খারাপ নকশা?

আমি লোকদের বলতে শুনেছি:

আপনি যদি স্কোয়ারটি আয়তক্ষেত্র থেকে প্রাপ্ত করেছেন, তবে আপনি যে কোনও আয়তক্ষেত্রের প্রত্যাশা করেন সেখানে স্কয়ার ব্যবহারযোগ্য হবে

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

আপনার যদি আয়তক্ষেত্রের বেস শ্রেণিতে যদি সেটউইথ এবং সেটহাইট পদ্ধতি থাকে এবং যদি আপনার আয়তক্ষেত্রের রেফারেন্সটি কোনও স্কোয়ারের দিকে নির্দেশ করে, তবে সেটউইথ এবং সেটহাইট কোনও অর্থবোধ করে না কারণ একটিটি সেট করে অন্যটিকে এটির সাথে মেলে। এক্ষেত্রে স্কোয়ার আয়তক্ষেত্রের সাথে লিসকোভ সাবস্টিটিউশন টেস্টে ব্যর্থ হয় এবং স্কোয়ারটি আয়তক্ষেত্র থেকে উত্তরাধিকার সূত্রে প্রাপ্ত বিমূর্ততা খারাপ।

কেউ কি উপরোক্ত যুক্তি ব্যাখ্যা করতে পারেন? আবার, যদি আমরা স্কয়ারে সেটউইথ এবং সেটহাইট পদ্ধতিগুলি অতিরিক্ত চালিত করি, তবে এটি কি এই সমস্যার সমাধান করবে না?

শুনেছি / পড়েছি:

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

এখানে আমি বিশ্বাস করি "পুনরায় আকারযুক্ত" সঠিক শব্দটি। আয়তক্ষেত্রগুলি "পুনরায় আকারযুক্ত" এবং তেমনি স্কোয়ারগুলি। আমি কি উপরোক্ত তর্ক কিছু মিস করছি? একটি বর্গক্ষেত্রকে যে কোনও আয়তক্ষেত্রের মতো পুনরায় আকার দেওয়া যেতে পারে।


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

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

7
আমি মনে করি আরও ভাল প্রশ্ন Why do we even need Square? এটি দুটি কলম থাকার মত। একটি নীল কলম এবং একটি লাল নীল, হলুদ বা সবুজ কলম। নীল কলম অপ্রয়োজনীয় - এর চেয়েও বেশি বর্গক্ষেত্রের ক্ষেত্রে এর কোনও ব্যয়বহুল নেই।
গুড্ডর

2
@eBusiness এর বিমূর্ততা এটিই একটি ভাল শেখার প্রশ্ন তৈরি করে। নির্দিষ্ট ব্যবহারের ক্ষেত্রে সাব-টাইপিংয়ের ব্যবহারগুলি স্বতন্ত্রভাবে খারাপ কিনা তা চিহ্নিত করার পক্ষে সক্ষম হওয়া আমাদের পক্ষে গুরুত্বপূর্ণ।
ডোভাল

5
পছন্দ করেছেন সাবটাইপিং সমস্ত আচরণ সম্পর্কে এবং একটি পরিবর্তনীয় স্কোয়ার একটি পরিবর্তনীয় আয়তক্ষেত্রের মতো আচরণ করে না। এই কারণেই "এটি একটি ..." রূপকটি খারাপ।
ডোভাল

উত্তর:


189

মূলত আমরা জিনিসগুলি সংবেদনশীল আচরণ করতে চাই।

নিম্নলিখিত সমস্যা বিবেচনা করুন:

আমাকে একটি গ্রুপ আয়তক্ষেত্র দেওয়া হয়েছে এবং আমি তাদের ক্ষেত্রটি 10% বাড়াতে চাই। সুতরাং আমি যা করছি তা আমি আয়তক্ষেত্রটির দৈর্ঘ্যটি আগে যা ছিল তার চেয়ে 1.1 গুণ নির্ধারণ করেছি।

public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles)
{
  foreach(var rectangle in rectangles)
  {
    rectangle.Length = rectangle.Length * 1.1;
  }
}

এখন এই ক্ষেত্রে, আমার সমস্ত আয়তক্ষেত্রগুলির দৈর্ঘ্য এখন 10% বৃদ্ধি পেয়েছে, যা তাদের অঞ্চল 10% বৃদ্ধি করবে। দুর্ভাগ্যক্রমে, কেউ আমাকে স্কোয়ার এবং আয়তক্ষেত্রের মিশ্রণটি দিয়েছে এবং যখন আয়তক্ষেত্রটির দৈর্ঘ্য পরিবর্তন করা হয়েছিল, তখন প্রস্থটি ছিল।

আমার ইউনিট পরীক্ষা পাস হয়েছে কারণ আমি আয়তক্ষেত্রের সংগ্রহ ব্যবহার করতে আমার সমস্ত ইউনিট পরীক্ষা লিখেছি wrote আমি এখন আমার অ্যাপ্লিকেশনটিতে একটি সূক্ষ্ম বাগ প্রবর্তন করেছি যা কয়েক মাস ধরে নজরে না যেতে পারে।

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

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

public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles)
{
  foreach(var rectangle in rectangles)
  {
    if (typeof(rectangle) == Rectangle)
    {
      rectangle.Length = rectangle.Length * 1.1;
    }
    if (typeof(rectangle) == Square)
    {
      rectangle.Length = rectangle.Length * 1.04880884817;
    }
  }
}

আলফ্রেড তার উবার হ্যাকিংয়ের দক্ষতায় খুশি এবং জিল সাইন ইন করে যে বাগটি ঠিক হয়ে গেছে।

পরের মাসে কাউকে বেতন দেওয়া হয় না কারণ অ্যাকাউন্টিং IncreaseRectangleSizeByTenPercentপদ্ধতিতে স্কোয়ারগুলি পাস করতে সক্ষম হওয়া এবং ক্ষেত্রের 21% বৃদ্ধি পাওয়ার উপর নির্ভরশীল ছিল । ইস্যুর উত্সটি সন্ধান করতে পুরো সংস্থাটি "অগ্রাধিকার 1 বাগফিক্স" মোডে যায়। তারা আলফ্রেডের সমস্যার সমাধান করতে সমস্যাটি সনাক্ত করে। তারা জানে যে তাদের অ্যাকাউন্টিং এবং বিজ্ঞাপন উভয়কেই খুশি রাখতে হবে। সুতরাং তারা পদ্ধতি কলটির সাথে ব্যবহারকারীকে চিহ্নিত করে সমস্যাটি সমাধান করে:

public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles)
{
  IncreaseRectangleSizeByTenPercent(
    rectangles, 
    new User() { Department = Department.Accounting });
}

public void IncreaseRectangleSizeByTenPercent(IEnumerable<Rectangle> rectangles, User user)
{
  foreach(var rectangle in rectangles)
  {
    if (typeof(rectangle) == Rectangle || user.Department == Department.Accounting)
    {
      rectangle.Length = rectangle.Length * 1.1;
    }
    else if (typeof(rectangle) == Square)
    {
      rectangle.Length = rectangle.Length * 1.04880884817;
    }
  }
}

এবং তাই এবং তাই ঘোষণা.

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

এই সমস্যাটি ঠিক করার দুটি বাস্তব উপায় রয়েছে।

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

দ্বিতীয় উপায়টি স্কোয়ার এবং আয়তক্ষেত্রগুলির মধ্যে উত্তরাধিকার শৃঙ্খলা ভাঙা। যদি কোনও বর্গক্ষেত্রের একক SideLengthসম্পত্তি থাকার সাথে সংজ্ঞা দেওয়া হয় এবং আয়তক্ষেত্রগুলির একটি Lengthএবং Widthসম্পত্তি থাকে এবং কোনও উত্তরাধিকার না থাকে তবে আয়তক্ষেত্রের প্রত্যাশা করে এবং বর্গক্ষেত্র অর্জন করে ঘটনাক্রমে জিনিসগুলি ভাঙ্গা অসম্ভব। সি # পদগুলিতে, আপনি sealআপনার আয়তক্ষেত্রের শ্রেণিটি করতে পারতেন , এটি নিশ্চিত করে যে আপনি যে সমস্ত আয়তক্ষেত্রগুলি পান সেগুলি আসলে আয়তক্ষেত্রগুলি।

এই ক্ষেত্রে, আমি সমস্যাটি সমাধানের "অপরিবর্তনীয় জিনিসগুলি" পছন্দ করি। একটি আয়তক্ষেত্রের পরিচয় এটির দৈর্ঘ্য এবং প্রস্থ। এটি উপলব্ধি করে যে আপনি যখন কোনও বস্তুর পরিচয় পরিবর্তন করতে চান তখন আপনি যা চান তা একটি নতুন অবজেক্ট। আপনি যদি কোনও পুরানো গ্রাহক হারিয়ে ফেলে এবং একটি নতুন গ্রাহক অর্জন করেন তবে আপনি পুরানো গ্রাহক Customer.Idথেকে ক্ষেত্রটি নতুনটিতে পরিবর্তন করবেন না , আপনি একটি নতুন তৈরি করেন Customer

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


7
লিসকভ একটি জিনিস, এবং স্টোরেজ অন্য বিষয়। বেশিরভাগ বাস্তবায়নে, আয়তক্ষেত্রের উত্তরাধিকার সূত্রে প্রাপ্ত একটি স্কোয়ার উদাহরণের জন্য দুটি মাত্রা সংরক্ষণের জন্য স্থান প্রয়োজন হবে, যদিও কেবল একটি মাত্র প্রয়োজন।
el.pescado

29
পয়েন্টটি চিত্রিত করার জন্য একটি গল্পের উজ্জ্বল ব্যবহার
ররি হান্টার

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

33
@ রয়ইটি .: কেন একটি আয়তক্ষেত্রটি তার অঞ্চলটি সেট করতে হয় তা জানতে হবে? এটি দৈর্ঘ্য এবং প্রস্থ থেকে পুরোপুরি উত্পন্ন একটি সম্পত্তি। এবং আরও বিন্দুতে, এর কোন মাত্রাটি পরিবর্তন করা উচিত - দৈর্ঘ্য, প্রস্থ বা উভয়?
সিএওও

32
@ রয় টি। এটি বলতে খুব সুন্দর যে আপনি সমস্যাটি অন্যরকমভাবে সমাধান করেছেন, তবে বাস্তবতা হ'ল উত্তরাধিকারী পণ্যগুলি বজায় রাখার সময় বিকাশকারীরা প্রতিদিনের ভিত্তিতে যে বাস্তব পরিস্থিতিগুলির মুখোমুখি হন তার বাস্তব উদাহরণ এটি সহজ-সরল হলেও is এমনকি আপনি যদি এই পদ্ধতিটি বাস্তবায়ন করেন, তবে এটি উত্তরাধিকারীদের এলএসপি লঙ্ঘন এবং এইগুলির মতো বাগগুলি প্রবর্তন বন্ধ করবে না। এই কারণেই .NET ফ্রেমওয়ার্কের প্রতিটি শ্রেণি সিল করা হয়।
স্টিফেন

30

যদি আপনার সমস্ত বস্তু পরিবর্তনযোগ্য হয় তবে কোনও সমস্যা নেই। প্রতিটি স্কোয়ারও একটি আয়তক্ষেত্র। একটি আয়তক্ষেত্রের সমস্ত বৈশিষ্ট্যও একটি স্কোয়ারের বৈশিষ্ট্য।

আপনি যখন বস্তুগুলিকে সংশোধন করার ক্ষমতা যুক্ত করেন তখন সমস্যাটি শুরু হয়। অথবা সত্যই - যখন আপনি কেবল সম্পত্তি প্রাপ্তি পড়া না করে অবজেক্টটিতে যুক্তিগুলি পাস করতে শুরু করেন।

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

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

যখন আপনি একটি আয়তক্ষেত্র এবং একটি স্কোয়ার "কী" রাখতে পারেন, আপনি তাদের কাছে কী বার্তা প্রেরণ করতে পারেন সেদিকে নজর দিলে আপনি সম্ভবত দেখতে পাবেন যে কোনও বার্তা আপনি বৈধভাবে কোনও স্কোয়ারে প্রেরণ করতে পারবেন, আপনি একটি আয়তক্ষেত্রেও পাঠাতে পারেন।

এটি সহ-ভেরিয়েন্স বনাম বিপরীতে বৈচিত্রের বিষয়।

একটি উপযুক্ত সাবক্লাসের পদ্ধতি, যেখানে সুপারক্লাস প্রত্যাশিত সমস্ত ক্ষেত্রে উদাহরণ ব্যবহার করা যায়, প্রতিটি পদ্ধতির প্রয়োজন:

  • সুপারক্লাসের কেবলমাত্র মানগুলি প্রত্যাবর্তন করবে - এটি হ'ল, রিটার্নের ধরণটি সুপারক্লাস পদ্ধতির রিটার্ন টাইপের একটি সাব টাইপ হতে হবে। রিটার্ন সহ-বৈকল্পিক।
  • সুপারটাইপ গ্রহণ করবে এমন সমস্ত মান গ্রহণ করুন - অর্থাত্ আর্গুমেন্টগুলি সুপারক্লাস পদ্ধতির যুক্তির ধরণগুলির সুপারটাইপস হতে হবে। যুক্তিগুলি বৈকল্পিক হয়।

সুতরাং, আয়তক্ষেত্র এবং স্কোয়ারে ফিরে যান: স্কয়ারটি আয়তক্ষেত্রের একটি উপক্লাস হতে পারে কিনা তা পুরোপুরি নির্ভর করে যে আয়তক্ষেত্রগুলি কী পদ্ধতিতে রয়েছে তার উপর নির্ভর করে।

যদি আয়তক্ষেত্রের প্রস্থ এবং উচ্চতার জন্য পৃথক সেটটার থাকে তবে স্কোয়ারটি ভাল একটি সাবক্লাস তৈরি করবে না।

তেমনিভাবে, আপনি যদি কিছু পদ্ধতি আর্গুমেন্টগুলিতে যেমন compareTo(Rectangle)আয়তক্ষেত্র এবং compareTo(Square)স্কোয়ারে থাকার ক্ষেত্রে সহ-বৈকল্পিক হন তবে আপনার স্কোয়ারটি আয়তক্ষেত্র হিসাবে ব্যবহার করতে সমস্যা হবে।

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


"আপনার সমস্ত বস্তু অপরিবর্তনীয় হন, সমস্যা নেই" - এই এই প্রশ্নের, যা স্পষ্টভাবে প্রস্থ এবং উচ্চতার জন্য setters উল্লেখ প্রেক্ষাপটে দৃশ্যত অপ্রাসঙ্গিক বিবৃতি
মশা

11
আমি এটি আকর্ষণীয় পেয়েছি, এমনকি যখন এটি "আপাতদৃষ্টিতে অপ্রাসঙ্গিক"
জেসভিন জোসে

14
@gnat আমি যুক্তিযুক্ত এটি প্রাসঙ্গিক কারণ প্রশ্নের দুই ধরণের মধ্যে যখন একটি বৈধ সাব টাইপিং সম্পর্ক থাকে তখনই এর আসল মানটি চিহ্নিত করা হয়। এটি নির্ভর করে কোন ধরণের সুপারটাইপ ঘোষনা করে তার উপর নির্ভর করে, সুতরাং মিউটেটর পদ্ধতিগুলি চলে গেলে সমস্যাটি চলে যায় goes
ডোভাল

1
@ জাগ্রত করুন , সেটারগুলি মিউটরেটর , তাই lrn মূলত বলছে, "এটি করবেন না এবং এটি কোনও সমস্যা নয়।" আমি সাধারণ ধরণের অপরিবর্তনীয়তার সাথে একমত হতে পারি তবে আপনি একটি ভাল বক্তব্য রাখেন: জটিল বস্তুর জন্য সমস্যাটি এত সহজ নয় not
প্যাট্রিক এম

1
এইভাবে বিবেচনা করুন, 'আয়তক্ষেত্র' শ্রেণীর দ্বারা গ্যারান্টিযুক্ত আচরণটি কী? যে আপনি একে অপরের প্রস্থ এবং উচ্চতা INDEPendENT পরিবর্তন করতে পারেন। (যেমন সেটউইথ এবং সেটহাইট) পদ্ধতি। এখন যদি স্কোয়ারটি আয়তক্ষেত্র থেকে উদ্ভূত হয় তবে স্কয়ারটিকে এই আচরণের গ্যারান্টি দিতে হবে। স্কয়ার যেহেতু এই আচরণের গ্যারান্টি দিতে পারে না, এটি একটি খারাপ উত্তরাধিকার। তবে, যদি সেটউইথ / সেটহাইটের পদ্ধতিগুলি আয়তক্ষেত্রের শ্রেণি থেকে সরানো হয়, তবে এরকম আচরণ নেই এবং তাই আপনি আয়তক্ষেত্র থেকে স্কোয়ার শ্রেণি অর্জন করতে পারেন।
নিতিন भिদে

17

এখানে অনেক ভাল উত্তর আছে; বিশেষত স্টিফেনের জবাব কেন প্রতিস্থাপনের নীতি লঙ্ঘন দলগুলির মধ্যে বাস্তব-বিশ্ব দ্বন্দ্বের দিকে পরিচালিত করে তা বোঝাতে একটি ভাল কাজ করে।

আমি ভেবেছিলাম আমি এলএসপির অন্যান্য লঙ্ঘনের রূপক হিসাবে ব্যবহার না করে আয়তক্ষেত্র এবং স্কোয়ারগুলির নির্দিষ্ট সমস্যা সম্পর্কে সংক্ষেপে কথা বলতে পারি।

বর্গক্ষেত্রের একটি বিশেষ-ধরণের আয়তক্ষেত্রের সাথে অতিরিক্ত সমস্যা রয়েছে যা খুব কমই উল্লেখ করা হয় এবং তা হ'ল: আমরা কেন বর্গাকার এবং আয়তক্ষেত্রগুলি দিয়ে থামছি ? যদি আমরা বলতে চাই যে একটি বর্গক্ষেত্রটি একটি বিশেষ ধরণের আয়তক্ষেত্র হয় তবে অবশ্যই আমাদেরও এটি বলতে রাজি হওয়া উচিত:

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

পৃথিবীর সমস্ত সম্পর্ক এখানে কী হওয়া উচিত? শ্রেণি-উত্তরাধিকার ভিত্তিক ভাষা যেমন সি # বা জাভা একাধিক বিভিন্ন ধরণের প্রতিবন্ধকতার সাথে এই ধরণের জটিল সম্পর্কের প্রতিনিধিত্ব করার জন্য ডিজাইন করা হয়নি। সাবটাইটিং সম্পর্কযুক্ত শ্রেণি হিসাবে এই সমস্ত কিছুকে উপস্থাপন করার চেষ্টা না করে কেবল প্রশ্নটি পুরোপুরি এড়ানো সহজ।


3
আকারের অবজেক্টগুলি যদি অপরিবর্তনীয় হয় তবে তার মধ্যে একটি IShapeটাইপ থাকতে পারে যার মধ্যে একটি বাউন্ডিং বাক্স রয়েছে এবং এটি আঁকতে, স্কেল করে এবং সিরিয়ালাইজ করা যায়, এবং একটি IPolygonঅনুপাতের সংখ্যা রিপোর্ট করার পদ্ধতি এবং একটি ফেরত দেওয়ার পদ্ধতি সহ একটি উপ- টাইপ থাকতে পারে IEnumerable<Point>। এক তারপর হতে পারে IQuadrilateralউপপ্রকার যা থেকে আহরিত IPolygon, IRhombusএবং IRectangle, যা থেকে আহরণ করা, এবং ISquareথেকে আহরণ করা IRhombusএবং IRectangle। পরিবর্তনযোগ্যতা উইন্ডোটির বাইরে সবকিছু ছুঁড়ে মারবে, এবং একাধিক উত্তরাধিকার ক্লাসগুলির সাথে কাজ করে না, তবে আমি মনে করি এটি অপরিবর্তনীয় ইন্টারফেসের সাথে ঠিক আছে।
সুপারক্যাট

আমি কার্যকরভাবে এখানে এরিকের সাথে একমত নই (যদিও -1-এর পক্ষে যথেষ্ট নয়)। এই সমস্ত সম্পর্কগুলি (সম্ভবত) প্রাসঙ্গিক, যেমন @ সুপারকার্ট উল্লেখ করেছে; এটি কেবল একটি YAGNI ইস্যু: আপনার প্রয়োজন না হওয়া পর্যন্ত আপনি এটিকে বাস্তবায়ন করবেন না।
মার্ক হার্ট

খুব ভাল উত্তর! উচ্চতর উপায় হতে হবে।
andrew.fox

1
@ মার্কহর্ড - এটি কোনও ইয়াজিএনআই ইস্যু নয়: উত্তরাধিকার-ভিত্তিক শ্রেণিবিন্যাস বর্ণিত শ্রেণীবিন্যাসের মতো আকারযুক্ত, তবে এটি সংজ্ঞায়িত সম্পর্কের গ্যারান্টি হিসাবে এটি লেখা যায় না। সমান দৈর্ঘ্যের প্রান্ত অনুসারে সংজ্ঞায়িত থেকে IRhombusসমস্ত Pointফিরে আসার গ্যারান্টি কীভাবে দেয় ? যেহেতু শুধুমাত্র ইন্টারফেসের প্রয়োগটি গ্যারান্টি দেয় না যে একটি কংক্রিট অবজেক্ট-রম্বস, উত্তরাধিকার উত্তর হতে পারে না। Enumerable<Point>IPolygonIRhombus
এ রাগার

14

গাণিতিক দৃষ্টিকোণ থেকে, একটি বর্গক্ষেত্র একটি আয়তক্ষেত্র হয়। কোনও গণিতবিদ যদি স্কোয়ারটি পরিবর্তন করেন তবে এটি আর বর্গ চুক্তির সাথে মেনে চলেন না, এটি আয়তক্ষেত্রে পরিবর্তিত হয়।

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

এখানে মূল কারণটি হল পরিবর্তনশীলতা । এটি তৈরি হয়ে গেলে কি কোনও আকৃতি পরিবর্তন হতে পারে?

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

  • অপরিবর্তনীয়: যদি একবার নির্মাণের পরে আকারগুলি পরিবর্তন করতে না পারে তবে একটি বর্গক্ষেত্রের অবশ্যই আয়তক্ষেত্র চুক্তিটি সর্বদা পূর্ণ করতে হবে। একটি বর্গক্ষেত্রের আয়তক্ষেত্রের সাথে একটি সম্পর্ক থাকতে পারে।

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


1
This is one of those cases where the real world is not able to be modeled in a computer 100%। কেন এমন? আমরা এখনও একটি বর্গক্ষেত্র এবং একটি আয়তক্ষেত্রের কার্যকরী মডেল রাখতে পারি। এর একমাত্র পরিণতি হ'ল এই দুটি বস্তুর উপর বিমূর্ত করার জন্য আমাদের একটি সহজ নির্মাণের সন্ধান করতে হবে।
সাইমন বার্গোট

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

3
@ স্টিফেন সম্মত। প্রকৃতপক্ষে, তাদের অপরিবর্তনীয় করে তোলা ছোটখাটো সমস্যা বিবেচনা না করেই করণীয় বুদ্ধিমানের কাজ। এগুলিকে পরিবর্তনীয় করার কোনও কারণ নেই - একটি নতুন চৌকো বা আয়তক্ষেত্রটি পরিবর্তন করার চেয়ে কোনও শক্তিশালীকরণের পক্ষে শক্ত, সুতরাং কীটগুলি কীটগুলি খুলে কেন? এখন আপনার এলিয়াসিং / পার্শ্ব প্রতিক্রিয়া সম্পর্কে চিন্তা করার দরকার নেই এবং প্রয়োজনে আপনি এগুলি মানচিত্র / ডিস্টের কী হিসাবে ব্যবহার করতে পারেন। কেউ কেউ বলবে "পারফরম্যান্স", যার জন্য আমি "অকাল অপ্টিমাইজেশন" বলব যতক্ষণ না তারা প্রকৃতপক্ষে পরিমাপ করে এবং প্রমাণ করে না যে হট স্পটটি শেপ কোডটিতে রয়েছে।
ডোভাল

দুঃখিত বন্ধুরা, দেরি হয়ে গেছে এবং আমি উত্তরটি লিখতে গিয়ে ক্লান্ত হয়ে পড়েছিলাম। আমি আসলে কী বলতে চাইছিলাম তা বলার জন্য এটি আবার লিখলাম, যার ক্রুक्सটি হ'ল পরিবর্তনশীলতা।

13

এবং আপনি যে কোনও আয়তক্ষেত্রের প্রত্যাশা করেন সেখানে স্কয়ারটি কেন ব্যবহারযোগ্য হবে?

কারণ এটি সাব-টাইপ হওয়ার অর্থের অংশ (এটিও দেখুন: লিসকভের প্রতিস্থাপন নীতি)। আপনি এটি করতে পারবেন, এটি করতে সক্ষম হতে হবে:

Square s = new Square(5);
Rect r = s;
doSomethingWith(r); // written assuming a Rect, actually calls Square methods

আপনি ওওপি ব্যবহার করার সময় এটি আসলে সর্বদা (কখনও কখনও আরও স্পষ্টভাবে) করতে পারেন।

এবং যদি আমরা স্কয়ারের জন্য সেটউইথ এবং সেটহাইট পদ্ধতিগুলি অতিরিক্ত চালিত করি তবে কেন কোনও সমস্যা হবে?

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


অনেকগুলি ভাষায়, আপনার এমনকি Rect r = s;লাইনের প্রয়োজন নেই , আপনি কেবল পারেন doSomethingWith(s)এবং রানটাইম sকোনও ভার্চুয়াল Squareপদ্ধতিতে সমাধান করতে কোনও কল ব্যবহার করবে ।
প্যাট্রিক এম

1
@ পেট্রিকএম আপনার সাব-টাইপ করে এমন কোনও বুদ্ধিমান ভাষায় এটির দরকার নেই। আমি স্পষ্টভাবে প্রকাশের জন্য সেই লাইনটি অন্তর্ভুক্ত করেছি।

সুতরাং ওভাররাইড setWidthএবং setHeightপ্রস্থ এবং উচ্চতা উভয়ই পরিবর্তন করতে।
ApproachingDarknessFish

@ ভালেকহাল্ফ হার্ট এটি হ'ল বিকল্পটি আমি বিবেচনা করছি।

7
@ ভালেকহাল্ফ হার্ট: লিসকোভ সাবস্টিটিউশন নীতিটি হ'ল লঙ্ঘন যা আপনাকে ঘৃণা করবে এবং দু'বছর পরে একটি অদ্ভুত বাগ খোঁজার চেষ্টা করার জন্য আপনি বেশ কয়েকটা নিদ্রাহীন রাত কাটাবেন যখন আপনি ভুলে গেছেন যে কোডটি কীভাবে কাজ করা উচিত ছিল।
জানু হুডেক

9

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

আয়তক্ষেত্র-স্কোয়ার সমস্যা লিসকোভকে পরিচয় করানোর পক্ষে খুব ভাল উপায় নয়। এটি একটি বিস্তৃত নীতিটি একটি উদাহরণ ব্যবহার করে ব্যাখ্যা করার চেষ্টা করে যা প্রকৃতপক্ষে খুব সূক্ষ্ম, এবং সমস্ত গণিতের সবচেয়ে সাধারণ স্বজ্ঞাত সংজ্ঞাগুলির মধ্যে একটির উপরে চলে আসে। কেউ কেউ এ কারণে এলিপস-সার্কেল সমস্যা হিসাবে ডাকে তবে এটি যতদূর এগিয়ে যায় কেবল সামান্য ভাল better সমান্তরালগ্রাম-আয়তক্ষেত্রের সমস্যাটিকে আমি যা বলি তা ব্যবহার করে একটি সামান্য পদক্ষেপ ফিরে নেওয়া একটি আরও ভাল পদ্ধতির। এটি জিনিসগুলি বুঝতে খুব সহজ করে তোলে।

একটি সমান্তরাল দুটি সমান্তরাল পক্ষের দুটি চতুর্ভুজযুক্ত। এটিতে দুটি জোড়া সংযুক্ত কোণ রয়েছে। এই লাইনগুলির সাথে একটি সমান্তরাল বস্তুটি কল্পনা করা কঠিন নয়:

class Parallelogram {
    function getSideA() {};
    function getSideB() {};
    function getAngleA() {};
    function getAngleB() {};
    function setSideA(newLength) {};
    function setSideB(newLength) {};
    function setAngleA(newAngle) {};
    function setAngleB(newAngle) {};
}

আয়তক্ষেত্রটি ভাবার একটি সাধারণ উপায় হ'ল ডান কোণগুলির সাথে সমান্তরাল হিসাবে। প্রথম নজরে, এটি সমান্তরালগ্রাম থেকে উত্তরাধিকার সূত্রে রেক্টাঙ্গেলকে উত্তম প্রার্থী হিসাবে মনে হতে পারে , যাতে আপনি সেই সমস্ত মুখরোচক কোডটি পুনরায় ব্যবহার করতে পারেন। যাহোক:

class Rectangle extends Parallelogram {
    function getSideA() {};
    function getSideB() {};
    function getAngleA() {};
    function getAngleB() {};
    function setSideA(newLength) {};
    function setSideB(newLength) {};

    /* BUG: Liskov violations ahead */
    function setAngleA(newAngle) {};
    function setAngleB(newAngle) {};
}

কেন এই দুটি ফাংশন আয়তক্ষেত্রে বাগ প্রবর্তন করে? সমস্যাটি হ'ল আপনি একটি আয়তক্ষেত্রগুলিতে কোণগুলি পরিবর্তন করতে পারবেন না : এগুলি সর্বদা 90 ডিগ্রি হিসাবে সংজ্ঞায়িত করা হয় এবং সুতরাং এই ইন্টারফেসটি সমান্তরালাম থেকে প্রাপ্ত আয়তক্ষেত্রের পক্ষে আসলে কাজ করে না। যদি আমি এমন একটি আয়তক্ষেত্রকে এমন কোনও কোডে অদলবদ্ব করে যা কোনও সমান্তরালগ্রাম প্রত্যাশা করে এবং সেই কোডটি কোণ পরিবর্তন করার চেষ্টা করে তবে অবশ্যই বাগগুলি থাকবে। আমরা সাবক্লাসে লিখিতযোগ্য এমন কিছু নিয়েছি এবং এটি কেবল পঠনযোগ্য করে তুলেছি এবং এটি লিসকোভ লঙ্ঘন।

এখন, এটি স্কোয়ার এবং আয়তক্ষেত্রগুলিতে কীভাবে এটি প্রয়োগ হয়?

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

class Square extends Rectangle {
    function getSideA() {};
    function getSideB() {};
    function getAngleA() {};
    function getAngleB() {};

    /* BUG: More Liskov violations */
    function setSideA(newLength) {};
    function setSideB(newLength) {};

    /* Liskov violations inherited from Rectangle */
    function setAngleA(newAngle) {};
    function setAngleB(newAngle) {};
}

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

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


8

সাবটাইপিং আচরণ সম্পর্কে।

প্রকারের Bউপ-টাইপ হওয়ার জন্য A, টাইপটিকে Aএকই শব্দার্থবিজ্ঞানের ("আচরণ" এর জন্য অভিনব আলাপ) সমর্থন করে এমন প্রতিটি ক্রিয়াকলাপ অবশ্যই সমর্থন করে । প্রতিটি বি একটি এ কাজ করে না এমন যুক্তি ব্যবহার করে - আচরণের সামঞ্জস্যের চূড়ান্ত বক্তব্য রয়েছে। বেশিরভাগ সময় "বি" এক ধরণের এ "" বি এর সাথে এ এর ​​মতো আচরণ করে "" এর ওভারল্যাপ করে তবে সবসময় হয় না

একটি উদাহরণ:

আসল সংখ্যাগুলির সেট বিবেচনা করুন। কোন ভাষায়, আমরা তাদের কাজকর্মকে সাহায্য করতে আশা করতে পারেন +, -, *, এবং /। এখন ইতিবাচক পূর্ণসংখ্যার সেট বিবেচনা করুন ({1, 2, 3, ...})। স্পষ্টতই, প্রতিটি ধনাত্মক পূর্ণসংখ্যাও একটি আসল সংখ্যা। তবে ধনাত্মক পূর্ণসংখ্যার ধরণটি কি প্রকৃত সংখ্যার ধরণের একটি উপপ্রকার? আসুন চারটি ক্রিয়াকলাপটি দেখুন এবং দেখুন যে ইতিবাচক পূর্ণসংখ্যাগুলি আসল সংখ্যার মতো একই আচরণ করে:

  • +: আমরা সমস্যা ছাড়াই ধনাত্মক পূর্ণসংখ্যার যোগ করতে পারি।
  • -: ধনাত্মক পূর্ণসংখ্যার সমস্ত বিয়োগের ফলে ইতিবাচক পূর্ণসংখ্যার ফলাফল হয় না। যেমন 3 - 5
  • *: আমরা সমস্যা ছাড়াই ধনাত্মক পূর্ণসংখ্যার গুণ করতে পারি।
  • /: আমরা সবসময় ধনাত্মক পূর্ণসংখ্যাগুলি ভাগ করতে পারি না এবং ধনাত্মক পূর্ণসংখ্যা পেতে পারি। যেমন 5 / 3

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

অবশ্যই, আপনি +32-বিট ইন্টের জন্য সংজ্ঞা দিতে পারেন যাতে ফলস্বরূপ একটি -৪-বিট পূর্ণসংখ্যা হয় তবে প্রতিবার আপনি দুটি 32-বিট সংখ্যা যুক্ত করার সময় আপনাকে 64 বিট স্থান সংরক্ষণ করতে হবে। আপনার মেমরির প্রয়োজনের উপর নির্ভর করে এটি আপনার কাছে গ্রহণযোগ্য বা নাও হতে পারে।

কেন এই ব্যাপার?

প্রোগ্রামগুলি সঠিক হওয়া গুরুত্বপূর্ণ important এটি কোনও প্রোগ্রামের জন্য তর্কতিত্বে সবচেয়ে গুরুত্বপূর্ণ সম্পত্তি। যদি কোনও প্রোগ্রাম কোনও প্রকারের জন্য সঠিক হয় A, তবে সেই প্রোগ্রামটির গ্যারান্টি দেওয়ার একমাত্র উপায় Bহ'ল যদি প্রতিটি Bউপাচারের মতো আচরণ করা হয় A

সুতরাং আপনার ধরণ রয়েছে Rectanglesযার স্পেসিফিকেশন বলছে এর পক্ষগুলি স্বাধীনভাবে পরিবর্তন করা যেতে পারে। আপনি কিছু প্রোগ্রাম লিখেছেন যা ব্যবহার করে Rectanglesএবং অনুমান করে যে প্রয়োগটি স্পেসিফিকেশন অনুসরণ করে। তারপরে আপনি একটি উপ-টাইপ চালু করেছিলেন Squareযার পক্ষগুলি স্বাধীনভাবে আকার পরিবর্তন করতে পারে না । ফলস্বরূপ, বেশিরভাগ প্রোগ্রাম যা আয়তক্ষেত্রগুলির আকার পরিবর্তন করে এখন ভুল হবে।


6

একটি স্কোয়ার যদি আয়তক্ষেত্রের এক ধরণের হয় তবে কেন কোনও আয়তক্ষেত্র থেকে স্কয়ার উত্তরাধিকারী হয় না? বা কেন এটি একটি খারাপ নকশা?

প্রথম জিনিসগুলি প্রথমে নিজেকে জিজ্ঞাসা করুন যে আপনি কেন বর্গাকার একটি আয়তক্ষেত্র বলে মনে করেন।

অবশ্যই বেশিরভাগ লোক প্রাথমিক বিদ্যালয়ে শিখেছিল এবং এটি সুস্পষ্ট বলে মনে হবে। একটি আয়তক্ষেত্রটি 90 টি ডিগ্রি কোণ সহ 4 পার্শ্বযুক্ত আকার এবং একটি বর্গক্ষেত্র সমস্ত বৈশিষ্ট্য পূর্ণ করে। সুতরাং একটি বর্গ একটি আয়তক্ষেত্র নয়?

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

সুতরাং আপনি এমনকি বলার আগে "একটি বর্গক্ষেত্র একটি ধরণের আয়তক্ষেত্র" আপনাকে প্রথমে নিজেকে জিজ্ঞাসা করতে হবে, এটি কি আমার যত্ন নেওয়ার মানদণ্ডের উপর ভিত্তি করে ?

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

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

এই প্রসঙ্গে একটি বর্গটি অবশ্যই স্পষ্টভাবে আয়তক্ষেত্র নয় , কারণ যে নিয়মগুলি স্কোয়ারটি কীভাবে পরিবর্তন করা যায় তা আয়তক্ষেত্রের মতো নয়। সুতরাং তারা জিনিস একই ধরণের নয়।

কোন ক্ষেত্রে তাদের যেমন মডেল করবেন না। আপনি কেন হবে? এটি আপনাকে অপ্রয়োজনীয় বাধা ব্যতীত আর কিছুই লাভ করে না।

এটি কেবলমাত্র ব্যবহারযোগ্য হবে যদি আমরা স্কোয়ার অবজেক্টটি তৈরি করি এবং যদি আমরা স্কয়ারের জন্য সেটউইথ এবং সেটহাইটের পদ্ধতিগুলি ওভাররাইড করি তবে কেন কোনও সমস্যা হবে?

যদি আপনি তা করেন তবে আপনি ব্যবহারিকভাবে কোডে উল্লেখ করছেন যে তারা একই জিনিস নয়। আপনার কোডটি বলবে কোনও বর্গক্ষেত্র এইভাবে আচরণ করে এবং একটি আয়তক্ষেত্র সেভাবে আচরণ করে তবে তারা এখনও একই।

আপনি যে প্রসঙ্গে যত্নশীল সেগুলিতে সেগুলি পরিষ্কারভাবে একই নয় কারণ আপনি কেবল দুটি পৃথক আচরণের সংজ্ঞা দিয়েছেন। তাহলে কেন সেগুলি একই রকম ভান করে যদি সেগুলি যদি আপনি বিবেচনা করেন না এমন প্রসঙ্গে যদি একইরকম হয় তবে?

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

এই প্রশ্নের উত্তরের অনেকগুলি উপ-টাইপিংয়ের উপর দৃষ্টি নিবদ্ধ করে যা গ্রুপিং আচরণ সম্পর্কে রয়েছে 'তাদের বিধিগুলির কারণ

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


যদি ভেরিয়েবলের মানগুলিRectangle কেবলমাত্র মানগুলির প্রতিনিধিত্ব করতে ব্যবহৃত হয় তবে কোনও শ্রেণীর Squareপক্ষে Rectangleতার চুক্তিটি উত্তীর্ণ হওয়া এবং সম্পূর্ণরূপে মেনে চলা সম্ভব । দুর্ভাগ্যক্রমে, অনেক ভাষা ভেরিয়েবলগুলির মধ্যে কোনও পার্থক্য করে না যা মানগুলিকে আবদ্ধ করে এবং সত্তা সনাক্ত করে এমনগুলির মধ্যে।
সুপারক্যাট

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

অথবা এটি অন্য কোনও উপায়ে রাখুন: চামচটি বাঁকানোর চেষ্টা করবেন না। সেটা অসম্ভব. পরিবর্তে কেবল সত্য উপলব্ধি করার চেষ্টা করুন, কোনও চামচ নেই। :-)
করম্যাক মুলহাল 12'14

1
অপরিবর্তনীয় Squareধরণের যা অপরিবর্তনীয় টাইপ থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হওয়াই কার্যকর Rectnagleহতে পারে যদি এমন কিছু ধরণের অপারেশন থাকে যা কেবল স্কোয়ারের উপর দিয়েই করা যায়। ধারণার একটি বাস্তব উদাহরণ হিসাবে, একটি ReadableMatrixপ্রকার [বেস টাইপ একটি আয়তক্ষেত্রাকার অ্যারে বিবেচনা করুন যা বিচ্ছিন্নভাবে সহ বিভিন্ন উপায়ে সংরক্ষণ করা যেতে পারে] এবং একটি ComputeDeterminantপদ্ধতি বিবেচনা করুন। এটা জ্ঞান আছে পারে ComputeDeterminantশুধুমাত্র একটি সঙ্গে কাজ ReadableSquareMatrixযে ধরনের থেকে প্রাপ্ত হচ্ছে ReadableMatrix, যা আমি একটি একটি উদাহরণ হতে বিবেচনা করবে Squareএকটি থেকে আহরিত Rectangle
সুপারক্যাট

5

একটি স্কোয়ার যদি আয়তক্ষেত্রের এক ধরণের হয় তবে কেন কোনও আয়তক্ষেত্র থেকে স্কয়ার উত্তরাধিকারী হয় না?

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

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

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

  • স্কোয়ারটিকে বেস ক্লাস হিসাবে widthপরামিতি এবং resize(double factor)প্রদত্ত ফ্যাক্টর দ্বারা প্রস্থের আকার পরিবর্তন করে ব্যাখ্যা করুন
  • আয়তক্ষেত্র শ্রেণি এবং স্কোয়ারের সাবক্লাসটি সংজ্ঞায়িত করুন, কারণ এটি আরও একটি বৈশিষ্ট্য যুক্ত করে heightএবং এর resizeকার্যকারিতাটি ওভাররাইড করে , যা কল দেয় super.resizeএবং তারপরে প্রদত্ত ফ্যাক্টরের দ্বারা উচ্চতাকে আকার দেয়

প্রোগ্রামিং দৃষ্টিকোণ থেকে স্কোয়ারে কিছুই নেই, যা আয়তক্ষেত্রটি নেই। আয়তক্ষেত্রের সাবক্লাস হিসাবে স্কোয়ার তৈরি করার কোনও ধারণা নেই।


+1 কেবল কারণ একটি স্কোয়ারটি গণিতে বিশেষ ধরণের রেক্ট, এর অর্থ এটি ওও তেমন নয়।
লভিস 16

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

4

LSP দ্বারা কারণ, দুই আর অগ্রাহ্য মধ্যে উত্তরাধিকার সম্পর্ক তৈরি setWidthএবং setHeightতা নিশ্চিত করার জন্য বর্গ একই প্রবর্তন বিভ্রান্তিকর এবং অ স্বজ্ঞাত আচরণ উভয় হিসাবে হয়েছে। আমাদের একটি কোড রয়েছে বলে দিন:

Rectangle r = createRectangle(); // create rectangle or square here
r.setWidth(10);
r.setHeight(20);
print(r.getWidth()); // expect to print 10
print(r.getHeight()); // expect to print 20

তবে যদি পদ্ধতিটি createRectangleফিরে আসে Square, কারণ এটি Squareউত্তরাধিকার সূত্রে প্রাপ্ত হওয়ার জন্য ধন্যবাদ Rectange। তারপরে প্রত্যাশাগুলি ভেঙে যায়। এখানে, এই কোড সহ আমরা প্রস্থ বা উচ্চতা নির্ধারণের ফলে কেবলমাত্র যথাক্রমে প্রস্থ বা উচ্চতায় পরিবর্তন আনতে পারি। OOP এর মুল বক্তব্যটি হ'ল আপনি যখন সুপারক্লাসের সাথে কাজ করেন তখন এর অধীনে যে কোনও সাবক্লাসের আপনার শূন্য জ্ঞান থাকে। এবং যদি সাবক্লাস আচরণটি পরিবর্তন করে যাতে এটি সুপারক্লাস সম্পর্কে আমাদের প্রত্যাশার বিপরীতে যায়, তবে বাগগুলি হওয়ার সম্ভাবনা বেশি। এবং এই ধরণের বাগগুলি ডিবাগ করা এবং ঠিক করা উভয়ই শক্ত।

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


2

এলএসপি যা বলেছে তা হ'ল উত্তরাধিকার সূত্রে প্রাপ্ত কিছু Rectangleঅবশ্যই একটি Rectangle। অর্থাৎ এটি যা কিছু Rectangleকরে তা করা উচিত ।

সম্ভবত এর জন্য ডকুমেন্টেশনটি Rectangleলিখে দেওয়া হয়েছে যে কোনও Rectangleনামের আচরণটি নীচে রয়েছে r:

r.setWidth(10);
r.setHeight(20);
print(r.getWidth());  // prints 10

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

এখন, ডকুমেন্টেশনগুলি এমনভাবে লেখা সম্ভব হবে Rectangleযাতে এটি বোঝায় না যে উপরের কোডটি 10 ​​প্রিন্ট করে, সেই ক্ষেত্রে সম্ভবত আপনার Squareহতে পারে একটি Rectangle। আপনি ডকুমেন্টেশন দেখতে পাচ্ছেন যা এমন কিছু বলে যে "এটি এক্স করে। যদি তা হয় তবে ক্লাস থেকে ইন্টারফেস বের করার এবং ইন্টারফেসটি কী গ্যারান্টি দেয় এবং এর সাথে ক্লাস কী গ্যারান্টি দেয় তার মধ্যে পার্থক্য করার জন্য আপনার কাছে একটি ভাল মামলা রয়েছে। কিন্তু লোকেরা যখন বলে যে "একটি পরিবর্তনীয় বর্গক্ষেত্র কোনও পরিবর্তনীয় আয়তক্ষেত্র নয়, যখন একটি পরিবর্তনীয় বর্গক্ষেত্র একটি পরিবর্তনযোগ্য আয়তক্ষেত্র", তারা মূলত ধরে নিচ্ছে যে উপরেরটি প্রকৃতপক্ষে একটি পরিবর্তনীয় আয়তক্ষেত্রের যুক্তিসঙ্গত সংজ্ঞাটির অংশ।


এই নিছক একটি ব্যাখ্যা পয়েন্ট পুনরাবৃত্তি বলে মনে হয় উত্তর, পোস্ট 5 ঘন্টা আগে
মশা

@ গ্যাनेट: আপনি কি আমাকে এই উত্তরটি প্রায় এই বংশবৃদ্ধির নিচে সম্পাদনা করতে পছন্দ করবেন? ;-) আমি মনে করি না যে অন্যান্য উত্তরদাতারা সম্ভবত উত্তরটি মনে করেন যে প্রশ্নের উত্তর দেওয়া প্রয়োজন এবং আমার মনে হয় না এমন পয়েন্টগুলি সরিয়ে না দিয়ে আমি পারব।
স্টিভ জেসপ 16


1

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

যাইহোক, দেখা যাচ্ছে যে এই নীতিটি হয় বেশিরভাগ কোডের অবাস্তব / অনুপযুক্ত, বা সত্যই অসম্পূর্ণ (অসম্পূর্ণ ক্ষেত্রে) অসম্ভব! বর্গ-আয়তক্ষেত্র সমস্যা বা বৃত্ত-উপবৃত্ত সমস্যা ( http://en.wikedia.org/wiki/Circle-ellipse_problem ) হিসাবে পরিচিত এই সমস্যাটি পূরণ করা কতটা কঠিন তার একটি বিখ্যাত উদাহরণ।

মনে রাখবেন যে আমরা আরও-বেশি পর্যবেক্ষণমূলক-সমতুল্য স্কোয়ার এবং আয়তক্ষেত্রগুলি প্রয়োগ করতে পারি , তবে কেবলমাত্র পার্থক্যটি অকেজো না হওয়া পর্যন্ত কেবল আরও বেশি কার্যকারিতা ছুঁড়ে ফেলে।

উদাহরণ হিসাবে, দেখুন http://okmij.org/ftp/Comptation/Subtyping/

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