একক দায়িত্বের নীতিমালাটি পরিষ্কার করুন

64

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

"একটি জিনিস" এর অর্থ কীভাবে আপনি বর্ণনা করবেন? একটি শ্রেণি সত্যই "একটি জিনিস" এর চেয়ে বেশি কিছু করে এমন কয়েকটি লক্ষণীয় লক্ষণ কী কী?

design object-oriented

— dsimcha
সূত্র

6

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

— ববি টেবিলগুলি

50

রবার্ট সি মার্টিন (আঙ্কেল বব) যেভাবে একক দায়িত্বের নীতিটি পুনঃস্থাপন করেছেন (পিডিএফ-এর সাথে যুক্ত ) আমি সত্যিই পছন্দ করি :

শ্রেণীর পরিবর্তনের জন্য একাধিক কারণ থাকতে হবে না

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

লিঙ্কযুক্ত নিবন্ধে, চাচা বব শেষ করেছেন:

এসআরপি হ'ল নীতিগুলির মধ্যে একটি সহজতম এবং সঠিক হওয়া সবচেয়ে কঠিন একটি। যৌথ দায়বদ্ধতা এমন একটি বিষয় যা আমরা স্বাভাবিকভাবেই করি। এই দায়িত্বগুলি একে অপরের থেকে সন্ধান এবং পৃথক করা সফ্টওয়্যার ডিজাইনটি আসলে কী।

— Paddyslacker
সূত্র

2

আমি এটি যেভাবে বলেছি এটি পছন্দ করি, বিমূর্ত "দায়িত্ব" এর পরিবর্তে পরিবর্তনের সাথে সম্পর্কিত হলে এটি পরীক্ষা করা সহজ বলে মনে হয়।

— ম্যাথিউ এম।

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

— কোডেক্সআরকানিয়াম

1

এটি কেবল আমার গ্রেডকে দেখিয়েছে - দুর্দান্ত পড়া এবং আমার কাছে এক জঘন্য স্মারক।

— মার্টিজন ভার্বার্গ

1

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

— dsimcha

18

আমি নিজেকে জিজ্ঞাসা করতে থাকি যে এসআরপি কোন সমস্যার সমাধান করার চেষ্টা করছে? এসআরপি কখন আমাকে সাহায্য করে? আমি এখানে যা এলাম তা এখানে:

আপনার ক্লাসের বাইরে দায়বদ্ধতা / কার্যকারিতাটি পুনরায় সজ্জিত করা উচিত যখন:

1) আপনি কার্যকারিতা সদৃশ করেছেন (DRY)

2) আপনি দেখতে পান যে আপনার কোডটি বুঝতে (KISS) এটি বুঝতে সহায়তা করার জন্য আপনার কোডটির অন্য স্তরের বিমূর্ততা প্রয়োজন

3) আপনি দেখতে পেলেন যে কার্যকারিতার টুকরোটি আপনার ডোমেন বিশেষজ্ঞদের দ্বারা আলাদা উপাদান হিসাবে পৃথক (সর্বব্যাপী ভাষা) হিসাবে বোঝা গেছে

আপনি কোনও শ্রেণীর বাইরে রিফ্যাক্টরের দায়িত্বে নিবেন না যখন:

1) কোনও সদৃশ কার্যকারিতা নেই।

2) কার্যকারিতাটি আপনার শ্রেণির প্রসঙ্গে বাইরে বোঝায় না। অন্য কোনও উপায়ে বলুন, আপনার শ্রেণি একটি প্রসঙ্গ সরবরাহ করে যাতে কার্যকারিতা বোঝা আরও সহজ।

3) আপনার ডোমেন বিশেষজ্ঞদের সেই দায়বদ্ধতার ধারণা নেই।

