একক দায়িত্ব নীতি। যতটা সহজ মনে হয় ততটা নয়

একক দায়িত্ব নীতি, একক দায়িত্ব নীতি হিসাবেও পরিচিত,
ওরফে ইউনিফর্ম পরিবর্তনশীলতার নীতি - বোঝার জন্য অত্যন্ত পিচ্ছিল লোক এবং একজন প্রোগ্রামার সাক্ষাত্কারে এমন একটি স্নায়বিক প্রশ্ন।

এই নীতির সাথে আমার প্রথম গুরুতর পরিচিতি প্রথম বছরের শুরুতে ঘটেছিল, যখন তরুণ এবং সবুজদেরকে লার্ভা থেকে ছাত্র তৈরি করতে বনে নিয়ে যাওয়া হয়েছিল - প্রকৃত ছাত্র।

বনে, আমরা প্রত্যেকে 8-9 জনের দলে বিভক্ত হয়েছিলাম এবং একটি প্রতিযোগিতা ছিল - কোন দলটি দ্রুততম বোতল ভদকা পান করবে, তবে শর্ত থাকে যে গ্রুপের প্রথম ব্যক্তি একটি গ্লাসে ভদকা ঢেলে দেয়, দ্বিতীয়টি এটি পান করে, এবং তৃতীয় একটি জলখাবার আছে. যে ইউনিটটি তার ক্রিয়াকলাপ সম্পূর্ণ করেছে তা গ্রুপের সারির শেষে চলে যায়।

যে ক্ষেত্রে সারির আকার তিনটির গুণিতক ছিল তা SRP-এর একটি ভাল বাস্তবায়ন ছিল।

সংজ্ঞা 1. একক দায়িত্ব।

একক দায়বদ্ধতা নীতির (এসআরপি) অফিসিয়াল সংজ্ঞা বলে যে প্রতিটি সত্তার নিজস্ব দায়িত্ব এবং অস্তিত্বের কারণ রয়েছে এবং এটির শুধুমাত্র একটি দায়িত্ব রয়েছে।

"পানীয়" বস্তুটি বিবেচনা করুন (টিপলার).
এসআরপি নীতি বাস্তবায়নের জন্য, আমরা দায়িত্বগুলিকে তিনটি ভাগে ভাগ করব:

• এক ঢালা (পোরঅপারেশন)
• একটি পানীয় (ড্রিংকআপ অপারেশন)
• একজনের জলখাবার আছে (টেকবাইট অপারেশন)

প্রক্রিয়ার প্রতিটি অংশগ্রহণকারী প্রক্রিয়াটির একটি উপাদানের জন্য দায়ী, অর্থাৎ, একটি পারমাণবিক দায়িত্ব রয়েছে - পান করা, ঢালা বা জলখাবার।

পানীয় গর্ত, ঘুরে, এই অপারেশনগুলির জন্য একটি সম্মুখভাগ:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

কেন?

মানব প্রোগ্রামার বানর-মানুষের জন্য কোড লেখেন, এবং বানর-মানুষ অমনোযোগী, মূর্খ এবং সর্বদা তাড়াহুড়ো করে। তিনি এক সময়ে প্রায় 3 - 7 পদ ধরে রাখতে এবং বুঝতে পারেন।
একজন মাতালের ক্ষেত্রে এই তিনটি পদ আছে। যাইহোক, যদি আমরা একটি শীট দিয়ে কোড লিখি, তবে তাতে থাকবে হাত, চশমা, মারামারি এবং রাজনীতি নিয়ে অন্তহীন তর্ক। আর এসবই হবে এক পদ্ধতির বডিতে। আমি নিশ্চিত যে আপনি আপনার অনুশীলনে এই জাতীয় কোড দেখেছেন। মানসিকতার জন্য সবচেয়ে মানবিক পরীক্ষা নয়।

অন্যদিকে, বানর মানুষটিকে তার মাথায় বাস্তব বিশ্বের বস্তু অনুকরণ করার জন্য ডিজাইন করা হয়েছে। তার কল্পনায়, তিনি তাদের একসাথে ঠেলে দিতে পারেন, তাদের থেকে নতুন বস্তু একত্রিত করতে পারেন এবং একইভাবে তাদের বিচ্ছিন্ন করতে পারেন। একটি পুরানো মডেলের গাড়ি কল্পনা করুন। আপনার কল্পনায়, আপনি দরজাটি খুলতে পারেন, দরজার ছাঁটা খুলতে পারেন এবং সেখানে উইন্ডো লিফ্ট মেকানিজম দেখতে পারেন, যার ভিতরে গিয়ার থাকবে। কিন্তু আপনি একটি "তালিকা" এ একই সময়ে মেশিনের সমস্ত উপাদান দেখতে পারবেন না। অন্তত "বানর মানুষ" পারে না।

