এমন কোনও ডিজাইনের প্যাটার্ন রয়েছে যা ছাড় মডেলের ক্ষেত্রে প্রযোজ্য?

Question

ছাড়ের মডেলগুলি প্রয়োগের জন্য কি কোনও পরিচিত নকশার নিদর্শন রয়েছে?

ছাড়ের মডেলগুলির দ্বারা, আমি নিম্নলিখিতটি বোঝাতে চাইছি:

1. যদি কোনও গ্রাহক পণ্য এক্স, পণ্য ওয়াই এবং পণ্য জেড কিনে তবে তিনি 10% বা $ 100 ছাড় পাবেন।

2. কোনও গ্রাহক যদি প্রোডাক্ট এক্স এর 100 ইউনিট কিনে তবে সে 15% বা $ 500 ছাড় পাবে

3. যদি কোনও গ্রাহক গত বছরে K 100K এর বেশি আনেন তবে তিনি ফ্ল্যাটটিতে 20% ছাড় পাবেন

4. কোনও গ্রাহক যদি প্রোডাক্ট এক্স এর 2 ইউনিট কিনে থাকে তবে তিনি পণ্য এক্স এর 1 ইউনিট (বা পণ্য ওয়াই) বিনামূল্যে পান।

5. ...

উপরের সমস্ত পরিস্থিতিতে পরিচালনার জন্য কী জেনেরিক প্যাটার্ন প্রয়োগ করা যেতে পারে? আমি কয়েকটি মডেলের কথা ভাবছি, তবে জেনেরিকটি দেখতে পারা যায় না।

Comments

IIRC সব টিউটোরিয়াল আমি ডিসকাউন্ট জড়িত উদাহরণ দেখা করেছি (অনেক হয়) স্ট্র্যাটেজি প্যাটার্ন সুপারিশ

— মশা

@ কণিনী এটি কি বাস্তব-বিশ্বের সমস্যা? এরকম ক্ষেত্রে এই সিস্টেমটি কি রিয়েল-টাইম বা মুলতুবি-সময়ে? এই বিধিগুলি কি কোনও নিয়ম-ইঞ্জিন বা ডাটাবেস মান হিসাবে উপস্থাপিত হয়? ছাড়ের সন্ধান কী অগ্রাধিকারের ভিত্তিতে শ্রেণিবদ্ধ? কৌশল প্যাটার্ন বেশিরভাগ ক্ষেত্রে কাজ করবে তবে এটি কার্যকর করার জন্য আপনার নিয়মগুলি অবশ্যই প্রমাণিত হতে হবে

— উবারম্যানশ

এছাড়াও যদি কেউ প্রোডাক্ট এক্স, একটি পণ্য ওয়াই এবং একটি পণ্য জেড 2 ইউনিট ক্রয় করে তবে 10% এবং অতিরিক্ত পণ্য এক্স উভয়ই পেতে পারে?

— উবারম্যানশ

দয়া করে দয়া করে সেই কয়েকটি টিউটোরিয়ালের কয়েকটি লিঙ্ক জাগ্রত করুন।

— ব্যবহারকারীর6767

Answer 1

যদি সমস্যাটি হয় তবে আপনাকে একাধিক ছাড় প্রয়োগ করতে হবে, নির্দিষ্ট পরিস্থিতিতে, আপনি দায়বদ্ধতার চেইনটি বিবেচনা করতে চাইতে পারেন ।

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

এইভাবে আপনি কলিং কোডটি কখনও পরিবর্তন না করে প্রসেসরের কাঠামো এবং ক্রম পরিবর্তন করতে পারেন।

Comments

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

— টমাস ওয়ানস

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

— ডক ব্রাউন

Answer 2

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

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

Comments

রাষ্ট্রের প্যাটার্নটি যা করার তাগিদে আসলেই তা নয়, তাই না?

— পিডিআর

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

— টমাস ওয়ানস

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

— পিডিআর

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

— jfrankcarr

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

— টমাস ওয়েন্স

Answer 3

ঠিক আছে, আমি একটি জুটি হিসাবে "পূর্ব শর্ত" এবং "ছাড়" হিসাবে ছাড়ের মডেলটি ডিজাইন করব, যেখানে "পূর্ব শর্ত" পদ্ধতি সহ একটি শ্রেণি

  bool IsFulfilled(Customer c);

অথবা এবং

  bool IsFulfilled(Customer c, Order o);

এবং ছাড়ের একটি পদ্ধতি রয়েছে void ApplyTo(Customer c)। এটি আপনাকে যে কোনও প্রকার পূর্বশর্তকে যে কোনও ধরণের ছাড়ের সাথে একত্রিত করার ক্ষমতা দেয় (আমি মনে করি এটি "ব্রিজ প্যাটার্ন" এর একটি রূপ)।

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

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

Comments

আমার অন্তর্নিহিত পরামর্শ দেয় যে এই প্রশ্নের প্রসঙ্গে তিনি যা খুঁজছিলেন তা হতে পারে

— উবারম্যানশ

Answer 4

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

• "এই গ্রাহকের আদেশ" শ্রেণিতে সম্ভবত ছাড়ের সংগ্রহ দরকার needs তালিকা? হ্যাশ? যোজিত তালিকা? তবুও যত্ন নেই ছাড় ক্রয়ের ক্ষেত্রে প্রযোজ্য, গ্রাহক নয়!

