কৌশল প্যাটার্ন এর সুবিধা

Question

আপনি যদি / তার পরে ক্ষেত্রে কেবল আপনার কোডটি লিখতে পারেন তবে কৌশল প্যাটার্নটি ব্যবহার করা কেন উপকারী?

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

এছাড়াও, রানটাইমটিতে অ্যালগরিদমটি পরিবর্তনের অর্থ কী?

Comments

এই হোমওয়ার্ক হয়? আপ-ফ্রন্ট যদি তা থাকে তবে তা বলা ভাল।

— ফুহরম্যানেটর

@ ফুহরমনেটর এটির মত নয়

— সাফাই

Answer 1

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

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

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

কৌশল কৌশলটি এখানে:

• আপনি একটি ইন্টারফেস সংজ্ঞায়িত করেন, উদাহরণস্বরূপ TaxCalculation, এবং আপনার কাঠামো ট্যাক্স গণনা করার জন্য এই ধরণের উদাহরণ স্বীকার করে
• কাঠামোর ব্যবহারকারীর একটি শ্রেণি তৈরি করা হয়েছে যা এই ইন্টারফেসটি প্রয়োগ করে এবং এটি আপনার কাঠামোর কাছে পৌঁছে দেয়, এইভাবে গণনার কিছু অংশ সম্পাদনের উপায় সরবরাহ করে

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

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

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

খোলা / বন্ধ নীতি , এছাড়াও খুব প্রাসঙ্গিক, কারণ হিসাবে আমি উপরের উদাহরণে বর্ণিত, স্ট্র্যাটেজি আপনি ঐ অংশ (rewriting "পরিমার্জন জন্য বন্ধ" ছাড়া আপনার কোড ( "এক্সটেনশন জন্য খোলা") কিছু অংশে একটি যুক্তিবিজ্ঞান প্রসারিত করতে পারবেন )।

Comments

if/elseব্লকগুলিও কোড পাঠযোগ্যতা কম করে। কৌশল প্যাটার্ন হিসাবে, ওপেন / ক্লোজড নীতি আইএমও উল্লেখযোগ্য।

— ম্যাকিয়েজ চ্যাপাপুক

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

— গ্রেগ বার্গার্ড

উত্তরের জন্য ধন্যবাদ. তাহলে কেন আমি একই শ্রেণিতে বিভিন্ন অ্যালগরিদমের জন্য পৃথক পদ্ধতি ব্যবহার করতে পারি না?

— আরমন সাফাই

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

— স্ক্রিপ্টিন

কেন এটি পরীক্ষা করা আরও সহজ তা সম্পর্কে আপনি আরও পরিষ্কার হতে পারেন? পলিমারফিক পদ্ধতিতে (কৌশলটির ভিত্তি) কেস স্টেটমেন্ট (বা যদি / তারপরে) রিফ্যাক্টর করার উদাহরণটি পরীক্ষা করা বেশ সহজ। রিফ্যাক্টরিং / ক্যাটাগল / রিপ্লেসকন্ডিশনাল উইথপলিমারফিজম html যদি আমি পরীক্ষার জন্য সমস্ত শর্ত জানি তবে আমি প্রত্যেকটির জন্য একটি পরীক্ষা লিখি। আমার যদি কৌশল থাকে তবে আমাকে প্রত্যেকের জন্য একটি তাত্ক্ষণিকভাবে চালিত করতে হবে এবং চালিত করতে হবে। কৌশল কীভাবে পরীক্ষা করা সহজ? আপনি যখন স্ট্র্যাটেজির রিফ্যাক্টর হন তখন আমরা জটিল নেস্টেড আইএফ নিয়ে কথা বলছি না।

— ফুহরম্যানেটর

Answer 2

আপনি যদি / তার পরে ক্ষেত্রে কেবল আপনার কোডটি লিখতে পারেন তবে কৌশল প্যাটার্নটি ব্যবহার করা কেন উপকারী?

কখনও কখনও আপনার যদি কেবল / তখন ব্যবহার করা উচিত। এটি সহজ কোড যা পড়া সহজ।

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

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

Comments

যদি / তারপরে কোডে কোড পরিবর্তন করে ভুল হয়? আপনি যদি কৌশলগত প্যাটার্নে কোডটি সংশোধন করতে চান তবে আপনি যদি আলগোরিদিমগুলির মধ্যে একটির ফাংশন কীভাবে পরিবর্তন করতে চান?

— আরমন সাফাই

