আমি কীভাবে একটি ইন্টারফেস ডিজাইন করব যাতে এটি স্পষ্ট হয় যে কোন বৈশিষ্ট্য তাদের মান পরিবর্তন করতে পারে এবং কোনটি স্থির থাকবে?

12

.NET বৈশিষ্ট্য সংক্রান্ত আমার একটি ডিজাইনের সমস্যা হচ্ছে।

interface IX
{
    Guid Id { get; }
    bool IsInvalidated { get; }
    void Invalidate();
}

সমস্যা:

এই ইন্টারফেসে দুটি পঠনযোগ্য বৈশিষ্ট্য রয়েছে Idএবং IsInvalidated। এগুলি যে কেবলমাত্র পঠনযোগ্য তা কেবল তাদের গ্যারান্টিই নয় যে তাদের মানগুলি স্থির থাকবে।

আসুন আমরা বলি যে এটি আমার স্পষ্ট করে দেওয়ার উদ্দেশ্য ছিল যে…

Id যখন একটি ধ্রুবক মান উপস্থাপন করে (যা সম্ভবত নিরাপদে ক্যাশে করা যেতে পারে)
IsInvalidatedকোনও IXবস্তুর জীবদ্দশায় এর মান পরিবর্তিত হতে পারে (এবং তাই ক্যাশে করা উচিত নয়)।

কীভাবে আমি interface IXচুক্তিটি যথেষ্ট পরিমাণে সুস্পষ্ট করতে সংশোধন করতে পারি ?

একটি সমাধানে আমার নিজের তিনটি প্রচেষ্টা:

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

এই যুক্তিটি কেবলমাত্র সেই ক্ষেত্রে ধারণ করে যেখানে পদ্ধতি এবং সম্পত্তি একইরূপে নামকরণ করা হয়।
একটি ইভেন্টের সাথে এই ইন্টারফেসটি বৃদ্ধি করুন IsInvalidatedChanged:
```
bool IsInvalidated { get; }
event EventHandler IsInvalidatedChanged;
```
কোনও …Changedইভেন্টের উপস্থিতি IsInvalidatedজানিয়েছে যে এই সম্পত্তিটি তার মান পরিবর্তন করতে পারে এবং অনুরূপ ইভেন্টের অনুপস্থিতি Idএকটি প্রতিশ্রুতি দেয় যে সম্পত্তি তার মান পরিবর্তন করবে না।

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

নিম্নলিখিত পরিস্থিতিতে কোনও সম্পত্তি পরিবর্তে কোনও পদ্ধতি ব্যবহার করুন। […] পরামিতিগুলি পরিবর্তিত না হলেও, অপারেশন প্রতিবার যখন এটি বলা হয় তখন ভিন্ন ফলাফল দেয়।

আমি কি ধরণের উত্তর আশা করি?

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

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

c# design .net properties

— stakx
সূত্র

না IsInvalidatedপ্রয়োজন private set?

— জেমস

2

@ জেমস: অগত্যা, ইন্টারফেসের ঘোষণায় বা বাস্তবায়নের ক্ষেত্রেও

class Foo : IFoo { private bool isInvalidated; public bool IsInvalidated { get { return isInvalidated; } } public void Invalidate() { isInvalidated = true; } }

— অগত্যা নয়

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

— সোভিক

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

— যাইহোক

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

— প্রস্কর

2

আমি 1 এবং 2 এর উপরে 3 এর চেয়ে বেশি সমাধান পছন্দ করব।

সমাধান 1 এর সাথে আমার সমস্যাটি হ'ল : কোনও Invalidateপদ্ধতি না থাকলে কী হয় ? IsValidপ্রত্যাবর্তনকৃত একটি সম্পত্তি সহ একটি ইন্টারফেস ধরে নিন DateTime.Now > MyExpirationDate; আপনার SetInvalidএখানে একটি স্পষ্ট পদ্ধতি প্রয়োজন হবে না । যদি কোনও পদ্ধতি একাধিক বৈশিষ্ট্যকে প্রভাবিত করে? সঙ্গে একটি সংযোগ টাইপ ধরে IsOpenএবং IsConnectedবৈশিষ্ট্যাবলী - উভয় দ্বারা প্রভাবিত হয় Closeপদ্ধতি।