আমার কাছে এটি ঘটে যে যদি এসআরপিকে বিস্তৃতভাবে প্রয়োগ করা হয় তবে আমরা একধরনের জটিলতা (একটি শ্রেণীর মাথা বা লেজ তৈরির চেষ্টা করে যা অনেক বেশি insideুকে যাচ্ছে) অন্য ধরণের সাথে (সমস্ত সহযোগী / স্তরের সকল স্তরের রাখার চেষ্টা করছি) এই ক্লাসগুলি আসলে কী করে তা নির্ধারণের জন্য সরাসরি বিমূর্ততা)।

সন্দেহ হলে, ছেড়ে দিন! আপনি পরে সর্বদা রিফ্যাক্টর করতে পারেন, যখন এটির জন্য একটি পরিষ্কার ক্ষেত্রে রয়েছে।

আপনি কি মনে করেন?

— ব্র্যান্ডন
সূত্র

যদিও এই নির্দেশিকাগুলি সহায়ক হতে পারে বা নাও হতে পারে, এসআলডি-তে সংজ্ঞায়িত হিসাবে এসআরপি-র সাথে এর আসলে কোনও সম্পর্ক নেই, তাই না?

— সারা

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

— নিকোলাস পিটারসন

4

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

— জেরেমি
সূত্র

4

উত্তর সংজ্ঞা মধ্যে আছে

আপনি যে দায়িত্বটি নির্ধারণ করবেন তা শেষ পর্যন্ত আপনাকে সীমানা দেয়।

উদাহরণ:

আমার একটি উপাদান রয়েছে যাতে চালান প্রদর্শন করার দায়িত্ব রয়েছে -> এই ক্ষেত্রে আমি যদি আরও কিছু যুক্ত করা শুরু করি তবে আমি নীতিটি ভঙ্গ করছি।

অন্যদিকে যদি আমি চালানগুলি পরিচালনা করার দায়িত্ব বলেছি -> একাধিক ছোট ফাংশন যুক্ত করা (যেমন মুদ্রণ চালান , চালান আপডেট করা ) সমস্তই সেই সীমার মধ্যে।

তবে যদি সেই মডিউলটি চালানের বাইরে কোনও কার্যকারিতা পরিচালনা করতে শুরু করে , তবে তা সেই সীমানার বাইরে।

— কালো রাত
সূত্র

আমার ধারণা এখানে প্রধান সমস্যাটি হ্যান্ডলিং শব্দটি। একটি একক দায়িত্ব সংজ্ঞায়িত করা খুব সাধারণ ic আমি মনে করি একটি একক উপাদান হ্যান্ডেল-প্রিন্ট, আপডেট এবং - এর পরিবর্তে মুদ্রণ চালানের জন্য কোনও উপাদান এবং আপডেট চালানের জন্য আরও একটির জন্য দায়বদ্ধ থাকা ভাল ? কেন নয়? - প্রদর্শন, যাই হোক না কেন oice চালান ।

— মাচাডো

1

ওপি মূলত জিজ্ঞাসা করছে "আপনি কীভাবে একটি দায়িত্ব সংজ্ঞা দেবেন?" সুতরাং যখন আপনি বলছেন যে দায়িত্বটি আপনি যা যা সংজ্ঞা দিয়েছিলেন তা মনে হয় যেন এটি কেবল প্রশ্নের পুনরাবৃত্তি করছে।

— দেশপারটার

2

আমি সর্বদা এটি দুটি স্তরে দেখি:

আমি নিশ্চিত করি যে আমার পদ্ধতিগুলি কেবল একটি কাজ করে এবং এটি ভাল করে
আমি একটি ক্লাসকে সেই পদ্ধতিগুলির যৌক্তিক (ওও) গ্রুপিং হিসাবে দেখছি যা একটি জিনিসকে ভালভাবে উপস্থাপন করে

কুকুর নামে একটি ডোমেন অবজেক্টের মতো কিছু:

Dogআমার ক্লাস কিন্তু কুকুর অনেক কিছুই করতে পারে! আমি যেমন পদ্ধতি থাকতে পারে walk(), run()এবং bite(DotNetDeveloper spawnOfBill)(দুঃখিত প্রতিহত করতে পারে না; P)।