অতএব, মানব প্রোগ্রামাররা জটিল প্রক্রিয়াগুলিকে কম জটিল এবং কার্যকরী উপাদানগুলির একটি সেটে পচিয়ে দেয়। যাইহোক, এটি বিভিন্ন উপায়ে পচে যেতে পারে: অনেক পুরানো গাড়িতে, বায়ু নালী দরজায় যায় এবং আধুনিক গাড়িগুলিতে, লক ইলেকট্রনিক্সের ব্যর্থতা ইঞ্জিনকে শুরু হতে বাধা দেয়, যা মেরামতের সময় একটি সমস্যা।

এখন, SRP হল একটি নীতি যা ব্যাখ্যা করে কিভাবে পচতে হয়, অর্থাৎ কোথায় বিভাজক রেখা আঁকতে হয়.

তিনি বলেছেন যে "দায়িত্ব" এর বিভাজনের নীতি অনুসারে পচন করা প্রয়োজন, অর্থাৎ নির্দিষ্ট বস্তুর কাজ অনুসারে।

আসুন মদ্যপানে ফিরে আসি এবং পচনের সময় বানর মানুষ যে সুবিধাগুলি পায়:

• কোড প্রতিটি স্তরে অত্যন্ত স্পষ্ট হয়ে উঠেছে
• কোডটি একসাথে একাধিক প্রোগ্রামার দ্বারা লিখতে পারে (প্রতিটি একটি পৃথক উপাদান লেখে)
• স্বয়ংক্রিয় পরীক্ষা সরলীকৃত - উপাদান যত সহজ, পরীক্ষা করা তত সহজ
• কোডের সংমিশ্রণ উপস্থিত হয় - আপনি প্রতিস্থাপন করতে পারেন ড্রিংকআপ অপারেশন একটি অপারেশন যেখানে একজন মাতাল টেবিলের নিচে তরল ঢেলে দেয়। অথবা ঢালা অপারেশনটি একটি অপারেশন দিয়ে প্রতিস্থাপন করুন যেখানে আপনি ওয়াইন এবং জল বা ভদকা এবং বিয়ার মিশ্রিত করুন। ব্যবসার প্রয়োজনীয়তার উপর নির্ভর করে, আপনি পদ্ধতি কোড স্পর্শ না করেই সবকিছু করতে পারেন টিপলার.অ্যাক্ট.
• এই অপারেশনগুলি থেকে আপনি পেটুক ভাঁজ করতে পারেন (কেবল ব্যবহার করে TakeBitOperation), অ্যালকোহলিক (শুধুমাত্র ব্যবহার করে ড্রিংকআপ অপারেশন সরাসরি বোতল থেকে) এবং অন্যান্য অনেক ব্যবসার প্রয়োজনীয়তা পূরণ করুন।

(ওহ, মনে হচ্ছে এটি ইতিমধ্যেই একটি OCP নীতি, এবং আমি এই পোস্টের দায়িত্ব লঙ্ঘন করেছি)

এবং, অবশ্যই, অসুবিধাগুলি:

• আমরা আরো ধরনের তৈরি করতে হবে.
• একজন মাতাল প্রথমবার পান করে তার চেয়ে কয়েক ঘণ্টা পরে।

সংজ্ঞা 2. ইউনিফাইড পরিবর্তনশীলতা।

আমাকে অনুমতি দিন, ভদ্রলোক! মদ্যপানকারী শ্রেণীরও একক দায়িত্ব আছে - এটি পান করে! এবং সাধারণভাবে, "দায়িত্ব" শব্দটি একটি অত্যন্ত অস্পষ্ট ধারণা। কেউ মানবতার ভাগ্যের জন্য দায়ী, এবং কেউ মেরুতে উল্টে যাওয়া পেঙ্গুইনদের উত্থাপনের জন্য দায়ী।

