প্রেরণাগুলি মধ্যে পার্থক্য বুঝতে:
মনে করুন আপনি এমন একটি সরঞ্জাম তৈরি করছেন যেখানে আপনি বস্তু তৈরি করেছেন এবং অবজেক্টগুলির আন্তঃসম্পর্কতার একটি কার্যকর প্রয়োগ। যেহেতু আপনি বস্তুগুলির বিভিন্নতার পূর্বাভাস দিয়েছেন, তাই আপনি অন্য কোনও বস্তুর জন্য বস্তুর বৈকল্পিক তৈরি করার দায়িত্ব অর্পণ করে একটি দিকনির্দেশ তৈরি করেছেন ( আমরা এটাকে অ্যাবস্ট্রাক্ট ফ্যাক্টরি বলি )। আপনি ভবিষ্যতের এক্সটেনশানগুলিকে objects অবজেক্টগুলির বিভিন্ন রূপের প্রয়োজনের আগে থেকেই এই বিমূর্তিটি শক্তিশালী উপকার পেয়েছে।
চিন্তার এই লাইনে আরেকটি বরং আকর্ষণীয় প্রেরণা এমন একটি ঘটনা যেখানে পুরো গোষ্ঠীর প্রতিটি বা-কোনওটিরই সংশ্লিষ্ট বৈকল্পিক থাকবে না। কিছু শর্তের উপর ভিত্তি করে, উভয় রূপই ব্যবহার করা হবে এবং প্রতিটি ক্ষেত্রে সমস্ত বস্তু অবশ্যই একই বৈকল্পিকের হতে হবে। এটি প্রায়শই আমরা মনে করি যেহেতু এটি বুঝতে কিছুটা স্বজ্ঞাত হতে পারে - যতক্ষণ না কোনও বস্তুর রূপগুলি একটি সাধারণ ইউনিফর্ম চুক্তি অনুসরণ করে ( বিস্তৃত অর্থে ইন্টারফেস) ) কংক্রিট বাস্তবায়ন কোডটি ভাঙা উচিত নয়। এখানে আকর্ষণীয় সত্যটি হ'ল, এটি সর্বদা সত্য নয় বিশেষত যখন প্রত্যাশিত আচরণ কোনও প্রোগ্রামিং চুক্তির মাধ্যমে মডেল করা যায় না।
একটি সাধারণ ( জিওএফের কাছ থেকে ধারণা ধার করা) ) কোনও জিইউআই অ্যাপ্লিকেশন হ'ল ভার্চুয়াল মনিটর যা এমএস বা ম্যাক বা ফেডোরা ওএস-এর চেহারা-অনুভূতিকে অনুকরণ করে। এখানে উদাহরণস্বরূপ, উইন্ডো, বোতাম ইত্যাদির মতো সমস্ত উইজেট অবজেক্টে যখন ম্যাক ভেরিয়েন্ট থেকে প্রাপ্ত স্ক্রোল-বার ব্যতীত এমএস ভেরিয়েন্ট থাকে, তখন সরঞ্জামটির উদ্দেশ্যটি খারাপভাবে ব্যর্থ হয়।
এই উপরোক্ত মামলাগুলি অ্যাবস্ট্রাক্ট ফ্যাক্টরি প্যাটার্নের মৌলিক প্রয়োজনীয়তা তৈরি করে ।
অন্যদিকে, কল্পনা করুন আপনি একটি কাঠামো লিখছেন যাতে অনেক লোক আপনার কাঠামোটি ব্যবহার করে বিভিন্ন সরঞ্জাম ( যেমন উপরের উদাহরণগুলির মধ্যে একটি ) তৈরি করতে পারে। একটি কাঠামোর ধারণা সম্পর্কে, আপনার প্রয়োজন নেই, যদিও আপনি আপনার যুক্তিতে কংক্রিট অবজেক্টগুলি ব্যবহার করতে পারবেন না। আপনি বরং বিভিন্ন বিষয়বস্তু এবং তারা কীভাবে ইন্টারঅ্যাক্ট করেন তার মধ্যে কিছু উচ্চ স্তরের চুক্তি রেখেছিলেন। আপনি ( ফ্রেমওয়ার্ক বিকাশকারী হিসাবে ) খুব বিমূর্ত স্তরে থাকা অবস্থায়, সরঞ্জামটির প্রতিটি নির্মাতাকে আপনার কাঠামো-গঠনগুলি অনুসরণ করতে বাধ্য করা হয়। যাইহোক, তাদের ( সরঞ্জাম নির্মাতারা ) কোন অবজেক্টটি তৈরি করা উচিত এবং তারা যে সমস্ত বস্তু তৈরি করবেন তা কীভাবে ইন্টারঅ্যাক্ট করবে তা নির্ধারণ করার স্বাধীনতা রয়েছে। পূর্ববর্তী কেস ( বিমূর্ত কারখানার প্যাটার্ন ) এর বিপরীতে , আপনি ( ফ্রেমওয়ার্ক স্রষ্টা হিসাবে) এক্ষেত্রে কংক্রিটের সাথে কাজ করার দরকার নেই; এবং বরং অবজেক্টগুলির চুক্তি পর্যায়ে থাকতে পারে। তদ্ব্যতীত, পূর্ববর্তী প্রেরণাগুলির দ্বিতীয় অংশের বিপরীতে, আপনার বা সরঞ্জাম-নির্মাতাদের কখনও বৈকল্পিক থেকে বস্তুর মিশ্রণের পরিস্থিতি নেই। এখানে, ফ্রেমওয়ার্ক কোডটি চুক্তি স্তরে থাকা অবস্থায়, প্রতিটি সরঞ্জাম-নির্মাতা তাদের নিজস্ব বস্তু ব্যবহারের ক্ষেত্রে ( কেস প্রকৃতির দ্বারা ) সীমাবদ্ধ । এক্ষেত্রে অবজেক্ট ক্রিয়েশনগুলি প্রতিটি প্রয়োগকারীকে অর্পণ করা হয় এবং কাঠামো সরবরাহকারীরা কেবলমাত্র বস্তু তৈরি এবং ফিরে আসার জন্য অভিন্ন পদ্ধতি সরবরাহ করে। এ জাতীয় পদ্ধতিগুলি ফ্রেমওয়ার্ক বিকাশকারীদের তাদের কোডটি এগিয়ে নিয়ে যাওয়ার জন্য অনিবার্য এবং কারখানার পদ্ধতি ( অন্তর্নিহিত প্যাটার্নের জন্য ফ্যাক্টরি পদ্ধতি প্যাটার্ন ) নামে একটি বিশেষ নাম রয়েছে ।
কয়েকটি নোট:
- আপনি যদি 'টেম্পলেট পদ্ধতি' সম্পর্কে পরিচিত হন, তবে আপনি দেখতে পাবেন যে কোনও ধরণের কাঠামোর সাথে সম্পর্কিত প্রোগ্রামগুলির ক্ষেত্রে ফ্যাক্টরি পদ্ধতিগুলি প্রায়শই টেম্পলেট পদ্ধতিগুলি থেকে আহ্বান করা হয়। বিপরীতে, অ্যাপ্লিকেশন-প্রোগ্রামগুলির টেম্পলেট পদ্ধতিগুলি প্রায়শই নির্দিষ্ট অ্যালগরিদমের সহজ প্রয়োগ এবং কারখানা-পদ্ধতিগুলি শূন্য থাকে।
- তদ্ব্যতীত, চিন্তাভাবনার সম্পূর্ণতার জন্য, ফ্রেমওয়ার্কটি ( উপরে উল্লিখিত ) ব্যবহার করে , যখন কোনও সরঞ্জাম-নির্মাতা কোনও কারখানা পদ্ধতির অভ্যন্তরে কোনও কংক্রিট অবজেক্ট তৈরির পরিবর্তে কোনও সরঞ্জাম তৈরি করছেন, তখন তিনি আরও একটি বিমূর্তির উপর দায়িত্ব অর্পণ করতে পারেন ফ্যাক্টরি অবজেক্ট, সরঞ্জাম-নির্মাতা ভবিষ্যতের এক্সটেনশনের জন্য কংক্রিট অবজেক্টগুলির পরিবর্তনের পূর্বাভাস দেয়।
কোডের উদাহরণ:
//Part of framework-code
BoardGame {
Board createBoard() //factory method. Default implementation can be provided as well
Piece createPiece() //factory method
startGame(){ //template method
Board borad = createBoard()
Piece piece = createPiece()
initState(board, piece)
}
}
//Part of Tool-builder code
Ludo inherits BoardGame {
Board createBoard(){ //overriding of factory method
//Option A: return new LudoBoard() //Lodu knows object creation
//Option B: return LudoFactory.createBoard() //Lodu asks AbstractFacory
}
….
}
//Part of Tool-builder code
Chess inherits BoardGame {
Board createBoard(){ //overriding of factory method
//return a Chess board
}
….
}
