SOLID হল রক্ষণাবেক্ষণযোগ্য, নমনীয় OOP সিস্টেম তৈরির জন্য পাঁচটি ডিজাইন নীতি। প্রতিটি কঠোর, ভঙ্গুর কোডের একটি সাধারণ কারণকে সম্বোধন করে।
| অক্ষর | নীতি | এক-লাইন অর্থ |
|---|
| S | Single Responsibility | একটি শ্রেণীর পরিবর্তনের একটি কারণ থাকা উচিত |
| O | Open/Closed | সম্প্রসারণের জন্য খোলা, পরিবর্তনের জন্য বন্ধ |
| L | Liskov Substitution | সাব-টাইপগুলি অবশ্যই যেকোনো জায়গায় ব্যবহারযোগ্য হবে যেখানে বেস টাইপ আছে |
| I | Interface Segregation | একটি মোটা ইন্টারফেসের চেয়ে অনেক ছোট ইন্টারফেস ভাল |
| D | Dependency Inversion | কংক্রিট ক্লাসের পরিবর্তে বিমূর্তকরণের উপর নির্ভর করুন |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService ইমেলের উপর নির্ভর করে না — এটি স্পর্শ না করে SMS বা একটি পরীক্ষা ডাবলে সুইচ করুন (D)। একটি নতুন notifier টাইপ যোগ করার জন্য OrderService-এ কোনো পরিবর্তনের প্রয়োজন নেই (O)।
SOLID নির্দেশনা, আইন নয়। এটি অতিরিক্ত প্রয়োগ করা — প্রতি ক্লাসে একটি ইন্টারফেস, সর্বত্র পরোক্ষতা — "বিমূর্তকরণ স্যুপ" তৈরি করে যা এটি যে সমস্যার সমাধান করেছে তার চেয়ে অনুসরণ করা কঠিন।
SOLID একটি ভাগ করা ডায়াগনস্টিক ভাষা দেয়: পর্যালোচকরা কেন একটি শ্রেণী পরিবর্তন করা কঠিন তার নাম দিতে পারে ("এটি SRP লঙ্ঘন করে") স্বাদের উপর তর্ক করার পরিবর্তে।
বিচারের সাথে প্রয়োগ করা হলে, নীতিগুলি লহর প্রভাব হ্রাস করে — পরিবর্তনগুলি স্থানীয় থাকে, নতুন বৈশিষ্ট্যগুলি পুনরায় লেখার পরিবর্তে সম্প্রসারিত হয় এবং পরীক্ষাগুলি প্রকৃত নির্ভরতার জন্য নকল প্রতিস্থাপন করতে পারে।
বিস্তারিত উত্তরসহ IT ইন্টারভিউ প্রশ্নের একটি লাইব্রেরি — জুনিয়র থেকে সিনিয়র পর্যন্ত।
দান করুন