আসুন পানকারীর দুটি বাস্তবায়ন বিবেচনা করি। উপরে উল্লিখিত প্রথমটিতে তিনটি শ্রেণী রয়েছে - ঢালা, পানীয় এবং জলখাবার।

দ্বিতীয়টি "ফরোয়ার্ড এবং অনলি ফরোয়ার্ড" পদ্ধতির মাধ্যমে লেখা হয়েছে এবং পদ্ধতিতে সমস্ত যুক্তি রয়েছে আইন:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
сlass BrutTippler {
   //...
   void Act(){
        // наливаем
    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))
        throw new OverdrunkException();

    // выпиваем
    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))
        throw new OverdrunkException();

    //Закусываем
    for(int i = 0; i< 3; i++){
        var food = _foodStore.TakeOrDefault();
        if(food==null)
            throw new FoodIsOverException();

        _hand.TryEat(food);
    }
   }
}

এই উভয় শ্রেণী, বাইরের পর্যবেক্ষকের দৃষ্টিকোণ থেকে, দেখতে হুবহু একই এবং "পান" এর একই দায়িত্ব ভাগ করে নেয়।

বিভ্রান্তি !

তারপরে আমরা অনলাইনে যাই এবং SRP-এর আরেকটি সংজ্ঞা খুঁজে পাই - একক পরিবর্তনযোগ্যতা নীতি।

SCP বলে যে "একটি মডিউল পরিবর্তন করার জন্য একটি এবং শুধুমাত্র একটি কারণ আছে" অর্থাৎ, "দায়িত্ব পরিবর্তনের একটি কারণ।"

(মনে হচ্ছে যে ছেলেরা আসল সংজ্ঞা নিয়ে এসেছেন তারা বনমানুষের টেলিপ্যাথিক দক্ষতায় আত্মবিশ্বাসী ছিলেন)

এখন সবকিছু জায়গায় পড়ে। আলাদাভাবে, আমরা ঢালা, মদ্যপান এবং স্ন্যাকিংয়ের পদ্ধতিগুলি পরিবর্তন করতে পারি, কিন্তু মদ্যপানকারীর মধ্যেই আমরা শুধুমাত্র ক্রিয়াকলাপের ক্রম এবং গঠন পরিবর্তন করতে পারি, উদাহরণস্বরূপ, পান করার আগে জলখাবার সরানো বা টোস্টের পাঠ যোগ করে।

"ফরোয়ার্ড এবং অনলি ফরোয়ার্ড" পদ্ধতিতে, যা কিছু পরিবর্তন করা যায় তা শুধুমাত্র পদ্ধতিতে পরিবর্তন করা হয় আইন. এটি পঠনযোগ্য এবং কার্যকর হতে পারে যখন সামান্য যুক্তি থাকে এবং এটি খুব কমই পরিবর্তিত হয়, তবে প্রায়শই এটি প্রতিটি 500 লাইনের ভয়ানক পদ্ধতিতে শেষ হয়, রাশিয়ার ন্যাটোতে যোগদানের জন্য প্রয়োজনের চেয়ে বেশি যদি-বিবৃতি থাকে।

সংজ্ঞা 3. পরিবর্তনের স্থানীয়করণ।

মদ্যপানকারীরা প্রায়শই বুঝতে পারে না কেন তারা অন্য কারো অ্যাপার্টমেন্টে জেগেছে বা তাদের মোবাইল ফোন কোথায় আছে। এটি বিস্তারিত লগিং যোগ করার সময়.

ঢালা প্রক্রিয়ার সাথে লগিং শুরু করা যাক:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Before pour with {_hand} and {_bottle}");
        //Pour business logic ...
        _log.Log($"After pour with {_hand} and {_bottle}");
    }
}

মধ্যে এটি encapsulating দ্বারা পোরঅপারেশন, আমরা দায়িত্ব এবং এনক্যাপসুলেশনের দৃষ্টিকোণ থেকে বুদ্ধিমানের সাথে কাজ করেছি, কিন্তু এখন আমরা পরিবর্তনশীলতার নীতির সাথে বিভ্রান্ত হয়েছি। অপারেশন নিজেই ছাড়াও, যা পরিবর্তন করতে পারে, লগিং নিজেই পরিবর্তনযোগ্য হয়ে ওঠে। ঢালা অপারেশনের জন্য আপনাকে আলাদা করতে হবে এবং একটি বিশেষ লগার তৈরি করতে হবে:

interface IPourLogger{
    void LogBefore(IHand, IBottle){}
    void LogAfter(IHand, IBottle){}
    void OnError(IHand, IBottle, Exception){}
}

class PourOperation: IOperation{
    PourOperation(IPourLogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.LogBefore(_hand, _bottle);
        try{
             //... business logic
             _log.LogAfter(_hand, _bottle");
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

সতর্ক পাঠক তা লক্ষ্য করবেন লগআফটার, লগ বিফোর и OnError এছাড়াও পৃথকভাবে পরিবর্তন করা যেতে পারে, এবং, পূর্ববর্তী ধাপের সাথে সাদৃশ্য দ্বারা, তিনটি শ্রেণী তৈরি করবে: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

এবং মনে রাখবেন যে একজন পানকারীর জন্য তিনটি অপারেশন আছে, আমরা নয়টি লগিং ক্লাস পাই। ফলস্বরূপ, সমগ্র পানীয় বৃত্ত 14 (!!!) শ্রেণী নিয়ে গঠিত।

অধিবৃত্ত? কঠিনভাবে! একটি পচনশীল গ্রেনেড সহ একটি বানর মানুষ "ঢালা"টিকে একটি ডিক্যান্টার, একটি গ্লাস, ঢালা অপারেটর, একটি জল সরবরাহ পরিষেবা, অণুগুলির সংঘর্ষের একটি শারীরিক মডেলে বিভক্ত করবে এবং পরবর্তী ত্রৈমাসিকের জন্য সে নির্ভরতাগুলিকে মুক্ত করার চেষ্টা করবে। গ্লোবাল ভেরিয়েবল। এবং বিশ্বাস করুন, তিনি থামবেন না।

এই মুহুর্তে অনেকেই এই উপসংহারে পৌঁছে যে SRP হল গোলাপী রাজ্যের রূপকথা, এবং নুডুলস খেলতে চলে যায়...

... Srp-এর তৃতীয় সংজ্ঞার অস্তিত্ব সম্পর্কে না শিখে:

“একক দায়িত্ব নীতি বলে যে পরিবর্তনের অনুরূপ জিনিসগুলি এক জায়গায় সংরক্ষণ করা উচিত" অথবা "কি পরিবর্তন একসাথে এক জায়গায় রাখতে হবে"

অর্থাৎ, যদি আমরা একটি অপারেশনের লগিং পরিবর্তন করি, তবে আমাদের অবশ্যই এটি একটি জায়গায় পরিবর্তন করতে হবে।

এটি একটি অত্যন্ত গুরুত্বপূর্ণ বিষয় - যেহেতু উপরে SRP-এর সমস্ত ব্যাখ্যায় বলা হয়েছে যে টাইপগুলিকে চূর্ণ করার সময় পিষে ফেলা প্রয়োজন ছিল, অর্থাৎ, তারা বস্তুর আকারের উপর একটি "উর্ধ্ব সীমা" আরোপ করেছে এবং এখন আমরা ইতিমধ্যে একটি "নিম্ন সীমা" সম্পর্কে কথা বলছি। অন্য কথায়, এসআরপি-র জন্য শুধুমাত্র "ক্রাশ করার সময় পিষে ফেলা" প্রয়োজন হয় না, তবে এটি অতিরিক্ত করাও নয় - "ইন্টারলকিং জিনিসগুলিকে ক্রাশ করবেন না". ওকামের রেজার আর এপ ম্যান এর মধ্যে এই মহাযুদ্ধ!

এখন পানকারী ভাল বোধ করা উচিত। IPourLogger লগারকে তিনটি শ্রেণীতে বিভক্ত করার কোন প্রয়োজন নেই তা ছাড়াও, আমরা সমস্ত লগারকে এক প্রকারে একত্রিত করতে পারি:

class OperationLogger{
    public OperationLogger(string operationName){/*..*/}
    public void LogBefore(object[] args){/*...*/}       
    public void LogAfter(object[] args){/*..*/}
    public void LogError(object[] args, exception e){/*..*/}
}

এবং যদি আমরা একটি চতুর্থ ধরনের অপারেশন যোগ করি, তাহলে এর জন্য লগিং ইতিমধ্যে প্রস্তুত। এবং অপারেশন কোড নিজেই পরিষ্কার এবং অবকাঠামো গোলমাল মুক্ত.

ফলস্বরূপ, মদ্যপানের সমস্যা সমাধানের জন্য আমাদের 5টি ক্লাস রয়েছে:

• ঢালা অপারেশন
• মদ্যপান অপারেশন
• জ্যামিং অপারেশন
• লগার
• মদ্যপ সম্মুখভাগ

তাদের প্রত্যেকে একটি কার্যকারিতার জন্য কঠোরভাবে দায়ী এবং পরিবর্তনের একটি কারণ রয়েছে। পরিবর্তন অনুরূপ সমস্ত নিয়ম কাছাকাছি অবস্থিত.

বাস্তব জীবনের উদাহরণ

আমরা একবার স্বয়ংক্রিয়ভাবে একটি b2b ক্লায়েন্ট নিবন্ধনের জন্য একটি পরিষেবা লিখেছিলাম। এবং অনুরূপ বিষয়বস্তুর 200 লাইনের জন্য একটি ঈশ্বর পদ্ধতি উপস্থিত হয়েছে:

• 1C এ যান এবং একটি অ্যাকাউন্ট তৈরি করুন
• এই অ্যাকাউন্টের সাথে, পেমেন্ট মডিউলে যান এবং সেখানে এটি তৈরি করুন
• চেক করুন যে এই ধরনের অ্যাকাউন্টের সাথে একটি অ্যাকাউন্ট মূল সার্ভারে তৈরি করা হয়নি
• একটি নতুন অ্যাকাউন্ট তৈরি করুন
• পেমেন্ট মডিউলে রেজিস্ট্রেশন ফলাফল এবং রেজিস্ট্রেশন ফলাফল পরিষেবাতে 1c নম্বর যোগ করুন
• এই টেবিলে অ্যাকাউন্ট তথ্য যোগ করুন
• পয়েন্ট সার্ভিসে এই ক্লায়েন্টের জন্য একটি পয়েন্ট নম্বর তৈরি করুন। এই পরিষেবাতে আপনার 1c অ্যাকাউন্ট নম্বর পাস করুন।

এবং ভয়ানক সংযোগ সহ এই তালিকায় আরও 10টি ব্যবসায়িক ক্রিয়াকলাপ ছিল। প্রায় প্রত্যেকেরই অ্যাকাউন্ট অবজেক্টের প্রয়োজন ছিল। অর্ধেক কলে পয়েন্ট আইডি এবং ক্লায়েন্টের নাম প্রয়োজন ছিল।

রিফ্যাক্টরিংয়ের এক ঘন্টা পরে, আমরা পরিকাঠামো কোড এবং অ্যাকাউন্টের সাথে কাজ করার কিছু সূক্ষ্মতাকে আলাদা পদ্ধতি/ক্লাসে আলাদা করতে সক্ষম হয়েছি। ঈশ্বর পদ্ধতিটি এটিকে সহজ করে দিয়েছে, কিন্তু কোডের 100টি লাইন বাকি ছিল যা কেবল অগোছালো হতে চায় না।

মাত্র কয়েকদিন পরেই এটা স্পষ্ট হয়ে গেল যে এই "হালকা" পদ্ধতির সারমর্ম হল একটি ব্যবসায়িক অ্যালগরিদম। এবং প্রযুক্তিগত বৈশিষ্ট্যের মূল বর্ণনাটি বেশ জটিল ছিল। এবং এটি এই পদ্ধতিটিকে টুকরো টুকরো করার চেষ্টা যা SRP লঙ্ঘন করবে, এবং এর বিপরীতে নয়।

আনুষ্ঠানিকতা।

আমাদের মাতালকে একা ছেড়ে দেওয়ার সময় এসেছে। আপনার অশ্রু শুকিয়ে দিন - আমরা অবশ্যই একদিন এটিতে ফিরে যাব। এখন এই নিবন্ধ থেকে জ্ঞান আনুষ্ঠানিক করা যাক.

আনুষ্ঠানিকতা 1. SRP এর সংজ্ঞা

1. উপাদানগুলিকে আলাদা করুন যাতে তাদের প্রতিটি একটি জিনিসের জন্য দায়ী।
2. দায়িত্ব মানে "পরিবর্তনের কারণ"। অর্থাৎ, ব্যবসায়িক যুক্তির পরিপ্রেক্ষিতে প্রতিটি উপাদানের পরিবর্তনের জন্য শুধুমাত্র একটি কারণ রয়েছে।
3. ব্যবসায়িক যুক্তিতে সম্ভাব্য পরিবর্তন। স্থানীয়করণ করা আবশ্যক। সিঙ্ক্রোনাসভাবে পরিবর্তিত উপাদানগুলি অবশ্যই কাছাকাছি হতে হবে।

আনুষ্ঠানিকতা 2. প্রয়োজনীয় স্ব-পরীক্ষার মানদণ্ড।

আমি এসআরপি পূরণের জন্য পর্যাপ্ত মানদণ্ড দেখিনি। কিন্তু প্রয়োজনীয় শর্ত আছে:

1) নিজেকে জিজ্ঞাসা করুন এই ক্লাস/পদ্ধতি/মডিউল/পরিষেবা কি করে। আপনি একটি সহজ সংজ্ঞা দিয়ে উত্তর দিতে হবে. ( ধন্যবাদ ব্রাইটরি )

ব্যাখ্যা

যাইহোক, কখনও কখনও এটি একটি সহজ সংজ্ঞা খুঁজে পাওয়া খুব কঠিন

2) একটি বাগ সংশোধন করা বা একটি নতুন বৈশিষ্ট্য যোগ করা ন্যূনতম সংখ্যক ফাইল/ক্লাসকে প্রভাবিত করে৷ আদর্শভাবে - এক.

ব্যাখ্যা

যেহেতু দায়বদ্ধতা (একটি বৈশিষ্ট্য বা বাগ) একটি ফাইল/ক্লাসে এনক্যাপসুলেট করা হয়েছে, আপনি ঠিক জানেন কোথায় দেখতে হবে এবং কী সম্পাদনা করতে হবে। উদাহরণস্বরূপ: লগিং ক্রিয়াকলাপের আউটপুট পরিবর্তন করার বৈশিষ্ট্যটির জন্য শুধুমাত্র লগার পরিবর্তন করতে হবে। বাকি কোডের মাধ্যমে চালানোর প্রয়োজন নেই।

আরেকটি উদাহরণ হল একটি নতুন UI কন্ট্রোল যোগ করা হচ্ছে, আগেরগুলির মতো। যদি এটি আপনাকে 10টি ভিন্ন সত্তা এবং 15টি ভিন্ন রূপান্তরকারী যোগ করতে বাধ্য করে, তাহলে মনে হচ্ছে আপনি এটিকে অতিরিক্ত করছেন৷

3) যদি বেশ কয়েকটি বিকাশকারী আপনার প্রকল্পের বিভিন্ন বৈশিষ্ট্যের উপর কাজ করে, তাহলে একটি মার্জ বিরোধের সম্ভাবনা, অর্থাৎ একই সময়ে একাধিক বিকাশকারীর দ্বারা একই ফাইল/শ্রেণী পরিবর্তন করার সম্ভাবনা ন্যূনতম।

ব্যাখ্যা

যদি, একটি নতুন অপারেশন "টেবিলের নীচে ভদকা ঢালা" যোগ করার সময়, আপনাকে লগার, মদ্যপান এবং ঢালার অপারেশনকে প্রভাবিত করতে হবে, তাহলে মনে হচ্ছে দায়িত্বগুলি বাঁকাভাবে ভাগ করা হয়েছে। অবশ্যই, এটি সর্বদা সম্ভব নয়, তবে আমাদের এই সংখ্যাটি হ্রাস করার চেষ্টা করা উচিত।

4) যখন ব্যবসায়িক যুক্তি সম্পর্কে একটি স্পষ্ট প্রশ্ন জিজ্ঞাসা করা হয় (একজন বিকাশকারী বা পরিচালকের কাছ থেকে), আপনি কঠোরভাবে একটি ক্লাস/ফাইলে যান এবং শুধুমাত্র সেখান থেকে তথ্য পান।

