রিয়েল ওয়ার্ল্ড - লিসকভ সাবস্টিটিউশন নীতি

Question

পটভূমি: আমি একটি বার্তা কাঠামো বিকাশ করছি। এই কাঠামোটি অনুমতি দেবে:

• একটি সার্ভিস বাসের মাধ্যমে বার্তা প্রেরণ
• বার্তা বাসে সারি সাবস্ক্রাইব
• একটি বার্তা বাসে বিষয় সাবস্ক্রাইব করা

আমরা বর্তমানে র‌্যাবিট এমকিউ ব্যবহার করছি, তবে আমি জানি আমরা খুব অদূর ভবিষ্যতে মাইক্রোসফ্ট সার্ভিস বাসে (প্রিমিসে) চলে যাব।

আমি ইন্টারফেস এবং বাস্তবায়নগুলির একটি সেট তৈরি করার পরিকল্পনা করছি যাতে আমরা যখন সার্ভিস-এ চলে যাই তখন ক্লায়েন্ট কোডের (যেমন প্রকাশক বা গ্রাহক) কোনও সংশোধন না করে আমার কেবল নতুন বাস্তবায়ন সরবরাহ করা দরকার।

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

সুতরাং আমার বক্তব্য, আমি নিম্নলিখিত হিসাবে একটি ইন্টারফেস তৈরি করতে পারেন:

public interface IMessageReceiver{
  void AddSubscription(ISubscription subscriptionDetails)
}

দুটি প্রযুক্তির অ-অনুবাদযোগ্য বৈশিষ্ট্যগুলির কারণে, উপরের ইন্টারফেসের সার্ভিসবাস এবং রাবিট এমকিউ বাস্তবায়নের আলাদা আলাদা প্রয়োজনীয়তা রয়েছে। সুতরাং IMessageReceiver এর আমার RabbitMq বাস্তবায়নটি দেখতে দেখতে এটি দেখতে পারে:

public void AddSubscription(ISubscription subscriptionDetails){
  if(!subscriptionDetails is RabbitMqSubscriptionDetails){
    // I have a problem!
  }
}

আমার কাছে, উপরের লাইনটি লিসকোভের বিকল্প ব্যবস্থার বিধি ভঙ্গ করেছে।

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

সুতরাং, আমার প্রশ্নগুলি হ'ল:

• আমি কি ঠিক করছি যে এটি এলএসপিকে ব্রেক করে?
• আমরা কি একমত যে কিছু ক্ষেত্রে এটি অনিবার্য, বা, আমি কিছু মিস করছি?

আশা করি, এটি স্পষ্ট এবং বিষয়টিতে!

Comments

ইন্টারফেসে কোনও ধরণের পরামিতি যুক্ত করা কি আপনার জন্য একটি বিকল্প? জাভা-সিনট্যাক্সের ক্ষেত্রে, এর মতো কিছু interface TestInterface<T extends ISubscription>পরিষ্কারভাবে যোগাযোগ করবে যে কোন ধরণের গৃহীত হয় এবং বাস্তবায়নের মধ্যে পার্থক্য রয়েছে।

— হাল্ক

@ হাল্ক, আমি এটি বিশ্বাস করি না, কারণ প্রতিটি প্রয়োগের জন্য আইএসবস্ক্রিপ্টের আলাদা বাস্তবায়ন প্রয়োজন হবে।

— জিনজানিজা

দুঃখিত, আমি যা প্রস্তাব করতে চেয়েছিলাম তা হ'ল interface IMessageReceiver<T extends ISubscription>{void AddSubscription(T subscriptionDetails); }। একটি বাস্তবায়ন তখন public class RabbitMqMessageReceiver implements IMessageReceiver<RabbitMqSubscriptionDetails> { public void AddSubscription(RabbitMqSubscriptionDetails subscriptionDetails){} }(জাভাতে) মতো দেখতে পেত ।

— হাল্ক

Answer 1

হ্যাঁ, এটি এলএসপিকে ভঙ্গ করে, কারণ আপনি গৃহীত মানগুলির সংখ্যা সীমাবদ্ধ করে উপ-শ্রেণীর সুযোগকে সংকুচিত করছেন, আপনি প্রাক শর্তগুলি প্রসারিত করছেন। পিতামাতারা এটি গ্রহণ করে তা নির্দিষ্ট করে ISubscriptionতবে শিশু তা গ্রহণ করে না।

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

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

Comments

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

— GinjaNinja

Answer 2

হ্যাঁ, আপনার কোড এখানে এলএসপি ভেঙে দেয়। এই জাতীয় ক্ষেত্রে, আমি ডিডিডি ডিজাইন প্যাটার্নগুলি থেকে দুর্নীতি দমন স্তরটি ব্যবহার করব। আপনি এখানে একটি উদাহরণ দেখতে পাচ্ছেন: http://www.markhneedham.com/blog/2009/07/07/domain-driven-design-anti-c भ्रष्टाचार-layer/

ধারণাটি হ'ল সাব-সিস্টেমটিকে স্পষ্টভাবে বিচ্ছিন্ন করে নির্ভরতা যতটা সম্ভব হ্রাস করা, এটি পরিবর্তন করার সময় রিফ্যাক্টরিংকে কমিয়ে আনা

আশা করি এটা সাহায্য করবে !