সমাধান 2 : যদি ইভেন্টটির একমাত্র পয়েন্টটি বিকাশকারীদের অবহিত করা হয় যে অনুরূপ নামযুক্ত সম্পত্তি প্রতিটি কলটিতে বিভিন্ন মান ফিরে আসতে পারে তবে আমি এর বিরুদ্ধে দৃ strongly়ভাবে পরামর্শ দেব। আপনার ইন্টারফেসগুলি সংক্ষিপ্ত এবং পরিষ্কার রাখা উচিত; তদ্ব্যতীত, সমস্ত বাস্তবায়ন আপনার জন্য সেই ইভেন্টটিকে চালিত করতে সক্ষম হবে না। আমি উপর IsValidথেকে আমার উদাহরণটি আবার ব্যবহার করব : আপনি একটি টাইমার প্রয়োগ করতে হবে এবং আপনি পৌঁছানোর পরে একটি ইভেন্ট নিক্ষেপ করতে হবে MyExpirationDate। সর্বোপরি, যদি সেই ইভেন্টটি আপনার সর্বজনীন ইন্টারফেসের অংশ হয় তবে ইন্টারফেসের ব্যবহারকারীরা সেই ইভেন্টটি কাজ করবে বলে আশা করবে।

এই সমাধান সম্পর্কে বলা হচ্ছে: সেগুলি খারাপ নয় n't কোনও পদ্ধতির উপস্থিতি বা ইভেন্টের উপস্থিতি ইঙ্গিত দেয় যে একই নামযুক্ত সম্পত্তি প্রতিটি কলটিতে বিভিন্ন মান ফেরত দিতে পারে। আমি যা বলছি তা হ'ল তারা একাই সর্বদা এই অর্থটি জানাতে যথেষ্ট নয়।

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

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

সুতরাং আমার পরামর্শ হবে:

সমাধানটি 3 একটি সম্মেলন ঘোষণা করুন এবং অবিচ্ছিন্নভাবে এটি অনুসরণ করুন। সম্পত্তির ডকুমেন্টেশনে এটি স্পষ্ট করুন যে কোনও সম্পত্তির পরিবর্তনশীল মান রয়েছে কি না। সাধারণ বৈশিষ্ট্যের সাথে কাজ করা বিকাশকারীরা সঠিকভাবে তাদের অ-পরিবর্তনযোগ্য হিসাবে ধরে নেবে (অর্থাত্‍ যখন কেবলমাত্র অবজেক্টের স্থিতি সংশোধন করা হবে তখন পরিবর্তন হবে)। একটি পদ্ধতি যে এটা মনে একটি সম্পত্তি হতে পারে সম্মুখীন ডেভেলপারগণ ( Count(), Length(), IsOpen()) তোমরা জেনে রাখ someting এর উপর যাচ্ছে এবং (আশা) বুঝতে কি ঠিক পদ্ধতি আছে এবং কিভাবে এটা আচরণ করবে পদ্ধতি ডক্স পড়ুন।

— Enzi
সূত্র

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

— stakx

8

চতুর্থ সমাধান রয়েছে: ডকুমেন্টেশনের উপর নির্ভর করুন ।

আপনি কীভাবে জানবেন যে stringশ্রেণি অপরিবর্তনীয়? আপনি কেবল তা জানেন, কারণ আপনি এমএসডিএন ডকুমেন্টেশন পড়েছেন। StringBuilderঅন্যদিকে, পরিবর্তনযোগ্য, কারণ, আবারও ডকুমেন্টেশন আপনাকে এটি বলে।

/// <summary>
/// Represents an index of an element stored in the database.
/// </summary>
private interface IX
{
    /// <summary>
    /// Gets the immutable globally unique identifier of the index, the identifier being
    /// assigned by the database when the index is created.
    /// </summary>
    Guid Id { get; }

    /// <summary>
    /// Gets a value indicating whether the index is invalidated, which means that the
    /// indexed element is no longer valid and should be reloaded from the database. The
    /// index can be invalidated by calling the <see cref="Invalidate()" /> method.
    /// </summary>
    bool IsInvalidated { get; }

    /// <summary>
    /// Invalidates the index, without forcing the indexed element to be reloaded from the
    /// database.
    /// </summary>
    void Invalidate();
}

আপনার তৃতীয় সমাধানটি খারাপ নয়, তবে .NET ফ্রেমওয়ার্ক এটি অনুসরণ করে না । উদাহরণ স্বরূপ:

StringBuilder.Length
DateTime.Now

বৈশিষ্ট্যগুলি হ'ল তবে প্রতিবার এগুলি স্থির থাকার আশা করবেন না।

.NET ফ্রেমওয়ার্কের মধ্যে যা ধারাবাহিকভাবে ব্যবহৃত হয় তা হ'ল:

IEnumerable<T>.Count()

একটি পদ্ধতি, যখন:

IList<T>.Length

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

ক্লাসগুলির সাথে, কেবল কোডটি দেখে পরিষ্কার বোঝা যায় যে কোনও জিনিসের মান বস্তুর জীবদ্দশায় পরিবর্তিত হবে না। এই ক্ষেত্রে,