যদি Dogঅযৌক্তিক হয়ে যায় তবে আমি কীভাবে এই পদ্ধতির দলগুলিকে অন্য শ্রেণিতে যেমন এক Movementক্লাসে আমার walk()এবং run()পদ্ধতিগুলি ধারণ করতে পারে তার জন্য কীভাবে মডেল করা যায় সে সম্পর্কে ভাবতে চাই ।

কোনও কঠোর এবং দ্রুত নিয়ম নেই, সময়ের সাথে সাথে আপনার ওও ডিজাইন বিকশিত হবে। আমি একটি পরিষ্কার কাটা ইন্টারফেস / পাবলিক এপিআই পাশাপাশি সাধারণ পদ্ধতি যা একটি জিনিস এবং একটি জিনিস ভালভাবে করতে চেষ্টা করি।

— মার্তিজান ভার্বার্গ
সূত্র

কামড় সত্যই অবজেক্টের উদাহরণ গ্রহণ করা উচিত, এবং একটি ডটনেট ডেফলার ব্যক্তির একটি সাবক্লাস হওয়া উচিত (সাধারণত, যাইহোক!)

— অ্যালান পিয়ার্স

@ অ্যালান - আছে - এটি আপনার জন্য স্থির করেছে :-)

— মার্টিজন ভার্বার্গ

1

আমি এটি আরও বর্গের লাইনে দেখছি কেবল একটি জিনিস প্রতিনিধিত্ব করা উচিত । যথাযথ @ Karianna উদাহরণ করার জন্য, আমি আমার আছে Dogবর্গ, যার জন্য পদ্ধতি আছে walk(), run()এবং bark()। আমি পদ্ধতি যোগ করার জন্য যাচ্ছি না meaow(), squeak(), slither()বা fly()কারণ সেগুলো কুকুর যে হয় না। এগুলি এমন জিনিস যা অন্যান্য প্রাণীগুলি করে এবং অন্যান্য প্রাণীগুলির প্রতিনিধিত্ব করার জন্য তাদের নিজস্ব শ্রেণি থাকবে।

(BTW, যদি আপনার কুকুর নেই উড়ে, তাহলে আপনি সম্ভবত তাকে জানালা দিয়ে ছুড়ে বন্ধ করা উচিত)।

— JohnL
সূত্র

"যদি আপনার কুকুরটি উড়ে যায় তবে আপনার সম্ভবত তাকে উইন্ডো থেকে ফেলে দেওয়া উচিত" for :)

— ববি টেবিল

শ্রেণীর প্রতিনিধিত্ব করা উচিত কিনা এই প্রশ্নের বাইরেও একটি উদাহরণ কী উপস্থাপন করে? এক শুভেচ্ছা যদি SeesFoodএকটি বৈশিষ্ট যেমন DogEyes, Barkকিছু হিসাবে একটি দ্বারা সম্পন্ন DogVoice, এবং Eatকিছু দ্বারা সম্পন্ন হিসেবে DogMouth, তারপর যুক্তিবিজ্ঞান মত if (dog.SeesFood) dog.Eat(); else dog.Bark();হয়ে যাবে if (eyes.SeesFood) mouth.Eat(); else voice.Bark();, পরিচয় যে চোখ, মুখ, এবং ভয়েস সমস্ত একটি একক entitity সংযুক্ত আছেন কোন অর্থে হারায়।

— সুপারক্যাট

প্রসঙ্গত গুরুত্বপূর্ণ যদিও @ সুপের্যাট এটি একটি ন্যায্য বিষয়। আপনার উল্লিখিত কোডটি যদি Dogশ্রেণীর মধ্যে থাকে তবে এটি সম্ভবত Dogসম্পর্কিত re যদি তা না হয় তবে আপনি সম্ভবত ন্যায়বিচারের myDog.Eyes.SeesFoodচেয়ে কিছু দিয়ে শেষ করবেন eyes.SeesFood। আরেকটি সম্ভাবনা হ'ল Dogসেই ISeeইন্টারফেসটি প্রকাশ করে যা Dog.Eyesসম্পত্তি এবং SeesFoodপদ্ধতিটি দাবি করে ।