@ আরমনসফাই - আপনি যদি কৌশলটি পরিবর্তন করেন তবে আপনার কৌশলটি পরীক্ষা করা দরকার। আপনি যদি সমস্ত অ্যালগরিদম পরিবর্তন করেন তবে আপনাকে সমস্ত অ্যালগরিদমগুলি পরীক্ষা করতে হবে। সবচেয়ে খারাপ, আপনি যদি নতুন কৌশল যুক্ত করেন তবে আপনার কৌশলটি পরীক্ষা করা দরকার। আপনি যদি নতুন শর্তসাপেক্ষ যুক্ত করেন তবে আপনার সমস্ত শর্তসাপেক্ষ পরীক্ষা করা দরকার।

— টেলাস্টিন

Answer 3

if/thenশর্তগুলি প্রকারের উপর ভিত্তি করে যখন কৌশলটি কার্যকর হয় , যেমন http://www.refactoring.com/catolog/replaceConditionalWithPolymorphism.html তে ব্যাখ্যা করা হয়েছে

টাইপ-চেকিং শর্তসাপেক্ষে সাধারণত উচ্চ চক্রযুক্ত জটিলতা থাকে না, তাই আমি বলব না যে কৌশল সেখানে প্রয়োজনীয়ভাবে উন্নতি করে।

কৌশলটির মূল কারণটি GoF বই p.316 তে ব্যাখ্যা করা হয়েছে যা প্যাটার্নটি প্রবর্তন করেছিল:

কৌশল প্যাটার্ন ব্যবহার করুন যখন

...

• একটি শ্রেণি অনেকগুলি আচরণের সংজ্ঞা দেয় এবং এগুলি এর ক্রিয়াকলাপগুলিতে একাধিক শর্তাধীন বিবৃতি হিসাবে উপস্থিত হয়। অনেকগুলি শর্তাবলীর পরিবর্তে, সম্পর্কিত শর্তাধীন শাখাগুলি তাদের নিজস্ব কৌশল শ্রেণিতে সরান।

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

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

Answer 4

[...] যদি আপনি কেবল আপনার কোডটি লিখতে পারেন তবে / যদি ক্ষেত্রে?

এটি হ'ল কৌশলগত প্যাটার্নের সবচেয়ে বড় সুবিধা benefit শর্ত না থাকা।

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

শর্তাবলী ( if/ elseif/ else) করতে আপনার ক্লাস / পদ্ধতি / ফাংশন দীর্ঘ, কারণ সাধারণত কোড যেখানে এক সিদ্ধান্ত মূল্যায়ণ করার trueঅংশ যেখানে সিদ্ধান্ত মূল্যায়ণ থেকে ভিন্ন false।

---

কৌশল প্যাটার্নের আর একটি দুর্দান্ত সুবিধা হ'ল এটি আপনার পুরো প্রকল্প জুড়ে পুনরায় ব্যবহারযোগ্য।

কৌশল ডিজাইনের প্যাটার্নটি ব্যবহার করার সময়, আপনার খুব সম্ভবত কোনও আইওসি পাত্রে থাকার সম্ভাবনা রয়েছে, যেখান থেকে আপনি কোনও ইন্টারফেসের পছন্দসই বাস্তবায়ন করছেন, সম্ভবত কোনও getById(int id)পদ্ধতি দ্বারা , যেখানে idএকজন গণক সদস্য হতে পারে।

এর অর্থ, বাস্তবায়নটি তৈরি করা আপনার কোডের এক জায়গায় in

আপনি যদি আরও বাস্তবায়ন যুক্ত করতে চান তবে আপনি getByIdপদ্ধতিটিতে নতুন বাস্তবায়ন যুক্ত করুন এবং আপনি যে কোডটি কল করেছেন সেখানে এই পরিবর্তনটি প্রতিফলিত হবে।

সাথে if/ elseif/ elseএটি করা অসম্ভব। একটি নতুন বাস্তবায়ন যুক্ত করে, আপনাকে একটি নতুন elseifব্লক যুক্ত করতে হবে এবং যেখানে প্রয়োগগুলি ব্যবহৃত হয়েছিল সেখানেই এটি করতে হবে, বা আপনি একটি কোড দিয়ে শেষ করতে পারেন যা অবৈধ, কারণ আপনি বাস্তবায়নের কাঠামোটিতে যুক্ত করতে ভুলে গেছেন।

---

এছাড়াও, রানটাইমটিতে অ্যালগরিদমটি পরিবর্তনের অর্থ কী?