public class Product
{
    private readonly int price;

    public Product(int price)
    {
        this.price = price;
    }

    public int Price
    {
        get
        {
            return this.price;
        }
    }
}

পরিষ্কার: দাম একই থাকবে।

দুঃখের বিষয়, আপনি কোনও ইন্টারফেসে একই প্যাটার্নটি প্রয়োগ করতে পারবেন না এবং সি # এর ক্ষেত্রে যথেষ্ট পরিমাণে মতামত প্রকাশ না করে, ফাঁকটি বন্ধ করতে ডকুমেন্টেশন (এক্সএমএল ডকুমেন্টেশন এবং ইউএমএল ডায়াগ্রাম সহ) ব্যবহার করা উচিত।

— আরসেনি মরজেনকো
সূত্র

এমনকি "কোনও অতিরিক্ত কাজ নয়" নির্দেশিকা একেবারে ধারাবাহিকভাবে ব্যবহৃত হয় না। উদাহরণস্বরূপ, Lazy<T>.Valueগণনা করতে খুব দীর্ঘ সময় লাগতে পারে (যখন এটি প্রথমবার ব্যবহার করা হয়)।

— এসভিিক

1

আমার মতে, .NET কাঠামো সমাধানের সম্মেলনটি অনুসরণ করে কিনা তা বিবেচ্য নয় 3 আমি আশা করি বিকাশকারীরা বাড়ির ধরণের বা ফ্রেমওয়ার্কের সাথে কাজ করছেন কিনা তা জানতে যথেষ্ট স্মার্ট থাকবেন be যে দেবগণ জানেন না যে দস্তাবেজগুলি পড়েন না এবং এইভাবে 4 সমাধান পান না সেগুলিও সহায়তা করবে না। যদি সমাধান 3 কোনও সংস্থা / দলীয় কনভেনশন হিসাবে প্রয়োগ করা হয়, তবে আমি বিশ্বাস করি যে অন্যান্য এপিআইগুলিও এটি অনুসরণ করে বা না নেয় তা বিবেচ্য নয় (যদিও এটি অবশ্যই খুব প্রশংসা হবে)।

— enzi

4

আমার 2 সেন্ট:

বিকল্প 3: একটি নন-সি # -er হিসাবে, এটি কোনও ক্লু খুব বেশি হবে না; তবে, আপনি যে উদ্ধৃতিটি নিয়ে এসেছেন তা বিচার করে, দক্ষ সি # প্রোগ্রামারদের কাছে এটি পরিষ্কার হওয়া উচিত যে এর অর্থ কিছু। আপনার এখনও এই সম্পর্কে ডক্স যুক্ত করা উচিত।

বিকল্প 2: আপনি পরিবর্তন করতে পারে এমন প্রতিটি জিনিসে ইভেন্ট যুক্ত করার পরিকল্পনা না করলে সেখানে যাবেন না।

অন্যান্য অপশন:

ইন্টারফেসের IXMutable নামকরণ, সুতরাং এটি স্পষ্ট যে এটি তার অবস্থার পরিবর্তন করতে পারে। আপনার উদাহরণের একমাত্র অপরিবর্তনীয় মান হ'ল idযা সাধারণত পরিবর্তনীয় বস্তুগুলিতেও অপরিবর্তনীয় বলে ধরে নেওয়া হয়।
এর উল্লেখ নেই। ইন্টারফেসগুলি আচরণের বর্ণনা দেওয়ার মতো ততটা ভাল নয় যেমন আমরা তাদের চাই; আংশিকভাবে, এর কারণ এই যে ভাষাটি আপনাকে "এই পদ্ধতিটি একটি নির্দিষ্ট বস্তুর জন্য সর্বদা একই মানটি ফিরিয়ে আনবে" বা "x <0 টি যুক্তি দিয়ে এই পদ্ধতিটি কল করা একটি ব্যতিক্রম ছড়িয়ে দেবে" এর মতো জিনিসগুলিকে বর্ণনা করতে দেয় না that's
ভাষা সম্প্রসারণ এবং কনস্ট্রাক্টস সম্পর্কে আরও সুনির্দিষ্ট তথ্য সরবরাহ করার একটি ব্যবস্থা আছে তা বাদে - টিকা / বৈশিষ্ট্য । তাদের মাঝে মাঝে কিছু কাজের প্রয়োজন হয়, তবে আপনাকে আপনার পদ্ধতিগুলি সম্পর্কে নির্বিচারে জটিল জিনিস নির্দিষ্ট করার অনুমতি দেয়। একটি টীকা সন্ধান করুন বা আবিষ্কার করুন যা বলছে "এই পদ্ধতির / সম্পত্তির মান কোনও সামগ্রীর আজীবন পরিবর্তিত হতে পারে" এবং এটিকে পদ্ধতিতে যুক্ত করে। এটি প্রয়োগ করার পদ্ধতিগুলি "উত্তরাধিকারসূত্রে" পাওয়ার জন্য আপনার কিছু কৌশল খেলতে হবে এবং ব্যবহারকারীরা সেই টীকাটির জন্য ডকটি পড়তে পারে তবে এটি এমন একটি সরঞ্জাম যা আপনাকে ইঙ্গিত করার পরিবর্তে ঠিক কী বলতে চাইবে তা বলতে দেয় এটি এ।

