Code Smell বা বাজে কোড

Code Smell বা বাজে কোড বোঝার কিছু প্যাটার্ন আছে যা দেখে বোঝা যায়। এখানে এই সম্পর্কে কিছু ধারনা দেয়া হল। code smell সাধারনত ২ ভাগে বিভক্ত।

Code smells between classes

দুই বা ততোধিক ক্লাসের মধ্যে সাধারনত কি ধরনের কোড স্মেল হয়ে থাকে এখানে তাই বর্ননা করা হয়েছে। নাম গুলি ইংরেজিতেই রাখা আছে যাতে সরাসরি ইংরেজি নাম দিয়ে গুগল করলেই সব ধরনের রিসোর্স পাওয়া যায়।

Alternative classes with different interfaces: দুইটা মানুষের ভিতরে সবকিছুই এক, শুধু চেহারা ছাড়া মানে যদি দুইটা ক্লাসের ভেতরের স্ট্রাকচার একই হয় কিন্তু বাহিরের আউটলুক ভিন্ন হয় বা যদি ইন্টারফেস আলাদা হয়, সেক্ষেত্রে দুইটা ক্লাসই একটা ইন্টারফেস শেয়ার করতে পারে।

Primitive obsession: বোকার মত যদি অনেকগুলা বেসিক ডেটা টাইপ ব্যবহার করা খুবই যন্ত্রনার। যদি ডেটা টাইপ জটিলতর ও কুটিলতর হয় তখন ক্লাস ব্যবহার করা ভাল।

Data class: যে সব ক্লাস ডেটা স্টোর করে, সে সব ক্লাস এড়ানো উচিত। ক্লাস তো আর ডেটাবেজ না। ডেটা যদি স্টোর করতেই হইতো তাইলে তো ডেটাবেজ ব্যবহার করাই যায়। ক্লাসের ক্ষেত্রে ডেটা থাকবে এবং তা মেথডের মাধ্যমে ব্যবহার করতে হবে।

Data clumps: যদি এক প্লেটে ২জন ভাত খায়, তখন তাদেরকে উচিত আলাদা প্লেট করে দেয়া। মানে যদি একটা ডেটা দুইটি ভিন্ন ক্লাসে ব্যবহৃত হয়, তখন ঐ ডেটা আসলে দুইটা ক্লাসেরই সম্পদ। তাদেরকে উচিত আলাদা করে দেয়া যাতে বারবার কল দিয়ে ডেটা আনা নেয়া করা না লাগে। এতে কম্পেক্সিটি অনেক কমে যায়।

Refuse bequest: যদি আমি মাটি দিয়ে খেলনা বানাই, কিন্তু খেলার সময় খেলনা থেকে মাটি আলাদা করে নিয়ে খেলি, তাহলে খেলনা বানানোর কি কোন দরকার আছে? যদি একটা ক্লাসকে অন্য একটা ক্লাস থেকে ইনহেরিট করা হয় এবং ঐ ক্লাসের ইনহেরিটেড ফাংশনালিটি ব্যবহার করা না হয়, তাহলে ইনহেরিট করা কি জরুরি?

Inappropriate intimacy: একটা ক্লাসের সাথে অন্য একটা ক্লাসের প্রেম ভালবাসা থাকাটা অতিমাত্রায় খারাপ। মানে যদি একটা ক্লাসের কোন কিছুর দরকার হলেই অন্য একটা ক্লাস শুধুমাত্র একটা ক্লাসের কাছেই কল দেয়। একটা ক্লাস অন্য একটা ক্লাস সম্পর্কে যত কম জানে, ততই ভাল।

Indecent exposure: যদি একটা ক্লাস তার ভিতরে সবকিছুই বাহিরের কাছে উন্মুক্ত করে রাখে মানে প্রাইভেসি না থাকে তখন সেটা অনেক সমস্যার জন্ম দেয়। ক্লাসের ভেতরের জিনিস প্রাইভেট রাখতে হয়। ভেতরে কি হচ্ছে তা বাহিরের মানুষকে জানানোর দরকার নাই। কি কি বাহিরে দেখাবে তা নির্দিষ্ট করা উচিত।

Feature envy: যদি একটা মেথড কিছু হইলেই অন্য আরেকটা ক্লাসের মেথডের দিকে চোখ তুলে তাকায়ে থাকে, তখন তাকে ঐ ক্লাসেই পাঠায়ে দেয়া ভাল।

Lazy class: এমনিতেই বাড়তি ক্লাস প্রজেক্টকে স্লো করে দেয়, তার উপর কমপ্লেক্সিটি। যদি এমন ক্লাস থাকে যেটা কোন কাজ করে না, বা খুব আরামেই তার কাজ অন্য কোন ক্লাসকে হস্তান্তর করা যায়, তাইলে ঐ ক্লাস ফেলে দিতে হবে।

Message chains: যদি কোন মেথডকে ১০ বাড়ি ঘুরে কোন রেজাল্ট নিয়ে আসতে হয় মানে অনেক গুলা ক্লাসের মাধ্যমে এক্সিকিউট করা লাগে, তখন তাদের মধ্যে নির্ভরশীলতা তৈরি হয়।

Middle man: যদি একটা ক্লাস কোন কাজ না করে শুধু তার কাজগুলা অন্য ক্লাস কে কল করে করায়ে নেয়, ভাল হচ্ছে তাকে ধাক্কা দিয়ে বিদেয় করে দেয়া।

Divergent change: যদি কোন ক্লাসে মাথায় হাত দিলে পায়ে ব্যাথা পায় মানে ক্লাসের একটা অংশে পরিবর্তন করলে অন্য ফাংশনালিটির মাথা খারাপ হয়ে যায়, তখন তাদেরকে ছোট ছোট ভাগে ভাগ করে অন্য ক্লাসে নিয়ে যাওয়া উচিত।

Shotgun surgery: যদি একটা ক্লাসে কোন পরিবর্তন আনতে হলে অন্যান্য অনেক ক্লাসেও পরিবর্তন করতে হয়, তখন ঐ পরিবর্তন টা যাতে শুধু একটা ক্লাসেই হয় সেই ব্যবস্থা করতে হবে।

Parallel inheritance hierarchies: যদি একটা ক্লাসের সাবক্লাস তৈরি করতে হলে অন্য আরও অনেক ক্লাসের সাবক্লাস তৈরি করতে হয়, তখন ইনহেরিটেন্স টাকে একটা ক্লাসেই সীমাবদ্ধ করতে হবে।

Incomplete library: ধরি আমরা কোন লাইব্রেরি ব্যবহার করতেছি যেটাতে আমরা যে মেথডটা চাই ঐটা নাই, আবার আমরা লাইব্রেরি বদলাতে পারতেছিনা বা চাচ্ছিনা। আমরা যদি লাইব্রেরি এডিট বা আপডেট করতে না পারি, তখন ঐ মেথডটাকে একটা আলাদা ক্লাসে নিয়ে কাজ করতে হবে।

Solution sprawl: যদি একটা কাজ করতে ৫ টা ক্লাসের কাছে যেতে হয়, তার মানে প্রচুর ঘাপলা আছে। পরে আমাকে কিছু পরিবর্তন করতে হলেও ঐ ৫ টা ক্লাসে করতে হবে। আবার ঐ ৫টা ক্লাসের কোন ১টাতেও কিছু পরিবর্তন করলে আমার ঐ কাজে সমস্যা দেখা দিবে। তখন আমার ডিজাইন টাকে আরও সহজ করতে হবে নয়তো ঐ ক্লাসগুলোকে ১টা বিশাল ক্লাসে নিয়ে আসতে হবে।

Facebook Comments