"বনাম" কেন? এটি "বনাম" নয়। আপনি ফাংশনাল প্রোগ্রামিংয়ের সাথে মিলিয়ে অ্যাসপেক্ট ওরিয়েন্টেড প্রোগ্রামিং ব্যবহার করতে পারেন, তবে অবজেক্ট ওরিয়েন্টডের সাথে সংমিশ্রণে। এটি "বনাম" নয়, এটি "অ্যাসপেক্ট ওরিয়েন্টেড প্রোগ্রামিং উইথ অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিং"।
আমার কাছে এওপি হ'ল এক ধরণের "মেটা-প্রোগ্রামিং"। এওপি যা কিছু করে তা কেবল আরও কোড যুক্ত করে এটি ছাড়াও করা যেতে পারে। এওপি আপনাকে এই কোডটি লিখে সংরক্ষণ করে।
এই মেটা-প্রোগ্রামিংয়ের জন্য উইকিপিডিয়ায় সেরা উদাহরণ রয়েছে। ধরে নিন আপনার অনেকগুলি "সেট ... ()" পদ্ধতি সহ গ্রাফিকাল ক্লাস রয়েছে। প্রতিটি সেট পদ্ধতির পরে গ্রাফিক্সের ডেটা পরিবর্তিত হয়, গ্রাফিকগুলি পরিবর্তিত হয় এবং এভাবে গ্রাফিকগুলি পর্দায় আপডেট করা প্রয়োজন। গ্রাফিকগুলি পুনরায় রঙ করার জন্য ধরে নিন আপনাকে অবশ্যই "Display.update ()" কল করতে হবে। শাস্ত্রীয় পদ্ধতির আরও কোড যুক্ত করে এটি সমাধান করা । প্রতিটি সেট পদ্ধতি শেষে আপনি লিখুন
void set...(...) {
:
:
Display.update();
}
আপনার যদি 3 টি সেট-পদ্ধতি থাকে তবে এটি কোনও সমস্যা নয়। আপনার যদি 200 (অনুমানমূলক) থাকে তবে এটিকে সর্বত্র যুক্ত করা সত্যিকারের বেদনাদায়ক হয়ে উঠছে। এছাড়াও আপনি যখনই কোনও নতুন সেট-পদ্ধতি যুক্ত করবেন তখন অবশ্যই এটি অবশ্যই শেষ পর্যন্ত ভুলে যাবেন না তা নিশ্চিত হওয়া উচিত, অন্যথায় আপনি কেবল একটি বাগ তৈরি করেছেন।
AOP টন কোড যোগ না করে এটি সমাধান করে, পরিবর্তে আপনি কোনও দিক যোগ করুন:
after() : set() {
Display.update();
}
এবং এটাই! আপডেট কোডটি নিজে লেখার পরিবর্তে আপনি কেবল সিস্টেমটিকে বলবেন যে একটি সেট () পয়েন্টকুট পৌঁছানোর পরে এটি অবশ্যই এই কোডটি চালাবে এবং এটি এই কোডটি চালাবে। 200 টি পদ্ধতি আপডেট করার দরকার নেই, কোনও নতুন সেট-পদ্ধতিতে আপনি এই কোডটি যুক্ত করতে ভুলবেন না তা নিশ্চিত করার প্রয়োজন নেই। অতিরিক্তভাবে আপনার কেবল পয়েন্টকুট দরকার:
pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);
ওটার মানে কি? এর অর্থ যদি কোনও পদ্ধতির নাম দেওয়া হয় তবে "সেট *" (* অর্থ কোনও নাম সেট পরে অনুসরণ করতে পারে), পদ্ধতিটি কী ফিরে আসে তা বিবেচনা না করে (প্রথম তারকাচিহ্ন) বা কোন প্যারামিটার নেয় (তৃতীয় তারকাচিহ্ন) এবং এটি মাইগ্রাফিকসক্লাসের একটি পদ্ধতি এবং এটি বর্গটি "com.company। *" প্যাকেজের অংশ, তারপরে এটি একটি সেট () পয়েন্টকাট। এবং আমাদের প্রথম কোড বলে " পরে কোনো পদ্ধতি একটি সেট pointcut যে চলমান, নিম্নলিখিত কোড চালানোর"।
দেখুন কীভাবে এওপি মার্জিতভাবে সমস্যাটি এখানে সমাধান করে? আসলে এখানে বর্ণিত সমস্ত কিছুই সংকলন সময়ে করা যেতে পারে। একটি এওপি প্রিপ্রোসেসর ক্লাস নিজেই সংকলন করার আগে আপনার উত্সটি (যেমন প্রতিটি সেট-পয়েন্টকুট পদ্ধতির শেষে প্রদর্শন.আপডেট () যুক্ত করে) পরিবর্তন করতে পারে।
যাইহোক, এই উদাহরণটি এওপি-র অন্যতম বৃহত ডাউনসাইডও দেখায়। এওপি আসলে এমন কিছু করছে যা অনেক প্রোগ্রামার একটি " অ্যান্টি-প্যাটার্ন " বিবেচনা করে। সঠিক প্যাটার্নটিকে বলা হয় " দূরত্বের অ্যাকশন "।
দূরত্বে অ্যাকশন হ'ল একটি অ্যান্টি-প্যাটার্ন (স্বীকৃত সাধারণ ত্রুটি) যার মধ্যে প্রোগ্রামের এক অংশের আচরণটি প্রোগ্রামের অন্য অংশে ক্রিয়াকলাপ চিহ্নিত করতে অসুবিধা বা অসম্ভবের উপর ভিত্তি করে বন্যভাবে পরিবর্তিত হয়।
কোনও প্রকল্পের নবাগত হিসাবে, আমি কেবল কোনও সেট-পদ্ধতির কোডটি পড়তে পারি এবং এটি ভাঙ্গা বিবেচনা করতে পারি, কারণ মনে হয় এটি আপডেটটি আপডেট করে না। আমি কেবল একটি সেট-পদ্ধতির কোডটি দেখেই দেখছি না , এটি কার্যকর করার পরে, অন্য কিছু কোড প্রদর্শনটি আপডেট করার জন্য "ম্যাজিকালি" কার্যকর করা হবে। আমি এটাকে মারাত্মক খারাপ দিক বিবেচনা করি! কোনও পদ্ধতিতে পরিবর্তন করে অদ্ভুত বাগগুলি প্রবর্তিত হতে পারে। কোডের প্রবাহের আরও বোঝা যেখানে নির্দিষ্ট জিনিসগুলি সঠিকভাবে কাজ করছে বলে মনে হয় তবে তা স্পষ্ট নয় (যেমন আমি বলেছি, তারা কেবল যাদুতে কাজ করে ... কোনওভাবে) সত্যই শক্ত is
হালনাগাদ
কেবল এটি স্পষ্ট করতে: কিছু লোকের ধারণা থাকতে পারে যে আমি বলছি এওপিটি খারাপ কিছু এবং এটি ব্যবহার করা উচিত নয়। আমি যা বলছি তা নয়! এওপি আসলে একটি দুর্দান্ত বৈশিষ্ট্য। আমি কেবল "এটি সাবধানে ব্যবহার করুন" বলি। যদি আপনি একই জন্য স্বাভাবিক কোড এবং Aop তালগোল Aop শুধুমাত্র সমস্যার সৃষ্টি হবে অ্যাসপেক্ট । উপরের উদাহরণে, আমাদের গ্রাফিকাল অবজেক্টের মানগুলি আপডেট করার এবং আপডেট হওয়া বস্তুর পেইন্টিংয়ের দিক রয়েছে। এটি আসলে একক দিক। এর অর্ধেকটি স্বাভাবিক কোড হিসাবে কোডিং এবং এর অর্ধেক অংশটি দিকটি হিসাবে সমস্যাটি যুক্ত করে।
আপনি যদি সম্পূর্ণ ভিন্ন দিক হিসাবে এওপি ব্যবহার করেন, যেমন লগিংয়ের জন্য, আপনি অ্যান্টি-প্যাটার্ন সমস্যাটিতে চলে যাবেন না। সেক্ষেত্রে এই প্রকল্পের একজন নবাবী ভাবতে পারেন "এই সমস্ত লগ বার্তা কোথা থেকে এসেছে? আমি কোডটিতে কোনও লগ আউটপুট দেখি না", তবে এটি কোনও বিশাল সমস্যা নয়। তিনি প্রোগ্রাম লজিকের যে পরিবর্তনগুলি করেছেন তা খুব কমই লগ সুবিধাটি ভেঙে দেবে এবং লগ সুবিধার পরিবর্তনগুলি তার প্রোগ্রামের যুক্তি খুব কমই ভেঙে ফেলবে - এই দিকগুলি সম্পূর্ণ আলাদা হয়ে গেছে। লগিংয়ের জন্য এওপি ব্যবহার করার সুবিধা রয়েছে যে আপনার প্রোগ্রাম কোডটি যা করা উচিত তা পুরোপুরি মনোনিবেশ করতে পারে এবং আপনার কোডটি কোথাও শত শত লগ বার্তা দ্বারা বিশৃঙ্খলা না করেই পরিশীলিত লগিং করতে পারে। এছাড়াও যখন নতুন কোড প্রবর্তন করা হবে, সঠিকভাবে সঠিক সামগ্রী সহ সঠিক সময়ে ম্যাজিকালি লগ বার্তা উপস্থিত হবে।
সুতরাং আমার উদাহরণে এওপির একটি ভাল ব্যবহার হ'ল সর্বদা লগ করা যদি কোনও সেট কোনও পদ্ধতির মাধ্যমে কোনও মান আপডেট করা থাকে। এটি কোনও অ্যান্টি-প্যাটার্ন তৈরি করবে না এবং খুব কমই কোনও সমস্যার কারণ হতে পারে।
কেউ বলতে পারেন, আপনি যদি এতগুলি সমস্যা তৈরি করতে সহজেই এওপিকে অপব্যবহার করতে পারেন তবে এটি সমস্ত ব্যবহার করা খারাপ ধারণা। তবে কোন প্রযুক্তিটি অপব্যবহার করা যাবে না? আপনি ডেটা এনকেপুলেশন অপব্যবহার করতে পারেন, উত্তরাধিকার অপব্যবহার করতে পারেন। খুব দরকারী প্রতিটি দরকারী প্রোগ্রামিং প্রযুক্তি অপব্যবহার করা যেতে পারে। একটি প্রোগ্রামিং ভাষা এত সীমিত বিবেচনা করুন যে এতে কেবল এমন বৈশিষ্ট্য রয়েছে যা অপব্যবহার করা যায় না; এমন একটি ভাষা যেখানে বৈশিষ্ট্যগুলি কেবল তখনই ব্যবহার করা যেতে পারে কারণ সেগুলি প্রাথমিকভাবে ব্যবহারের উদ্দেশ্যে করা হয়েছিল। এই জাতীয় ভাষা এতই সীমিত হবে যে এটি বিতর্কযোগ্য যদি এটি বাস্তব বিশ্বের প্রোগ্রামিংয়ের জন্যও ব্যবহার করা যায়।