আমার উদাহরণে, এটি idএকটি পরিবর্তনশীল হতে পারে যা ব্যবহারকারীর ইনপুটের উপর ভিত্তি করে পপুলেট হয়। যদি ব্যবহারকারী একটি বোতামে ক্লিক করে A, তারপরে id = 2, তিনি যদি একটি বোতাম বিতে ক্লিক করেন, তবে id = 8।

ভিন্ন idমানের কারণে, আইওসি পাত্রে থেকে একটি ইন্টারফেসের একটি পৃথক বাস্তবায়ন পাওয়া যায় এবং কোডটি বিভিন্ন ক্রিয়াকলাপ সম্পাদন করে।

Comments

উত্তরের জন্য ধন্যবাদ. তাহলে কেন আমি একই শ্রেণিতে বিভিন্ন অ্যালগরিদমের জন্য পৃথক পদ্ধতি ব্যবহার করতে পারি না?

— আরমন সাফাই

@ আরমনসফাই @ পৃথক পদ্ধতিগুলি কি সত্যিই কিছু সমাধান করতে পারে? আমি তাই মনে করি না. আপনি সমস্যাটিকে এক জায়গা থেকে অন্য জায়গায় নিয়ে যাচ্ছেন, এবং কোন পদ্ধতিটি কল করতে হবে তা সিদ্ধান্তের শর্তের ভিত্তিতে নেওয়া হবে। আবার, একটি if/ elseif/ elseরাষ্ট্র। আগের মতোই, ঠিক অন্য জায়গায়।

— অ্যান্ডি

সুতরাং যদি / তারপর মামলাগুলি মূল অধিকারে থাকবে? আপনি যদি কৌশলগত প্যাটার্নের ক্ষেত্রে / তারপরে কেসগুলি মূলত ব্যবহার করতে চান?

— আরমন সাফাই

@ আরমনসফাই না, আপনি না। idআপনার getByIdপদ্ধতিতে পরিবর্তনশীলটির উপর একটি স্যুইচ থাকবে যা নির্দিষ্ট বাস্তবায়নটি ফিরিয়ে দেবে। যতবারই আপনার ইন্টারফেসটির প্রয়োগের প্রয়োজন হবে, আপনি আইওসি পাত্রে এটি আপনাকে সরবরাহ করতে বলবেন।

— অ্যান্ডি

@ আরমনসফাই আপনার ঠিক একই পদ্ধতিতে ইন্টারফেসের getSortByEnumType(SortEnum type)প্রয়োগ বাস্তবায়িত করার পদ্ধতিও থাকতে পারে , একটি ভেরিয়েবল ফিরিয়ে দেওয়ার এবং প্যারামিটার হিসাবে সংগ্রহ করার পদ্ধতি থাকতে পারে এবং সেই পদ্ধতিতে আবার সঠিক প্লেয়ারটি পরিবর্তন করে আপনাকে সঠিক বাছাইকরণ অ্যালগরিদম ফিরিয়ে আনতে পারে। আপনার যদি নতুন নতুন বাছাই করা অ্যালগরিদম যুক্ত করার প্রয়োজন হয় তবে আপনাকে কেবল এনাম এবং একটি পদ্ধতি সম্পাদনা করতে হবে। এবং আপনি সেট করা আছে। SortgetSortTypeSortEnumgetSortByEnumTypetype

— অ্যান্ডি

Answer 5

আপনি যদি / তার পরে ক্ষেত্রে কেবল আপনার কোডটি লিখতে পারেন তবে কৌশল প্যাটার্নটি ব্যবহার করা কেন উপকারী?

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

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

এছাড়াও, রানটাইমটিতে অ্যালগরিদমটি পরিবর্তনের অর্থ কী?

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

Answer 6

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

তবে কিছু নির্দিষ্ট ক্ষেত্রে রয়েছে যেখানে কৌশল বিন্যাস সামগ্রিক কোডের রক্ষণাবেক্ষণের উন্নতি করতে পারে। উদাহরণ স্বরূপ:

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

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

"ট্যাক্স গণনা অ্যালগরিদম" কে মূল যুক্তি থেকে পরিষ্কারভাবে পৃথক করা যেতে পারে যা এটি আহ্বান করে এটি সবই নেমে আসে। একটি কৌশল প্যাটার্নের তুলনায় কিছুটা ওভারহেড থাকে if/else, তাই বিনিয়োগের পক্ষে যদি মূল্য হয় তবে আপনাকে কেস ভিত্তিতে কেস নিয়ে সিদ্ধান্ত নিতে হবে।