বিভিন্ন ধরণের পলিমারফিজম রয়েছে, আগ্রহের মধ্যে একটি হ'ল সাধারণত রানটাইম পলিমারফিজম / ডায়নামিক প্রেরণ।
রানটাইম পলিমারফিজমের খুব উচ্চ স্তরের বর্ণনাটি হ'ল কোনও মেথড কল তার রানটাইমের ধরণের উপর নির্ভর করে বিভিন্ন কাজ করে: এটি বিশাল পরিমাণে নমনীয়তার সুযোগ দেয়।
এই নমনীয়তাটি ব্যবহার করার অন্যতম সাধারণ উপায় হ'ল নির্ভরতা ইঞ্জেকশন depend , যেমন আমি বিভিন্ন প্রয়োগের মধ্যে পরিবর্তন করতে পারি বা পরীক্ষার জন্য মক অবজেক্টগুলিকে ইনজেক্ট করতে পারি। যদি আমি আগেই জানতাম যে কেবলমাত্র সম্ভাব্য পছন্দগুলির একটি সীমিত সংখ্যকই আমি শর্তসাপেক্ষে তাদের হার্ডকোড দেওয়ার চেষ্টা করতে পারি, যেমন:
void foo() {
if (isTesting) {
... // do mock stuff
} else {
... // do normal stuff
}
}
এটি কোড অনুসরণ করা শক্ত করে তোলে। বিকল্পটি হ'ল সেই ফু-অপারেশনের জন্য একটি ইন্টারফেস প্রবর্তন করা এবং একটি সাধারণ বাস্তবায়ন এবং সেই ইন্টারফেসের একটি মক বাস্তবায়ন এবং রানটাইমগুলিতে কাঙ্ক্ষিত বাস্তবায়নের জন্য "ইনজেকশন" লেখা। "নির্ভরতা ইনজেকশন" "একটি যুক্তি হিসাবে সঠিক বস্তুটি পাস করার" জন্য একটি জটিল শব্দ।
একটি বাস্তব-বিশ্বের উদাহরণ হিসাবে, আমি বর্তমানে একটি ধরণের মেশিন-লার্নিং সমস্যা নিয়ে কাজ করছি। আমার একটি অ্যালগরিদম রয়েছে যার জন্য একটি পূর্বাভাস মডেল প্রয়োজন। তবে আমি বিভিন্ন মেশিন লার্নিং অ্যালগরিদম ব্যবহার করে দেখতে চাই। সুতরাং আমি একটি ইন্টারফেস সংজ্ঞায়িত। আমার পূর্বাভাস মডেল থেকে আমার কী দরকার? কিছু ইনপুট নমুনা দেওয়া হয়েছে, পূর্বাভাস এবং এর ত্রুটিগুলি:
interface Model {
def predict(sample) -> (prediction: float, std: float);
}
আমার অ্যালগরিদম একটি ফ্যাক্টরি ফাংশন নেয় যা একটি মডেলকে প্রশিক্ষণ দেয়:
def my_algorithm(..., train_model: (observations) -> Model, ...) {
...
Model model = train_model(observations);
...
y, std = model.predict(x)
...
}
আমার কাছে এখন মডেল ইন্টারফেসের বিভিন্ন প্রয়োগ রয়েছে এবং সেগুলি একে অপরের বিপরীতে বেনমার্ক করতে পারি। এর মধ্যে একটি বাস্তবায়ন আসলে অন্য দুটি মডেল নেয় এবং এগুলিকে একটি বুস্টেড মডেলের সাথে সংযুক্ত করে। তাই এই ইন্টারফেস ধন্যবাদ:
- আমার অ্যালগরিদমের নির্দিষ্ট মডেলগুলি আগাম জানতে হবে না,
- আমি সহজেই মডেলগুলি অদলবদল করতে পারি, এবং
- আমার মডেলগুলি বাস্তবায়নে আমার অনেকটা নমনীয়তা রয়েছে।
পলিমারফিজমের ক্লাসিক ব্যবহারের ক্ষেত্রে জিইআইতে রয়েছে I জাভা এডাব্লুটি / সুইং / এর মতো জিইউআই ফ্রেমওয়ার্কে ... বিভিন্ন উপাদান রয়েছে । উপাদান ইন্টারফেস / বেস শ্রেণিটি স্ক্রিনে নিজেকে চিত্রিত করা, বা মাউস ক্লিকগুলিতে প্রতিক্রিয়া দেওয়ার মতো ক্রিয়াগুলি বর্ণনা করে। অনেকগুলি উপাদান পাত্রে থাকে যা উপ-উপাদানগুলি পরিচালনা করে। কিভাবে এই ধারক নিজেই আঁকতে পারে?
void paint(Graphics g) {
super.paint(g);
for (Component child : this.subComponents)
child.paint(g);
}
এখানে, ধারকটির সাব-কম্পোনেন্টগুলির সঠিক প্রকারগুলি সম্পর্কে আগাম সম্পর্কে জানতে হবে না - যতক্ষণ না তারা Component
ইন্টারফেসের সাথে মাপসই থাকে কনটেইনার কেবল পলিমারফিক paint()
পদ্ধতিতে কল করতে পারে । এটি আমাকে স্বেচ্ছাসেবী নতুন উপাদানগুলির সাথে এডাব্লুটি শ্রেণীর শ্রেণিবিন্যাস বাড়ানোর স্বাধীনতা দেয়।
সফ্টওয়্যার বিকাশ জুড়ে অনেকগুলি পুনরাবৃত্ত সমস্যা রয়েছে যা প্রযুক্তি হিসাবে পলিমারফিজম প্রয়োগ করে সমাধান করা যেতে পারে। এই পুনরাবৃত্ত সমস্যা – সমাধান জোড়াগুলিকে ডিজাইনের নিদর্শন বলা হয় এবং এর মধ্যে কয়েকটি একই নামের বইতে সংগ্রহ করা হয়। বইটির শর্তে, আমার ইনজেক্টেড মেশিন লার্নিং মডেলটি এমন একটি কৌশল হবে যা আমি "অ্যালগরিদমের একটি পরিবারকে সংজ্ঞায়িত করতে, প্রত্যেককেই আবদ্ধ করতে এবং তাদের বিনিময়যোগ্য করতে" ব্যবহার করি। জাভা-এডাব্লুটি উদাহরণ যেখানে কোনও উপাদানটিতে উপ-উপাদান থাকতে পারে তা যৌগিক উদাহরণ ।
তবে প্রতিটি নকশাকে পলিমারফিজম ব্যবহার করার প্রয়োজন হয় না (ইউনিট পরীক্ষার জন্য নির্ভরতা ইনজেকশন সক্ষম করার বাইরে যা সত্যই ব্যবহারের ক্ষেত্রে ভাল)। বেশিরভাগ সমস্যাগুলি অন্যথায় খুব স্থির হয় are ফলস্বরূপ, ক্লাস এবং পদ্ধতিগুলি প্রায়শই বহুবর্ষের জন্য ব্যবহৃত হয় না, তবে কেবল সুবিধাজনক নেমস্পেস এবং সুন্দর পদ্ধতি কল সিনট্যাক্সের জন্য। যেমন অনেক বিকাশকারী পদ্ধতি কলগুলিকে পছন্দ account.getBalance()
করে যেমন একটি বৃহত সমতুল্য ফাংশন কল Account_getBalance(account)
। এটি একটি নিখুঁত সূক্ষ্ম পদ্ধতির, এটি কেবলমাত্র বহু পদ্ধতি "কল" এর বহুবর্ষের সাথে কোনও সম্পর্ক নেই।