ব্যাখ্যা

বৈশিষ্ট্য, নিয়ম বা অ্যালগরিদমগুলি সংক্ষিপ্তভাবে লেখা হয়, প্রতিটি এক জায়গায়, এবং কোড স্পেস জুড়ে পতাকা দিয়ে ছড়িয়ে ছিটিয়ে নেই।

5) নামকরণ পরিষ্কার।

ব্যাখ্যা

আমাদের শ্রেণী বা পদ্ধতি একটি জিনিসের জন্য দায়ী, এবং দায়িত্বটি তার নামে প্রতিফলিত হয়

AllManagersManagerService - সম্ভবত একটি ঈশ্বর শ্রেণী
স্থানীয় পেমেন্ট - সম্ভবত না

আনুষ্ঠানিকতা 3. ওকাম-প্রথম বিকাশ পদ্ধতি।

নকশার শুরুতে, বানর মানুষ জানে না এবং সমস্যার সমাধান হওয়ার সমস্ত সূক্ষ্মতা অনুভব করে না এবং ভুল করতে পারে। আপনি বিভিন্ন উপায়ে ভুল করতে পারেন:

• বিভিন্ন দায়িত্ব একত্রিত করে বস্তুকে অনেক বড় করুন
• একটি একক দায়িত্বকে বিভিন্ন প্রকারে ভাগ করে রিফ্রেমিং
• দায়িত্বের সীমানা ভুলভাবে সংজ্ঞায়িত করুন

