আমি একটি প্রকল্প পেয়েছি। এই প্রকল্পে আমি এটিতে কোনও বৈশিষ্ট্য যুক্ত করতে পুনরায় চুলক করতে চেয়েছিলাম এবং বৈশিষ্ট্যটি যুক্ত করার জন্য আমি প্রকল্পটি রিফেক্টর করেছি।
সমস্যাটি হ'ল যখন আমার কাজ শেষ হয়েছিল, তখন দেখা গেল যে এটির জন্য আমার একটি ছোটখাটো ইন্টারফেস পরিবর্তন করা দরকার। তাই আমি পরিবর্তন করেছি। এবং তারপরে গ্রাহক বর্গটি তার বর্তমান ইন্টারফেসের সাথে নতুনটির ক্ষেত্রে প্রয়োগ করা যাবে না, সুতরাং এটির জন্য একটি নতুন ইন্টারফেসও প্রয়োজন। এখন এটি তিন মাস পরে, এবং আমাকে অগণিত কার্যত সম্পর্কহীন সমস্যাগুলি সমাধান করতে হয়েছিল এবং আমি এখন থেকে এক বছর ধরে রোডম্যাপ করা সমস্যাগুলি সমাধান করার দিকে লক্ষ্য করছি বা জিনিসটি সংকলনের আগে অসুবিধার কারণে ঠিক সমাধান করা হবে না বলে তালিকাবদ্ধ করছি আবার।
ভবিষ্যতে আমি কীভাবে এই জাতীয় ক্যাসকেডিং রিফ্যাক্টরিংগুলি এড়াতে পারি? একে অপরের উপর খুব দৃly়তার সাথে নির্ভর করে এটি কি আমার পূর্ববর্তী ক্লাসগুলির একটি লক্ষণ?
সংক্ষিপ্ত সম্পাদনা: এই ক্ষেত্রে, রিফ্যাক্টরটি বৈশিষ্ট্য ছিল , যেহেতু রিফ্যাক্টর একটি নির্দিষ্ট কোডের কোডের এক্সটেনসিবিলিটি বৃদ্ধি করেছিল এবং কিছু সংযোগকে হ্রাস করেছে। এর অর্থ হ'ল বহিরাগত বিকাশকারীরা আরও বেশি কিছু করতে পারে, এটিই আমি বৈশিষ্ট্যটি সরবরাহ করতে চেয়েছিলাম। সুতরাং মূল রিফ্যাক্টরটি নিজেই কার্যকরী পরিবর্তন হওয়া উচিত ছিল না।
পাঁচ দিন আগে আমি প্রতিশ্রুতিবদ্ধ বড় সম্পাদনা:
আমি এই রিফ্যাক্টরটি শুরুর আগে আমার একটি সিস্টেম ছিল যেখানে আমার একটি ইন্টারফেস ছিল, তবে বাস্তবায়নের ক্ষেত্রে, আমি dynamic_castযে সমস্ত সম্ভাব্য প্রয়োগগুলি প্রেরণ করেছি কেবল তার মাধ্যমেই। এর স্পষ্টতই বোঝানো হয়েছিল যে আপনি কেবলমাত্র একটি জিনিসের জন্য এবং ইন্টারফেস থেকে উত্তরাধিকার সূচনা করতে পারেন নি, এই ইন্টারফেসটি বাস্তবায়নের অ্যাক্সেস ছাড়া কারও পক্ষে এটি অসম্ভব হবে। সুতরাং আমি স্থির করেছিলাম যে আমি এই সমস্যাটি সমাধান করতে চাইছি এবং জনসাধারণের ব্যবহারের জন্য ইন্টারফেসটি খুলতে চাইছি যাতে যে কেউ এটি বাস্তবায়ন করতে পারে এবং ইন্টারফেসটি বাস্তবায়ন করা সম্পূর্ণ চুক্তির জন্য প্রয়োজনীয় ছিল - স্পষ্টতই একটি উন্নতি হয়েছিল।
আমি যখন এই জায়গাটি করেছিলাম সেই সমস্ত জায়গাগুলি আমি যখন সন্ধান করছিলাম এবং আগুন দিয়ে হত্যা করছিলাম তখন আমি একটি জায়গা পেয়েছি যা একটি বিশেষ সমস্যা হিসাবে প্রমাণিত হয়েছিল। এটি ইতিমধ্যে প্রয়োগ করা হয়েছে তবে অন্য কোথাও আরও ভাল বিভিন্ন ডেরাইভ ক্লাস এবং নকল কার্যকারিতা বাস্তবায়নের বিশদ উপর নির্ভর করে। এটি পরিবর্তে পাবলিক ইন্টারফেসের ক্ষেত্রে প্রয়োগ করা যেতে পারে এবং সেই কার্যকারিতাটির বিদ্যমান প্রয়োগটি পুনরায় ব্যবহার করা যেতে পারে। আমি আবিষ্কার করেছি যে সঠিকভাবে কাজ করতে এটির একটি নির্দিষ্ট প্রসঙ্গের প্রয়োজন। মোটামুটিভাবে বলতে গেলে, কলিংয়ের পূর্ববর্তী বাস্তবায়নটি দেখতে বেশ দয়ালু
for(auto&& a : as) {
f(a);
}
যাইহোক, এই প্রসঙ্গটি পেতে, আমার এটিকে আরও ভালো কিছুতে পরিবর্তন করা দরকার
std::vector<Context> contexts;
for(auto&& a : as)
contexts.push_back(g(a));
do_thing_now_we_have_contexts();
for(auto&& con : contexts)
f(con);
এর অর্থ হ'ল যে সমস্ত ক্রিয়াকলাপের একটি অংশ হিসাবে ব্যবহৃত হত fতাদের জন্য কিছুকে নতুন ফাংশনের একটি অংশ তৈরি করা দরকার যা gপ্রসঙ্গ ছাড়াই পরিচালিত হয় এবং তাদের কিছুকে এখন-পিছিয়ে যাওয়া অংশের তৈরি করা দরকার f। তবে সমস্ত পদ্ধতির fপ্রয়োজন হয় না বা এই প্রসঙ্গটি চান না - তাদের কারও কারও স্বতন্ত্র প্রসঙ্গ প্রয়োজন যা তারা পৃথক উপায়ে অর্জন করেন। সুতরাং fকলিংয়ে শেষ হওয়া সমস্ত কিছুর জন্য (যা মোটামুটিভাবে বলা যায়, বেশ কিছু সবকিছু ), আমি তাদের নির্ধারণ করতে হয়েছিল যে তাদের প্রসঙ্গটি কী দরকার, তাদের এটি কোথায় থেকে পাওয়া উচিত এবং কীভাবে তাদেরকে পুরানো fথেকে নতুন fএবং নতুনতে ভাগ করা যায়? g।
আমি এখন যেখানে আছি সেখানেই শেষ হয়ে গেল। আমি যাচ্ছি কেবলমাত্র কারণ হ'ল যাইহোক আমার অন্যান্য কারণে এই রিফ্যাক্টরিংয়ের প্রয়োজন ছিল needed