— জনএল

@ জনল: যদি দেখার আসল মেকানিক্সটি কোনও কুকুরের চোখের দ্বারা, যদি বিড়াল বা জেব্রা দ্বারা মূলত একইভাবে পরিচালিত হয় তবে মেকানিক্সটি কোনও Eyeশ্রেণি দ্বারা পরিচালিত করা বোধগম্য হতে পারে তবে একটি কুকুর "দেখতে" উচিত নিখরচায় দেখতে পারা চোখের চেয়ে এর চোখ ব্যবহার করা। একটি কুকুর চোখ নয়, তবে তা কেবল চোখের ধারকও নয়। এটি একটি "এমন জিনিস যা [কমপক্ষে দেখার চেষ্টা করতে] পারে", এবং ইন্টারফেসের মাধ্যমে এমনটি হিসাবে বর্ণনা করা উচিত। এমনকি অন্ধ কুকুরকে জিজ্ঞাসা করা যেতে পারে যে এটি খাবার দেখায়; এটি খুব কার্যকর হবে না, যেহেতু কুকুর সর্বদা "না" বলবে, তবে জিজ্ঞাসা করার কোনও ক্ষতি নেই।

— সুপারক্যাট

তারপরে আপনি আইএসআই ইন্টারফেসটি আমার মন্তব্যে বর্ণনা করার মতো ব্যবহার করবেন।

— জনল

1

বিমূর্তির নিজস্ব স্তরে দেখা গেলে একটি শ্রেণীর একটি কাজ করা উচিত। এটি নিঃসন্দেহে কম বিমূর্ত স্তরে অনেক কিছুই করবে। প্রোগ্রামগুলি আরও রক্ষণাবেক্ষণযোগ্য করার জন্য ক্লাসগুলি এইভাবে কাজ করে: আপনার যদি তাদের ঘনিষ্ঠভাবে পরীক্ষা করার প্রয়োজন না হয় তবে তারা বাস্তবায়নের বিশদটি গোপন করে।

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

আমার অভিজ্ঞতায় নীতির স্তরে এই নীতিটি রাখা আরও সহজ, যেখানে জিনিসগুলি আরও দৃ concrete়।

— ডেভিড থর্নলি
সূত্র

0

এটি একটি অনন্য রোল সম্পর্কে ।

প্রতিটি শ্রেণি একটি ভূমিকা নাম দিয়ে আবার শুরু করা উচিত। একটি ভূমিকা আসলে একটি (সেট) ক্রিয়া (গুলি) একটি প্রসঙ্গে যুক্ত।

উদাহরণ স্বরূপ :

ফাইল কোনও ফাইলের অ্যাক্সেস সরবরাহ করে। ফাইল ম্যানেজার ফাইল অবজেক্ট পরিচালনা করে।

একটি ফাইল থেকে এক সংস্থান হিসাবে রিসোর্স হোল্ড ডেটা। রিসোর্সস ম্যানেজারটি সমস্ত সংস্থান রাখে এবং সরবরাহ করে।

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

সুতরাং, ধারণাটি কেবল আপনাকে একটি অনন্য ভূমিকা সংজ্ঞায়িত করে ক্লাসটি কী করে তার একটি সহজ ধারণা পেতে দেওয়া, এটি বেশ কয়েকটি উপ-ভূমিকাটির সমষ্টি হতে পারে (সদস্য অবজেক্টস বা অন্যান্য বস্তু দ্বারা সম্পাদিত)।

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

আপনি যখন ডিজাইন করেন, অনন্য ভূমিকা চিহ্নিত করুন। এবং প্রতিটি ভূমিকার জন্য, আবার দেখুন যে এটি অন্য কয়েকটি চরিত্রে কাটা যায় না। এইভাবে, যদি আপনার ম্যানেজারকে অবজেক্ট তৈরির উপায়ের অনুরূপ প্রয়োজন হয় তবে কেবল কারখানাটি পরিবর্তন করুন এবং মনের মধ্যে শান্তিতে যাবেন।

