সফটওয়্যার ডেভেলপমেন্টে ডিজাইন প্রিন্সিপলস একটু বহুল আলোচিত ও গুরুত্বপুর্ন একটি শব্দ। সাধারনত ডিজাইন প্রিন্সিপালস বলতে বোঝানো হয় একগুচ্ছ গাইডলাইন বা নিয়ম কানুন যেগুলো মেনে কোড লিখলে বাজে ডিজাইন এড়ানো যায়। প্রশ্ন আসতে পারে যে একটি ডিজাইন কখন বাজে হতে পারে। ধরে নেই, কোন একটি সফটওয়্যারের ডেভেলপমেন্ট চলছে। মাঝপথে একটি নতুন ফিচার ইম্প্লিমেন্ট করতে গিয়ে দেখা গেল যে কোন একটি ক্লাসের একটি মেথডের সিগনেচার (মেথডের নাম, আর্গুমেন্ট গুলোর নাম, ডাটাটাইপ, সংখ্যা) পরিবর্তন করতে হবে। কিন্তু ইতিমধ্যে প্রায় ১০০ জায়গায় এই মেথডটি ব্যবহার করা হয়েছে। তার মানে এখন ওই ১০০ জায়গার মেথড কল করার সময় সিগনেচার পরিবর্তন করে দিয়ে আসতে হবে। অথবা ওই ক্লাসে নতুন একটি মেথড তৈরী করতে হবে। এটাকেই বাজে ডিজাইন বলা হচ্ছে। কারন নতুন একটি ফিচার ইমপ্লিমেন্ট করলে যদি আগের ইমপ্লিমেন্ট করা অন্যান্য ফিচারে বাজে প্রভাব ফেলে তাহলে ওই ডেভেলপমেন্টে সঠিক আর্কিটেকচার বা ডিজাইন মেনে কোড করা হয় নি বলেই ধরে নেওয়া হয়। রবার্ট মার্টিন (Robert Martin) নিজ লেখা বই “Agile Software Development: Principles, Patterns, and Practices” এ ডিজাইন প্রিন্সিপাল গুলো সম্পর্কে লিখেছেন।
রবার্ট মার্টিন এর মতে খারাপ বা বাজে ডিজাইন এর নিচের ৩ টি বৈশিষ্ট্য থাকে।
- রিজিডিটি (Rigidity) : কোডে কোন অংশের পরিবর্তন যদি সিস্টেমের অন্য অনেক জায়গায় প্রভাব ফেলে তাহলে পরিবর্তন করা ব্যয়বহুল হয়ে পড়ে।
- ফ্রা্গিলিটি (Fragility) : কোডের কোন অংশের পরিবর্তন যদি সিস্টেমের অন্য কোন ফিচার কে অনাকাঙ্খিত হবে অকেজো করে দেয়।
- ইমোবিলিটি (Immobility) : কোডের অংশ এমনভাবে অ্যাপলিকেশন নির্ভর যে, অন্য কোন অ্যাপ্লিকেশনে কোডটুকু ব্যবহার করা কঠিন হয়।
সাধারন নিচের পাঁচটি নিয়ম মেনে কোড করলে উপরের বর্নিত সমস্যাগুলো এড়ানো যায়।
১। ওপেন ক্লোজ নীতি (Open Close Principle)
২। ডিপেন্ডেন্সি ইনভার্সন নীতি (Dependency Inversion Principle)
৩। ইন্টারফেস সেগ্রেগেশন নীতি (Interface Segregation Principle)
৪। সিঙ্গেল রেসপনসিবিলিটি নীতি (Single Responsibility Principle)
৫। লিসকভ’স সাবস্টিটিউশন নীতি (Liskov’s Substitution Principle)
পাঁচটি প্রিন্সিপালের বর্ননা পরের পোস্ট গুলোতে দেওয়া হবে। এরা প্রত্যেকেই আলাদা আলাদা পোস্টের দাবীদার। 🙂
ভাই পরবর্তী পোস্টগুলা কুতায়?