• গ্রাহক, শপিং কার্ট, ইতিহাস ইত্যাদি থেকে ছাড়ের বিল্ডিং বিল্ডিং রাখুন এটি অনেকটা বদলে যাবে - যেমন @ জেফরঙ্ককারার উল্লেখ করেছেন।

• সম্ভবত প্রতিটি ছাড়ের জন্য পৃথক শ্রেণি এবং প্রতিটি ছাড়ের জন্য অ্যালগরিদম এবং প্যারামিটারগুলি বন্য ও অপ্রত্যাশিতভাবে পরিবর্তিত হয়।

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

নকশা প্যাটার্ন অ্যাপ্লিকেশন

• আমি একটি strategy pattern। আইডিসকাউন্ট হ'ল বিভিন্ন ছাড়ের অ্যালগোরিদমগুলি প্রয়োগ করার ইন্টারফেস।

• আমি একটি factory। অবশ্যই একটি পূর্ণ-বিকাশ নয় abstract factory pattern, বিশ্লেষণে এই সময়ে একক শ্রেণি। যুক্তিসঙ্গতভাবে, একটি একক জায়গা থাকতে হবে যেখানে কোন ছাড়টি প্রযোজ্য তা সিদ্ধান্ত নিতে এবং তারপরে সেগুলি তৈরি করার পর্যাপ্ত প্রসঙ্গ থাকতে হবে। এক শ্রেণি. যদি বিপণন বিভাগের মাশরুম পার্টির কারণে ছাড়ের আবেদনের নিয়মগুলি পরে বিস্ফোরিত হয় তবে কোনও অতিরিক্ত ছাড় ছাড় নির্মাণের যুক্তিটি এখনও এই বেস কারখানার শ্রেণিতে একত্রিত হতে হবে, আমি মনে করি।

• আমি দেখতে পাচ্ছি Chain of Responsibility। এটি factoryধারণার সাথে পারস্পরিক একচেটিয়া নয় । ছাড় সংগ্রহের পুনরাবৃত্তির পরিবর্তে প্রতিটি ছাড় পরবর্তী লোকটিকে কল করে। "গ্রাহকের আদেশ" শ্রেণি এই ক্ষেত্রে ছাড়ের সংগ্রহ রাখে না।

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

অনুমিতি

• ছাড়গুলি বর্তমান শপিং কার্ট এবং / বা ক্রয়ের ইতিহাসের ভিত্তিতে
• শূন্য বা আরও ছাড় প্রয়োগ হতে পারে। কোনও পারস্পরিক একচেটিয়া ছাড় নেই
• যথাযথ গণনাটি যে ক্রমে ছাড় প্রয়োগ করা হয় তার উপর নির্ভর করে না।

কি পরিবর্তন হয়, কি একই থাকে?

• ছাড় খুব আলাদা। প্রতিটি নিয়ম তৈরি করতে বিভিন্ন সংখ্যা এবং ধরণের প্যারামিটার।

• শপিং কার্টের পরিবর্তনের সাথে সাথে যোগ্যতা ছাড়ের যুক্তিগুলি পরিবর্তিত হয়।

• ছাড়ের সংখ্যা উপলব্ধ

• এই গ্রাহক তার শপিং কার্ট পরিবর্তন হিসাবে পরিবর্তনের জন্য যোগ্য এই ছাড়।

• এই ক্রয়ের প্রসঙ্গে শপিংয়ের ইতিহাস পরিবর্তন হয় না

• ক্রয় লাইন এবং ছাড় প্রয়োগ করা হিসাবে একটি ক্রিয়াকলাপ হিসাবে মোট ব্যয় গতিশীল পরিবর্তন হয়।

• প্রাথমিক প্রয়োগের পরে ছাড়ের আউটপুট পরিবর্তিত হতে পারে, উদাহরণস্বরূপ ক্রয়ের পরিমাণ পরিবর্তন হয়।

Comments

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

— le0diaz

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

— রডারবব

Answer 5

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

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

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

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

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

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

Answer 6

এর কোন কার্যকর প্যাটার্ন আছে কি না এমন কোনও প্রশ্ন জিজ্ঞাসা করছে? কাঠামোগত বা আচরণগত - কী ধরণের প্যাটার্ন প্রয়োজন?

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

cart.calculateDiscount(productVector);

এর চেয়ে বেশি কিছু আপনার দরকার নেই!

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

আমাদের যদি একে অপরের API এর অ্যাক্সেস করতে বা কোনও কার্য স্থলে রাখার জন্য যোগাযোগ করার জন্য বিভিন্ন অবজেক্টের প্রয়োজন হয় তবেই প্যাটার্নটির প্রয়োজন হবে।

পিএস: এটি সম্পর্কে চিন্তা করুন - যখন ফায়ারওয়াল প্যাকেটগুলি প্রক্রিয়াজাত করে এবং প্যাকেটগুলি পাস করে বা প্রত্যাখ্যান করে (বা এটি সংশোধন করে) - এটি কোন ডিজাইনের প্যাটার্নটি ব্যবহার করে? উত্তরটি বর্ণিত উপরের কোনওটি নয়!

Comments

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

— le0diaz