— আভিভ
সূত্র

3

আর একটি বিকল্প হ'ল ইন্টারফেসটি বিভক্ত করা: ধরে নেওয়া যে Invalidate()প্রতিটি অনুরোধ আহ্বান করার পরে IsInvalidatedএকই মানটি ফিরে আসবে true, IsInvalidatedএকই অংশটির জন্য অনুরোধ করার কোনও কারণ নেই বলে মনে হচ্ছে Invalidate()।

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

interface Invalidatable
{
    bool IsInvalidated { get; }
}

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

[Immutable]
interface IX
{
    Guid Id { get; }
    void Invalidate();
}

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

— proskor
সূত্র

বুদ্ধিটা খারাপ না! তবে, আমি যুক্তি দিয়ে বলব যে কোনও ইন্টারফেসটিকে [Immutable]ততক্ষণ চিহ্নিত করা ভুল হবে যতক্ষণ না এটি এমন পদ্ধতিগুলিকে অন্তর্ভুক্ত করে যার একমাত্র উদ্দেশ্য একটি রূপান্তর ঘটানো। আমি Invalidate()পদ্ধতিটি Invalidatableইন্টারফেসে স্থানান্তরিত করব ।

— stakx

1

@stakx- এর সাথে আমি একমত নই :) আমি মনে করি আপনি অপরিবর্তনীয়তা এবং বিশুদ্ধতা (পার্শ্ব প্রতিক্রিয়া অনুপস্থিতি) ধারণাটি গুলিয়ে ফেলেন । আসলে, প্রস্তাবিত ইন্টারফেস IX এর দৃষ্টিকোণ থেকে, কোনও পর্যবেক্ষণযোগ্য মিউটেশন নেই। আপনি যখনই কল করবেন Id, আপনি প্রতিবার একই মান পাবেন। এটি একই ক্ষেত্রে প্রযোজ্য Invalidate()(আপনি কিছুই পাবেন না, কারণ এটির রিটার্ন টাইপ হয় void) সুতরাং, প্রকারটি অপরিবর্তনীয়। অবশ্যই, আপনার পার্শ্ব প্রতিক্রিয়া রয়েছে , তবে আপনি ইন্টারফেসের মাধ্যমে সেগুলি পর্যবেক্ষণ করতে পারবেন না IX, তাই তাদের ক্লায়েন্টগুলির উপর তাদের কোনও প্রভাব পড়বে না IX।

— প্রস্কর

ঠিক আছে, আমরা একমত হতে পারি যে IXঅপরিবর্তনীয়। এবং যে তারা পার্শ্ব প্রতিক্রিয়া হয়; এগুলি কেবল দুটি বিভক্ত ইন্টারফেসের মধ্যে বিতরণ করা হয়েছে যাতে ক্লায়েন্টদের যত্ন নেওয়ার প্রয়োজন হয় না (ক্ষেত্রে IX) বা পার্শ্ব প্রতিক্রিয়াটি কী হতে পারে তা স্পষ্টভাবেই (এর ক্ষেত্রে Invalidatable)। কিন্তু কেন না এগিয়ে Invalidateযান Invalidatable? এটি IXঅপরিবর্তনীয় এবং খাঁটি করে তোলে , এবং Invalidatableআরও পরিবর্তনযোগ্য বা ততোধিক অশুদ্ধ হয়ে উঠবে না (কারণ এটি ইতিমধ্যে উভয়ই)।

— stakx

(আমি বুঝতে পারি যে একটি বাস্তব-জগতের দৃশ্যে, ইন্টারফেস বিভাজনের প্রকৃতি সম্ভবত প্রযুক্তিগত বিষয়গুলির চেয়ে ব্যবহারিক ব্যবহারের ক্ষেত্রে বেশি নির্ভর করবে তবে আমি এখানে আপনার যুক্তি পুরোপুরি বুঝতে চেষ্টা করছি।)

— স্টাকেক্স

1

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

— প্রকোস্ট