নিয়মটি মনে রাখা গুরুত্বপূর্ণ: "একটি বড় ভুল করা ভাল," বা "যদি আপনি নিশ্চিত না হন তবে এটিকে ভাগ করবেন না।" যদি, উদাহরণস্বরূপ, আপনার ক্লাসে দুটি দায়িত্ব থাকে, তবে এটি এখনও বোধগম্য এবং ক্লায়েন্ট কোডে ন্যূনতম পরিবর্তনের সাথে দুটি ভাগে বিভক্ত করা যেতে পারে। কাচের টুকরো থেকে একটি গ্লাস একত্রিত করা সাধারণত আরও কঠিন কারণ প্রসঙ্গটি বেশ কয়েকটি ফাইল জুড়ে ছড়িয়ে পড়ে এবং ক্লায়েন্ট কোডে প্রয়োজনীয় নির্ভরতার অভাব।

এটি একটি দিন কল করার সময়

SRP এর পরিধি OOP এবং SOLID এর মধ্যে সীমাবদ্ধ নয়। এটি পদ্ধতি, ফাংশন, ক্লাস, মডিউল, মাইক্রোসার্ভিস এবং পরিষেবাগুলিতে প্রযোজ্য। এটি "ফিগ্যাক্স-ফিগাক্স-এন্ড-প্রোড" এবং "রকেট-সায়েন্স" উভয়ের ক্ষেত্রেই প্রযোজ্য, যা বিশ্বকে সর্বত্র একটু ভালো করে তোলে। যদি আপনি এটি সম্পর্কে চিন্তা করেন, এটি প্রায় সমস্ত প্রকৌশলের মৌলিক নীতি। মেকানিক্যাল ইঞ্জিনিয়ারিং, কন্ট্রোল সিস্টেম এবং প্রকৃতপক্ষে সমস্ত জটিল সিস্টেম উপাদানগুলি থেকে তৈরি করা হয়, এবং "আন্ডারফ্র্যাগমেন্টেশন" ডিজাইনারদের নমনীয়তা থেকে বঞ্চিত করে, "ওভারফ্র্যাগমেন্টেশন" ডিজাইনারদের দক্ষতা থেকে বঞ্চিত করে, এবং ভুল সীমানা তাদের যুক্তি এবং মানসিক শান্তি থেকে বঞ্চিত করে।

SRP প্রকৃতি দ্বারা উদ্ভাবিত নয় এবং সঠিক বিজ্ঞানের অংশ নয়। এটি আমাদের জৈবিক এবং মনস্তাত্ত্বিক সীমাবদ্ধতা থেকে বেরিয়ে আসে।এটি বানর-মানুষের মস্তিষ্ক ব্যবহার করে জটিল সিস্টেমগুলি নিয়ন্ত্রণ এবং বিকাশ করার একটি উপায় মাত্র। তিনি আমাদের বলেন কিভাবে একটি সিস্টেম পচনশীল. মূল প্রণয়নের জন্য যথেষ্ট পরিমাণে টেলিপ্যাথির প্রয়োজন ছিল, কিন্তু আমি আশা করি এই নিবন্ধটি কিছু স্মোকস্ক্রিন পরিষ্কার করবে।

উত্স: www.habr.com