— Klaim
সূত্র

-1

এসআরপি কেবল শ্রেণি বিভাজন সম্পর্কে নয়, কার্যকারিতা সরবরাহ করার বিষয়েও।

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

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

সলাইডের নেট এফেক্টটি হ'ল আমরা বিদ্যমান কোডটি সংশোধন করার চেয়ে নতুন কোড লিখতে পাই এবং এটি একটি বড় জয়।

— user1488779
সূত্র

-1

এটি সমস্ত দায়বদ্ধতার সংজ্ঞা এবং সেই সংজ্ঞাটি আপনার কোড রক্ষণাবেক্ষণকে কীভাবে প্রভাবিত করে তার উপর নির্ভর করে। সমস্ত কিছু এক জিনিস পর্যন্ত ফোটে এবং এটিই আপনার কোডটি বজায় রাখতে আপনার ডিজাইন আপনাকে সহায়তা করবে।

এবং যেমন কেউ বলেছিলেন "প্রদত্ত চশমা থেকে পানির উপর হাঁটা এবং সফটওয়্যার ডিজাইন করা সহজ, তবে উভয়ই হিমশীতল"।

সুতরাং, আমরা যদি আরও দৃ concrete়ভাবে দায়িত্ব নির্ধারণ করি তবে আমাদের এটি পরিবর্তন করার দরকার নেই।

কখনও কখনও দায়িত্বগুলি সুস্পষ্টরূপে সুস্পষ্ট হয়ে উঠতে পারে তবে কখনও কখনও এটি সূক্ষ্ম হতে পারে এবং আমাদের ন্যায়বিচারের সাথে সিদ্ধান্ত নেওয়া দরকার।

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

— AKS
সূত্র

-1

"পরিবর্তনের একটি কারণ" সিস্টেমটি কে ব্যবহার করছে তার উপর নির্ভর করে। আপনি প্রতিটি অভিনেতার জন্য কেস ব্যবহার করেছেন তা নিশ্চিত করুন এবং ব্যবহারের প্রতিটি সম্ভাব্য পরিবর্তনের জন্য নিশ্চিত করুন যে কেবলমাত্র একটি শ্রেণি সেই পরিবর্তনের দ্বারা প্রভাবিত হবে। আপনি যদি সম্পূর্ণ নতুন ব্যবহারের কেস যুক্ত করছেন তবে নিশ্চিত হয়ে নিন যে এটি করার জন্য আপনার কেবল কোনও শ্রেণি বাড়ানো দরকার।

— kiwicomb123
সূত্র

1

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

— candied_orange

কেন আমরা সম্ভবত সম্ভাব্য পরিবর্তনের একটি তালিকা তৈরি করব না? জল্পনা নকশা?

— কিউইকম্ব 123

কারণ এটি সাহায্য করবে না, সম্পূর্ণ হবে না, এবং ভবিষ্যদ্বাণী করার চেয়ে পরিবর্তনের সাথে মোকাবিলা করার আরও কার্যকর উপায় রয়েছে। শুধু এটা আশা। বিচ্ছিন্ন সিদ্ধান্ত এবং প্রভাব ন্যূনতম হবে।

— candied_orange

ঠিক আছে, আমি বুঝতে পেরেছি, এটি "আপনার দরকার নেই এটি" নীতিটি লঙ্ঘন করে।

— কিউইকম্ব 123

বাস্তবে যজ্ঞকে অনেকদূর ধাক্কা দেওয়া যায়। এটি আসলে আপনাকে অনুমানমূলক ব্যবহারের ক্ষেত্রে প্রয়োগ করা থেকে বিরত রাখা। কোনও প্রয়োগকৃত ব্যবহারের কেসকে বিচ্ছিন্ন করা থেকে বিরত রাখবেন না।

— candied_orange