একক দায়িত্বের নীতিটি ব্যবহার করার সময়, কোন "দায়িত্ব" গঠন করে?

198

এটি বেশ পরিষ্কার বলে মনে হয় যে "একক দায়িত্বের নীতি" এর অর্থ "কেবল একটি কাজ করে না" does এটিই পদ্ধতিগুলি।

public Interface CustomerCRUD
{
    public void Create(Customer customer);
    public Customer Read(int CustomerID);
    public void Update(Customer customer);
    public void Delete(int CustomerID);
}

বব মার্টিন বলেছেন যে "ক্লাসগুলির পরিবর্তনের একমাত্র কারণ থাকতে হবে।" তবে আপনি যদি সলিডে নতুন কোনও প্রোগ্রামার হন তবে আপনার মনকে প্রায় মুড়িয়ে ফেলা মুশকিল।

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

তাহলে, তুমি কিভাবে এটা কর? প্রতিটি শ্রেণীর কোন দায়িত্ব থাকা উচিত তা আপনি কীভাবে নির্ধারণ করবেন এবং এসআরপি প্রসঙ্গে আপনি কীভাবে কোনও দায়িত্ব সংজ্ঞায়িত করবেন?

— রবার্ট হার্ভে
সূত্র

28

কোড পর্যালোচনাতে পোস্ট করুন এবং ছিঁড়ে ফেলা হবে :

— জার্গ ডব্লু মিত্তাগ ২ '

8

@ জার্গডব্লিউমিতাগ এখন আরে, লোকজনকে ভয় দেখায় না :)

— ফ্ল্যাম্বিনো ২

117

প্রবীণ সদস্যদের এর মতো প্রশ্নগুলি প্রমাণ করে যে আমরা যে নিয়ম ও নীতিগুলি ধরে রাখার চেষ্টা করি তা কোনওভাবেই সোজা বা সরল নয় । এগুলি [ধরণের] স্ববিরোধী এবং রহস্যবাদী ... কোনও নিয়মের ভাল সেট হওয়া উচিত। এবং, আমি এই নম্র জ্ঞানীদের মত প্রশ্ন বিশ্বাস করতে চাই, এবং যারা আশা নিরাশ বোকা বোধ। ধন্যবাদ, রবার্ট!

— এসভিডজেন ২

41

আমি অবাক হই যে এই প্রশ্নটি যদি কোনও নুব পোস্ট করা হত তবে সরাসরি + ডুপ্লিকেট চিহ্নিত করা হত :)

— আন্দ্রেজ

9

@ রমুন: বা অন্য কথায় - বড় বড় প্রতিনিধি আরও বেশি প্রতিনিধি আকৃষ্ট করে, কারণ স্ট্যাকেক্সচেঞ্জের উপর ভিত্তি করে মানবিক কুসংস্কার কেউ বাতিল করেনি

— আন্দ্রেজ

117

এর চারপাশে আপনার মাথা গুটিয়ে ফেলার একটি উপায় হ'ল ভবিষ্যতের প্রকল্পগুলির সম্ভাব্য প্রয়োজনীয়তাগুলির পরিবর্তনগুলি কল্পনা করা এবং সেগুলি ঘটানোর জন্য আপনার নিজেকে কী করতে হবে তা নিজেকে জিজ্ঞাসা করুন।

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

নতুন ব্যবসায়ের প্রয়োজনীয়তা: ক্যালিফোর্নিয়ায় থাকা ব্যবহারকারীরা একটি বিশেষ ছাড় পান।

"ভাল" পরিবর্তনের উদাহরণ: আমার কাছে এমন ক্লাসে কোডটি সংশোধন করা দরকার যা ছাড়ের পরিমাণ গণনা করে।

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

বা:

নতুন অ-কার্যকারী প্রয়োজন: আমরা এসকিউএল সার্ভারের পরিবর্তে ওরাকল ব্যবহার শুরু করব

ভাল পরিবর্তনের উদাহরণ: কেবলমাত্র অ্যাক্সেস লেয়ারে একক শ্রেণীর সংশোধন করা দরকার যা ডিটিওগুলিতে ডেটা কীভাবে বজায় রাখতে হয় তা নির্ধারণ করে।

খারাপ পরিবর্তন: আমার ব্যবসায়ের সমস্ত স্তর ক্লাসগুলি সংশোধন করা দরকার কারণ সেগুলিতে এসকিউএল সার্ভার-নির্দিষ্ট যুক্তি রয়েছে।

ধারণাটি হ'ল ভবিষ্যতের সম্ভাব্য পরিবর্তনের পদচিহ্ন হ্রাস করা, পরিবর্তনের ক্ষেত্রে প্রতি কোডের একটি অঞ্চলে কোড পরিবর্তনকে সীমাবদ্ধ করে।

খুব কমপক্ষে, আপনার ক্লাসগুলির শারীরিক উদ্বেগ থেকে যৌক্তিক উদ্বেগগুলি পৃথক করা উচিত। উদাহরণ একটি মহান সেট পাওয়া যাবে System.IOনামস্থান: সেখানে আমরা শারীরিক স্ট্রিম (যেমন একটি বিভিন্ন ধরণের জানতে পারেন FileStream, MemoryStreamঅথবা NetworkStream) এবং বিভিন্ন পাঠকদের ও লেখকদের ( BinaryWriter, TextWriter) যে একটি লজিক্যাল স্তরের উপর হবে। তাদের এই পথ আলাদা মাধ্যমে আমরা combinatoric বিস্ফোরণ এড়ানো: প্রয়োজন পরিবর্তে FileStreamTextWriter, FileStreamBinaryWriter, NetworkStreamTextWriter, NetworkStreamBinaryWriter, MemoryStreamTextWriter, এবং MemoryStreamBinaryWriter, আপনি শুধু আপ লেখক এবং স্ট্রিম হুক এবং আপনি যা চান তা থাকতে পারে। তারপরে পরে আমরা XmlWriterএটিকে মেমরি, ফাইল এবং নেটওয়ার্কের জন্য আলাদাভাবে পুনরায় প্রয়োগের প্রয়োজন ছাড়াই যুক্ত করতে পারি, বলতে পারি, এটি করতে পারি।

— জন উ
সূত্র

34

আমি আগে চিন্তা করার সাথে একমত হওয়ার সাথে সাথে, YAGNI এর মতো নীতি এবং টিডিডি থার মতো পদ্ধতিগুলি বিপরীত পরামর্শ দেয়।

— রবার্ট হার্ভে

87

YAGNI আমাদের যে জিনিসগুলি আজ প্রয়োজন তা না তৈরি করতে বলে build এটি এক্সটেনসিবল এমনভাবে স্টাফ তৈরি না করার কথা বলে না। আরও দেখুন খুলুন / বন্ধ নীতি , যা "সফ্টওয়্যার সত্ত্বা (ক্লাস, মডিউল, ফাংশন, ইত্যাদি) এক্সটেনশন জন্য খোলা উচিত, কিন্তু পরিবর্তনের জন্য বন্ধ।"

— জন উউ

18

@ জন ডাব্লু: একা আপনার YAGNI মন্তব্যের জন্য +1 করুন। আমি বিশ্বাস করতে পারছি না আমি কত মানুষের সাথে ব্যাখ্যা করার যে YAGNI আছে না একটি অজুহাত এক অনমনীয়, অনমনীয় সিস্টেম যে পরিবর্তন প্রতিক্রিয়া দেখাবে না গড়ে তুলতে - ব্যঙ্গ করে কি SRP এবং খুলুন / বন্ধ প্রিন্সিপাল জন্য নিশানা করছে খুব বিপরীত।

— গ্রেগ বার্গার্ড্ট

36

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

— ডক ব্রাউন 21

9

@ জোহানউইউ আমরা এসকিউএল ২০০৮ থেকে ২০১২-এ স্যুইচ করেছিলাম a মোট দুটি প্রশ্ন ছিল যা পরিবর্তনের প্রয়োজন। এবং এসকিউএল আথ থেকে বিশ্বস্ত? কেন এটি এমনকি কোড পরিবর্তন হবে; কনফিগ ফাইলে সংযোগটি পরিবর্তন করা যথেষ্ট is আবার, ইয়াজিএনআই। YAGNI এবং এসআরপি মাঝে মাঝে উদ্বেগের বিষয়গুলির প্রতিযোগিতা করে এবং কোনটিতে আরও ভাল খরচ / সুবিধা হয় তা আপনার বিচার করতে হবে।

— অ্যান্ডি

76

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

এটি আপনার অভিজ্ঞতাতে পরিবর্তিত হওয়ার সম্ভাবনা সম্পর্কে।

আমরা নীতিটির ভাষা একটি হাইপারবোলিক, আক্ষরিক, উদ্যোগী ক্রোধে প্রয়োগ করি। আমরা ক্লাসগুলি বিভক্ত করে থাকি কারণ তারা পরিবর্তিত হতে পারে বা এমন লাইন ধরে যা কেবল আমাদের সমস্যাগুলি ভেঙে দিতে সহায়তা করে। (পরবর্তী কারণটি সহজাতভাবে খারাপ নয় )) তবে, এসআরপি তার নিজের পক্ষে নেই; এটি রক্ষণাবেক্ষণযোগ্য সফ্টওয়্যার তৈরির কাজে রয়েছে ।

সুতরাং আবার, বিভাগগুলি সম্ভাব্য পরিবর্তনের দ্বারা পরিচালিত না হলে, YAGNI আরও প্রযোজ্য হলে তারা এসআরপি ¹ তে সত্যই পরিষেবাতে নেই' re উভয়ই একই চূড়ান্ত লক্ষ্য পরিবেশন করে। আর উভয় আশা - বিচারের বিষয়ে হয় পাকা রায়।

চাচা বব যখন এ সম্পর্কে লেখেন, তিনি পরামর্শ দিয়েছিলেন যে আমরা "দায়বদ্ধতা" কে "পরিবর্তনের জন্য কে জিজ্ঞাসা করছি" র ক্ষেত্রে বিবেচনা করি। অন্য কথায়, আমরা পার্টি এ তাদের চাকরি হারাতে চাই না কারণ পার্টি বি পরিবর্তন চেয়েছিল।

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

ভাল এবং অভিজ্ঞ বিকাশকারীদের একটি ধারণা থাকবে যার জন্য পরিবর্তনগুলি সম্ভবত। এবং সেই মানসিক তালিকাটি শিল্প ও সংস্থার দ্বারা কিছুটা পৃথক হবে।

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

^{১. স্পষ্ট করে বলার জন্য, এর অর্থ এই নয় যে তারা খারাপ বিভাগ। তারা দুর্দান্ত বিভাগ হতে পারে যা নাটকীয়ভাবে কোড পাঠযোগ্যতার উন্নতি করে। এর অর্থ কেবল তারা এসআরপি দ্বারা চালিত নয়।}

— svidgen
সূত্র

11

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

— user949300

2

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

— বাসিলিভস

6

@ বাসিলিভস আমি এই উত্তরটিতে যে ঘাটতিটি দেখছি তা পূরণ করার চেষ্টা করছি - আঙ্কেল বব এর উত্তর উল্লেখ না করার জন্য! তবে, সম্ভবত আমার স্পষ্ট করে বলা দরকার যে এসআরপি "পরিবর্তন" কেবলমাত্র 1 শ্রেণিতে প্রভাব ফেলবে তা নিশ্চিত করার বিষয়ে নয় । এটি নিশ্চিত করার বিষয়ে যে প্রতিটি শ্রেণি কেবল "একটি পরিবর্তন" তে সাড়া দেবে। ... এটি প্রতিটি শ্রেণি থেকে একক মালিকের কাছে আপনার তীরগুলি আঁকতে চেষ্টা করার বিষয়ে। প্রতিটি মালিক থেকে একক শ্রেণিতে নয়।

— এসভিডজেন

2

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

— মাইকেল এল।

4

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

— মাইকেল এল।

29

আমি অনুসরণ করি "ক্লাসগুলির পরিবর্তনের একমাত্র কারণ থাকতে হবে"।

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

অভিজ্ঞতার একমাত্র জিনিস যা আমি এই পাগল স্কিমগুলির সম্ভাবনার যথাযথ মূল্যায়ন করতে পেয়েছি - কারণ একটি সহজ করা দু'জনকে আরও শক্ত করে তুলতে পারে - এবং কোনও ডিজাইনের ভালোর মূল্যায়ন করে। অভিজ্ঞ প্রোগ্রামাররা কল্পনা করতে পারেন যে কোডটি পরিবর্তন করার জন্য তাদের কী প্রয়োজন, পাছায় কামড় দেওয়ার জন্য কী পড়ে আছে এবং কোন কৌশলগুলি জিনিসগুলি সহজ করে তোলে। অভিজ্ঞ পণ্যের প্রোগ্রামাররা যখন পণ্য মালিকের ক্রেজি স্টাফের জন্য জিজ্ঞাসা করেন তখন তারা কতটা খারাপ হয় সে সম্পর্কে ভাল অনুভূতি রয়েছে।

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

আরেকটি রুট মেট্রিক হ'ল লিফট পিচ। Ditionতিহ্যবাহী লিফট পিচগুলি হ'ল "আপনি যদি কোনও বিনিয়োগকারীর সাথে লিফটে থাকতেন তবে আপনি কি তাকে কোনও ধারণায় বিক্রি করতে পারেন?"। তারা কী করছে - তাদের ফোকাস কী তা নিয়ে স্টার্টআপসের সরল এবং সংক্ষিপ্ত বিবরণ থাকতে হবে। তেমনি ক্লাস (এবং ফাংশন) এর তারা কী করে তার একটি সরল বিবরণ থাকতে হবে । "এই শ্রেণিটি এমন কিছু ফিউবার প্রয়োগ করে না যে আপনি এটি এই নির্দিষ্ট পরিস্থিতিতে ব্যবহার করতে পারেন"। আপনি অন্য বিকাশকারীকে কিছু বলতে পারেন: "এই শ্রেণিটি ব্যবহারকারী তৈরি করে"। আপনি যদি অন্য বিকাশকারীদের সাথে এটি যোগাযোগ করতে না পারেন তবে আপনি বাগ পেতে চলেছেন ।

— Telastyn
সূত্র

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

16

আমি "লিফট পিচ" ধারণার জন্য বড় অ্যাডভোকেট। যদি কোনও শ্রেণি একটি বাক্য বা দুটি বাক্যে কী করে তা ব্যাখ্যা করা আপনার পক্ষে ঝুঁকিপূর্ণ অঞ্চলে explain

— ইভান

1

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

— কেভিন ক্রামউইদে

1

সুস্পষ্ট সুবিধাগুলির পাশাপাশি, "লিফট পিচস" ব্যবহার করে আপনার কোডটি নথিভুক্ত করা আপনার কোডটি প্রাকৃতিক ভাষা ব্যবহার করে কী করছে যা আমি একাধিক দায়িত্ব উদ্ঘাটন করতে দরকারী বলে মনে করতে সহায়তা করে।

— আলেকজান্ডার

1

@ কেভিন ক্রুউইউইয়েই "চিকেন মাথা কেটে নিয়ে ছুটে চলেছে" এবং "ওয়াইল্ড গুজ চেজ" পদ্ধতিগুলির জন্য!

26

কেউ জানে না. বা কমপক্ষে, আমরা একটি সংজ্ঞায় একমত হতে পারছি না। এ কারণেই এসপিআর (এবং অন্যান্য সোলিড নীতিগুলি) বেশ বিতর্কিত করে তোলে।

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

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

— euphoric
সূত্র

20

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

— রবার্ট হার্ভে

9

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

— ট্রিপহাউন্ড

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

— সলিডের

3

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

— মাইকেল এল।

1

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

— মাইকেল এল

5

আমি মনে করি "দায়বদ্ধতা" শব্দটি রূপক হিসাবে কার্যকর কারণ এটি আমাদের সফ্টওয়্যারটি কতটা সুসংহত করেছে তা তদন্ত করতে সফ্টওয়্যারটি ব্যবহার করার অনুমতি দেয়। বিশেষত, আমি দুটি নীতিতে মনোনিবেশ করব:

দায়িত্ব কর্তৃত্বের সাথে সামঞ্জস্যপূর্ণ।
কোনও দুটি সত্তা একই জিনিসটির জন্য দায়বদ্ধ হওয়া উচিত নয়।

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

এই দুটি ছাড়াও, একটি তৃতীয় নীতি যুক্তিসঙ্গত বলে মনে হয়:

দায়িত্ব অর্পণ করা যেতে পারে

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

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

— আমটন কর্ট
সূত্র

আমি 100% নিশ্চিত নই যে এটি এটি পুরোপুরি ব্যাখ্যা করে। তবে, আমি মনে করি "কর্তৃত্বের" প্রতি শ্রদ্ধার সাথে "দায়িত্ব" ব্যাখ্যা করা এটির বাক্যদৃষ্টি করার অন্তর্দৃষ্টিপূর্ণ উপায়! (+1)

— এসভিডজেন

পিরসিগ বলেছিলেন, "আপনি আপনার সমস্যাগুলি মেশিনে তৈরি করতে চান", যা আমাকে বিরতি দেয়।

@ নোকমপ্রেডে আপনিও নিজের শক্তিকে মেশিনে গড়ে তোলার ঝোঁক। আমি যুক্তি দেব যে যখন আপনার শক্তি এবং দুর্বলতা একই জিনিস হয়, যখন এটি আকর্ষণীয় হয়ে ওঠে।

— কর্ট

5

ইন এই সম্মেলনে ইয়েল এ আঙ্কেল বব এই দেয় মজার উদাহরণ:

তিনি বলেছেন যে Employeeপরিবর্তনের তিনটি কারণ রয়েছে, পরিবর্তনের প্রয়োজনীয়তার তিনটি উত্স রয়েছে এবং এই হাস্যকর এবং জিহ্বা-ইন-গাল দেয় তবে উদাহরণস্বরূপ, ব্যাখ্যা:

যদি CalcPay()পদ্ধতিটিতে ত্রুটি থাকে এবং সংস্থাকে কয়েক মিলিয়ন মার্কিন ডলার ব্যয় করে তবে সিএফও আপনাকে বরখাস্ত করবে ।

যদি ReportHours()পদ্ধতিটিতে ত্রুটি থাকে এবং সংস্থাকে কয়েক মিলিয়ন মার্কিন ডলার ব্যয় করে তবে সিওও আপনাকে বরখাস্ত করবে ।

যদি WriteEmmployee() পদ্ধতিটিতে একটি ত্রুটি থাকে যা প্রচুর ডেটা মুছে ফেলার কারণ হয়ে থাকে এবং সংস্থার কয়েক মিলিয়ন মার্কিন ডলার ব্যয় করে, সিটিও আপনাকে বরখাস্ত করবে ।

সুতরাং তিনটি পৃথক সি স্তরের মৃত্যুর সম্ভাবনা থাকলে একই ক্লাসে ব্যয়বহুল ত্রুটির জন্য আপনাকে বহিষ্কার করা মানে শ্রেণীর অনেক বেশি দায়িত্ব রয়েছে।

তিনি এই সমাধানটি দিয়েছিলেন যা এসআরপি লঙ্ঘন সমাধান করে, তবে এখনও ডিআইপি লঙ্ঘন সমাধান করতে হবে যা ভিডিওতে দেখানো হয়নি।

— তুলিনেস কর্ডোভা
সূত্র

এই উদাহরণটি আরও বেশি ক্লাসের মতো দেখায় যার ভুল দায়িত্ব রয়েছে।

— রবার্ট হার্ভে

4

@ রবার্টহারভে যখন কোনও শ্রেণিতে অনেক বেশি দায়িত্ব থাকে তখন এর অর্থ অতিরিক্ত দায়বদ্ধতা হ'ল ভুল দায়িত্ব।

— তুলিনাস কর্ডোভা

5

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

— রবার্ট হার্ভে

@ রবার্টহারভে, পার্থক্য কী? এই পরিস্থিতিগুলি আমার কাছে বিস্ময়কর বলে মনে হচ্ছে।

— পল ড্রাগন

3

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

যদি উভয় প্রশ্নের উত্তর হ্যাঁ হয়, তবে এটি সুপারিশ করবে ক্রিয়াগুলি পৃথক শ্রেণীর দ্বারা করা উচিত। উভয় প্রশ্নের উত্তর যদি না হয় তবে এটি পরামর্শ দেয় যে জনসাধারণের দৃষ্টিকোণ থেকে একটি শ্রেণি হওয়া উচিত; যদি এর জন্য কোডটি অযৌক্তিক হয়, তবে এটি অভ্যন্তরীণভাবে ব্যক্তিগত শ্রেণিতে বিভক্ত হতে পারে। প্রথম প্রশ্নের উত্তর যদি না হয় তবে দ্বিতীয়টি হ্যাঁ, প্রতিটি ক্রিয়াকলাপের জন্য একটি পৃথক শ্রেণী থাকতে হবে এবং একটি সংঘবদ্ধ শ্রেণি থাকতে হবে যা অন্যের উদাহরণগুলির উল্লেখ অন্তর্ভুক্ত করে।

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

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

— supercat
সূত্র

এটি নিখুঁত পরামর্শ। এটি কেবল উল্লেখ করার মতো হতে পারে যে আপনি কেবল এসআরপি থেকে বেশি মানদণ্ড অনুসারে দায়িত্বগুলি ভাগ করেন।

— জর্জেন ফোগ

1

গাড়ির উপমা: কারওর ট্যাঙ্কে কতটা গ্যাস রয়েছে তা আমার জানা দরকার নয়, বা অন্য কারও ওয়াইপার চালু করতে চান না। (তবে এটি ইন্টারনেটের সংজ্ঞা) (Shh! আপনি গল্পটি নষ্ট করবেন)

1

@ নোকমপ্রেন্ডে - "অন্য কারও ট্যাঙ্কে কতটা গ্যাস রয়েছে তা আমার জানা দরকার না," - আপনি যদি না কিশোর না হন তবে পরিবারের পরবর্তী গাড়িগুলি আপনার পরবর্তী ভ্রমণের জন্য "ধার" নেওয়ার চেষ্টা করছেন ...;)

— আলেফজারো

3

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

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

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

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

— ক্রিস্টোফ রাউসি
সূত্র

এসআরপি কি কেবল কনস্ট্যান্টাইনের কোহশন রিটটি বড় নয়?

— নিক কেইগলি

আপনি যদি যথেষ্ট দীর্ঘ কোড করেন তবে আপনি স্বাভাবিকভাবেই সেই নিদর্শনগুলি দেখতে পাবেন, তবে আপনি তাদের নাম দিয়ে শিক্ষার গতি বাড়িয়ে নিতে পারেন এবং এটি যোগাযোগের ক্ষেত্রে সহায়তা করে ...

— ক্রিস্টোফ রুসি

@ নিক কেইগলি আমি মনে করি এটি সংহতি, এত বেশি রাইট নয়, তবে অন্য দৃষ্টিকোণ থেকে তাকানো।

— এসডেনহ্যাম

3

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

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

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

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

সুতরাং কেবল কী পরিবর্তন হতে পারে সে সম্পর্কে কেবল ফোকাস করবেন না - ভবিষ্যতে কোনও কিছু অনুমেয়ভাবে পরিবর্তন হতে পারে। স্বাধীনভাবে কী পরিবর্তন হতে পারে সে বিষয়ে ফোকাস করুন on পরিবর্তনগুলি সাধারণত স্বতন্ত্র হয় যদি তারা বিভিন্ন অভিনেতার কারণে ঘটে থাকে।

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

আঙ্কেল বব কে এই শব্দটি আবিষ্কার করেছেন তা উদ্ধৃত করতে :

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

সুতরাং সংক্ষিপ্তসার হিসাবে: একটি "দায়িত্ব" একক ব্যবসায়ের ফাংশন পূরণ করে। যদি একাধিক অভিনেতা আপনাকে কোনও শ্রেণি পরিবর্তন করতে পারে তবে ক্লাসটি সম্ভবত এই নীতিটি ভঙ্গ করে।

— JacquesB
সূত্র

তাঁর "ক্লিন আর্কিটেকচার" বই অনুসারে এটি ঠিক ঠিক। ব্যবসায়ের নিয়মগুলি একটি উত্স থেকে আসা উচিত এবং একবার কেবল উত্স। এর অর্থ এইচআর, অপারেশনস এবং আইটি সকলকেই "একক দায়িত্ব" এ প্রয়োজনীয়তা নির্ধারণে সহযোগিতা করা দরকার। এবং এটিই নীতি। +1

— বেনি স্কগবার্গ

2

একটি ভাল নিবন্ধ যা SOLID প্রোগ্রামিং নীতিগুলি ব্যাখ্যা করে এবং নীতির অনুসরণ করে এবং অনুসরণ না করে উভয়ের কোডের উদাহরণ দেয় https://scotch.io/bar-talk/solid-the-first-five-pr सिद्धांत-of-object-oriented- নকশা ।

এসআরপি সম্পর্কিত উদাহরণে তিনি কয়েকটি আকৃতির শ্রেণি (বৃত্ত এবং বর্গ) এবং একাধিক আকারের মোট ক্ষেত্রের গণনা করার জন্য ডিজাইন করা একটি শ্রেণির উদাহরণ দেন।

তার প্রথম উদাহরণে তিনি অঞ্চল গণনা করে শ্রেণি তৈরি করে এবং এটি HTML হিসাবে তার আউটপুট ফেরত দেয়। পরে তিনি স্থির করেন যে তিনি এটিকে পরিবর্তে জেএসএন হিসাবে প্রদর্শন করতে চান এবং তার অঞ্চল গণনাকারী ক্লাসটি পরিবর্তন করতে হবে।

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

এটি একটি সহজ উদাহরণ (এবং আরও সহজেই নিবন্ধটি পড়ার সাথে বোঝা যায় কারণ এতে কোড স্নিপেট রয়েছে) তবে এসআরপির মূল ধারণাটি প্রদর্শন করে।

— blitz1616
সূত্র

0

প্রথমত, আপনার কাছে যা আছে তা আসলে দুটি পৃথক সমস্যা: আপনার ক্লাসে কী কী পদ্ধতি প্রয়োগ করা উচিত তার সমস্যা এবং ইন্টারফেস ফুলে যাওয়ার সমস্যা।

ইন্টারফেস

আপনার এই ইন্টারফেসটি রয়েছে:

public Interface CustomerCRUD
{
  public void Create(Customer customer);
  public Customer Read(int CustomerID);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

অনুমানযোগ্য, আপনার একাধিক ক্লাস রয়েছে যা CustomerCRUDইন্টারফেসের সাথে সামঞ্জস্য করে (অন্যথায় একটি ইন্টারফেস অপ্রয়োজনীয়), এবং কিছু ফাংশন do_crud(customer: CustomerCRUD)যা একটি উপযুক্ত উপাদান হিসাবে গ্রহণ করে। তবে আপনি ইতিমধ্যে এসআরপি ভেঙে দিয়েছেন: আপনি এই চারটি স্বতন্ত্র অপারেশনকে এক সাথে বেঁধে দিয়েছেন।

যাক এর পরে আপনি ডাটাবেস ভিউতে পরিচালনা করতে চান। একটি ডাটাবেস ভিউয়ের জন্য কেবল এটি Readউপলব্ধ পদ্ধতি রয়েছে। তবে আপনি এমন একটি ফাংশন লিখতে চান do_query_stuff(customer: ???)যা অপারেটরগুলি স্বতঃস্ফূর্তভাবে সম্পূর্ণ বিকাশযুক্ত টেবিল বা দর্শনগুলিতে; এটি কেবল Readপদ্ধতিটি ব্যবহার করে , সর্বোপরি।

সুতরাং একটি ইন্টারফেস তৈরি করুন

সর্বজনীন ইন্টারফেস গ্রাহকরেডার {সর্বজনীন গ্রাহক পঠন (গ্রাহকআইডি: ইনট)}

এবং আপনার CustomerCrudইন্টারফেস হিসাবে ফ্যাক্টর :

public interface CustomerCRUD extends CustomerReader
{
  public void Create(Customer customer);
  public void Update(Customer customer);
  public void Delete(int CustomerID);
}

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

এই জগাখিচুড়ি থেকে বেরোনোর উপায় হ'ল ইন্টারফেসের পরিবর্তে স্ট্রাকচারাল সাব টাইপিং (উদাহরণস্বরূপ ওক্যামল প্রয়োগ করা) (যা নামমাত্র সাব টাইপিংয়ের একটি রূপ)। আমরা ইন্টারফেস সংজ্ঞায়িত করি না; পরিবর্তে, আমরা কেবল একটি ফাংশন লিখতে পারি

let do_customer_stuff customer = customer.read ... customer.update ...

এটি আমাদের পছন্দসই পদ্ধতিগুলিকে কল করে। ওসিএএমএল এই ধরণের পদ্ধতি প্রয়োগ করে যে কোনও বস্তুতে আমরা পাস করতে পারি তা নির্ধারণ করতে প্রকারের অনুক্রম ব্যবহার করবে। এই উদাহরণে, এটি customerটাইপ রয়েছে তা নির্ধারণ করা হবে <read: int -> unit, update: int -> unit, ...>।

ক্লাস

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

— gardenhead
সূত্র

4

"অর্থহীন" কিছুটা শক্তিশালী। আমি "রহস্যময়" বা "জেন" এর পিছনে যেতে পারি। কিন্তু, ফ্ল্যাট আউট অর্থহীন নয়!

— এসভিডজেন

স্ট্রাকচারাল সাব টাইপিং কেন একটি সমাধান হিসাবে আপনি আরও কিছুটা ব্যাখ্যা করতে পারেন?

— রবার্ট হার্ভে

@ রবার্টহারভে আমার উত্তরটি উল্লেখযোগ্যভাবে পুনর্গঠন করেছেন

— বাগানের মাথা

4

আমি ইন্টারফেসগুলি ব্যবহার করি এমনকি যখন আমার কাছে কেবল একটি একক শ্রেণি এটি প্রয়োগ করে। কেন? ইউনিট-পরীক্ষায় বিদ্রূপ করা হচ্ছে।

— শাশ্বত 21

0

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

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

— আর্থার হাভলিসেক
সূত্র

0

এটি একাধিক প্রয়োজনীয়তার পরিবর্তনগুলি অর্জন করতে হয়, আপনার উপাদানটির পরিবর্তনের প্রয়োজন হয় না ।

তবে সৌভাগ্য যে প্রথম নজরে বুঝতে পারা, যখন আপনি প্রথম সলিড সম্পর্কে শুনবেন।

আমি মন্তব্য অনেক দেখছ ' SRP এবং YAGNI eachother বিপরীত করতে পারেন, কিন্তু YAGN আমি TDD- এ দ্বারা জারি (GOOS, লন্ডন স্কুল) এর মনে করেন এবং একটি ক্লায়েন্ট দৃষ্টিকোণ থেকে আমার উপাদান ডিজাইন করতে আমাকে শিক্ষা। আমি আমার ইন্টারফেসগুলি ডিজাইন করা শুরু করেছি যে কোনও ক্লায়েন্ট সবচেয়ে কম কাজ করতে চাইবে, এটি কতটা কম করা উচিত । এবং সেই অনুশীলন টিডিডির কোনও জ্ঞান ছাড়াই করা যেতে পারে।

আমি চাচা বব দ্বারা বর্ণিত কৌশলটি পছন্দ করি (আমি কোথা থেকে মনে করতে পারি না, দুঃখের সাথে), যা এরকম কিছু যায়:

নিজেকে জিজ্ঞাসা করুন, এই শ্রেণিটি কী করে?

আপনার উত্তরে And বা Or এর কোনওটি রয়েছে?

যদি তা হয় তবে উত্তরের সেই অংশটি বের করুন, এটি তার নিজস্ব একটি দায়বদ্ধ

এই কৌশলটি একটি চূড়ান্ত, এবং যেমন @ স্পিডজেন বলেছিলেন, এসআরপি একটি রায় কল, কিন্তু নতুন কিছু শিখার সময় , বিসর্জনগুলি সবচেয়ে ভাল, কেবল সর্বদা কিছু করা সহজ । আপনি আলাদা না করার কারণটি নিশ্চিত করুন; শিক্ষিত প্রাক্কলন, এবং না কারণ আপনার কিভাবে জানি না। এই শিল্প, এবং এটি অভিজ্ঞতা লাগে।

আমার মনে হয় এসআরপি নিয়ে কথা বলার সময় অনেক উত্তর ডিউপল করার পক্ষে যুক্তি বোধ করে ।

SRP হয় না নিশ্চিত একটি পরিবর্তন নির্ভরতা গ্রাফ নিচে সঞ্চারিত না করা।

তাত্ত্বিকভাবে, এসআরপি ব্যতীত আপনার কোনও নির্ভরশীলতা নেই ...

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

সুতরাং সামগ্রিকভাবে SOLID শেখানোর সময়, সাবধানতা অবলম্বন করুন যে এসআরপি আপনাকে প্রয়োজনীয় কোডগুলি পরিবর্তন করার সময় কম কোড পরিবর্তন করতে দেয় , যখন বাস্তবে, এটি আপনাকে কম নতুন কোড লেখার অনুমতি দেয় ।

— ক্রিস ওহলার্ট
সূত্র

3

When learning something new, absolutes are the best, it is easier to just always do something.- আমার অভিজ্ঞতায়, নতুন প্রোগ্রামাররা অনেক বেশি মূর্খ। নিরঙ্কুশতা চিন্তাভাবনা বিকাশকারী এবং কার্গো-কাল্ট প্রোগ্রামিংয়ের দিকে পরিচালিত করে। তিনি বলেন, "শুধু এই do" জরিমানা, তাই যতদিন আপনি বোঝেন যে ব্যক্তি আপনাকে বলতে হয় পরে দিতে হবে ভুলিয়া যাত্তয়া আপনি তাদের বিদ্যা শিখিয়ে দিয়েছেন।

— রবার্ট হার্ভে

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

— ক্রিস ওয়াহলার্ট 12

@ রবার্টহারভে, একটি দ্রুত বাস্তব জীবনের উদাহরণ: আপনি আপনার বাচ্চাদের সবসময় সৎ হতে শেখাতে পারেন , তবে বড় হওয়ার সাথে সাথে তারা সম্ভবত কিছু ব্যতিক্রম উপলব্ধি করতে পারবেন যেখানে লোকেরা তাদের সবচেয়ে সৎ চিন্তা শুনতে চায় না। সৎ হওয়ার বিষয়ে একটি সঠিক রায় কল করার জন্য 5 বছর বয়সী আশা করা সর্বোত্তম আশাবাদী। :)

— ক্রিস ওয়াহলার্ট

0

এর কোন সুস্পষ্ট উত্তর নেই। যদিও প্রশ্নটি সংকীর্ণ, ব্যাখ্যাগুলি নেই are

আমার জন্য, এটি চাইলে ওকামের রেজারের মতো কিছু। এটি একটি আদর্শ যেখানে আমি আমার বর্তমান কোডটির বিপরীতে পরিমাপ করার চেষ্টা করি। সহজ এবং সরল কথায় এটি পেরেক করা শক্ত। আর একটি রূপক হবে »একটি বিষয়« যা বিমূর্ত, অর্থাত্ বোঝা শক্ত, একক দায়িত্ব « তৃতীয় বিবরণটি হবে st বিমূর্ততার এক স্তরের সাথে ডিল করা «

এটি ব্যবহারিকভাবে কী বোঝায়?

ইদানীং আমি কোডিংয়ের একটি স্টাইল ব্যবহার করি যা বেশিরভাগ দুটি ধাপ নিয়ে গঠিত:

প্রথম পর্যায়টি সৃজনশীল বিশৃঙ্খলা হিসাবে সবচেয়ে বেশি বর্ণিত। এই পর্যায়ে আমি কোড লিখি কারণ চিন্তাগুলি প্রবাহিত হচ্ছে - যেমন কাঁচা এবং কুশ্রী u

দ্বিতীয় ধাপ সম্পূর্ণ বিপরীত। এটি হারিকেনের পরে পরিষ্কার করার মতো। এটি সবচেয়ে বেশি কাজ এবং শৃঙ্খলা নেয়। এবং তারপরে আমি কোডটি ডিজাইনারের দৃষ্টিকোণ থেকে দেখছি।

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

একটি বর্তমান উদাহরণ অন্য দিন ছোট রফতানি কার্যকারিতা লিখতে পারে ।

একটি জিপে সিএসভি , এক্সেল এবং সম্মিলিত এক্সেল শিটের প্রয়োজন ছিল ।

সরল কার্যকারিতা প্রতিটি তিনটি দর্শন (= ফাংশন) এ সম্পন্ন হয়েছিল । প্রতিটি ফাংশন ফিল্টার নির্ধারণের জন্য একটি সাধারণ পদ্ধতি এবং ডেটা পুনরুদ্ধারে দ্বিতীয় পদ্ধতি ব্যবহার করে। তারপরে প্রতিটি ফাংশনে রফতানির প্রস্তুতি নেওয়া হয়েছিল এবং সার্ভারের প্রতিক্রিয়া হিসাবে সরবরাহ করা হয়েছিল।

বিমূর্তির অনেকগুলি স্তর মিশ্রিত হয়েছিল:

আমি) আগত / বহির্গামী অনুরোধ / প্রতিক্রিয়া সাথে ডিল

দ্বিতীয়) ফিল্টার নির্ধারণ

III) তথ্য পুনরুদ্ধার করা

চতুর্থ) তথ্যের রূপান্তর

exporterপ্রথম পদক্ষেপ II-IV স্তরগুলি মোকাবেলা করার জন্য একটি বিমূর্ততা ( ) ব্যবহার করা সহজ পদক্ষেপ ছিল ।

অনুরোধ / প্রতিক্রিয়াগুলির সাথে মোকাবিলা করার বিষয়টি কেবলমাত্র অবশিষ্ট ছিল । বিমূর্তির একই স্তরে অনুরোধের প্যারামিটারগুলি বের করা হচ্ছে যা ঠিক আছে। সুতরাং আমার এই দৃষ্টিভঙ্গির জন্য একটি "দায়িত্ব" ছিল।

দ্বিতীয়ত, আমাকে রফতানিকারককে ভেঙে ফেলতে হয়েছিল, যা আমরা দেখেছি কমপক্ষে আরও তিনটি স্তর বিমূর্তকরণ নিয়ে গঠিত।

ফিল্টার মানদণ্ড নির্ধারণ এবং প্রকৃত পুনরুদ্ধার প্রায় বিমূর্ততার একই স্তরের (ডেটার সঠিক উপসেট পেতে ফিল্টারগুলির প্রয়োজন হয়)। এই স্তরগুলিকে ডেটা অ্যাক্সেস লেয়ারের মতো কিছুতে রাখা হয়েছিল ।

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

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

প্রতিটি শ্রেণীর কোন দায়িত্ব থাকা উচিত তা আপনি কীভাবে নির্ধারণ করবেন এবং এসআরপি প্রসঙ্গে আপনি কীভাবে কোনও দায়িত্ব সংজ্ঞায়িত করবেন?

এটি অনুসরণ করার জন্য একটি রেসিপি দেওয়া কঠিন। অবশ্যই আমি ক্রিপ্টিকটি repeat বিমূর্ততার এক স্তর repeat পুনরাবৃত্তি করতে পারি - যদি এটি সাহায্য করে তবে নিয়ম করুন।

আমার পক্ষে বেশিরভাগ ক্ষেত্রে এটি এক ধরণের "শৈল্পিক স্বজ্ঞাত" যা বর্তমান নকশার দিকে নিয়ে যায়; আমি একজন শিল্পীর মতো কোডের মডেলটি মৃত্তিকা ভাসিয়ে দেয় বা পেইন্টিং করতে পারে।

কোডিং বব রস হিসাবে আমাকে কল্পনা করুন ;)

— টমাস জাঙ্ক
সূত্র

0

এসআরপি অনুসরণকারী কোডটি লিখতে আমি যা করার চেষ্টা করি:

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

উদাহরণ:

সমস্যা: ব্যবহারকারীর কাছ থেকে দুটি নম্বর পান, তাদের যোগফল গণনা করুন এবং ফলাফলটি ব্যবহারকারীকে আউটপুট করুন:

//first step: solve the problem right away
static void Main(string[] args)
{
    Console.WriteLine("Number 1: ");
    int firstNumber = Convert.ToInt32(Console.ReadLine());

    Console.WriteLine("Number 2: ");
    int secondNumber = Convert.ToInt32(Console.ReadLine());

    int result = firstNumber + secondNumber;

    Console.WriteLine("Hi there! The result is: {0}", result);

    Console.ReadLine();
}

এরপরে, সম্পাদন করা প্রয়োজন এমন কাজের উপর ভিত্তি করে দায়িত্বগুলি নির্ধারণ করার চেষ্টা করুন। এটি থেকে উপযুক্ত ক্লাসগুলি বের করুন:

//Responsible for getting two integers from the user
class Input {
    public int FirstNumber { get; set; }
    public int SecondNumber { get; set; }
    public void Read() {
        Console.WriteLine("Number 1: ");
        FirstNumber = Convert.ToInt32(Console.ReadLine());

        Console.WriteLine("Number 2: ");
        SecondNumber = Convert.ToInt32(Console.ReadLine());
    }
}

//Responsible for calculating the sum of two integers
class SumOperation {
    public int Result { get; set; }
    public void Calculate(int a, int b) {
        Result = a + b;
    }
}

//Responsible for the output of some value to the user
class Output {
    public void Write(int result) {
        Console.WriteLine("Hello! The result is: {0}", result);
    }
}

তারপরে, রিফ্যাক্টরড প্রোগ্রামটি হয়ে যায়:

//Program: responsible for main execution.
//Gets two numbers from user and output their sum.
static void Main(string[] args)
{
    var input = new Input();
    input.Read();

    var operation = new SumOperation();
    operation.Calculate(input.FirstNumber, input.SecondNumber);

    var output = new Output();
    output.Write(operation.Result);

    Console.ReadLine();
}

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

— ইমারসন কার্ডোসো
সূত্র

1

আপনার উদাহরণটি এসআরপি পর্যাপ্তরূপে চিত্রিত করার জন্য খুব সহজ। বাস্তব জীবনে কেউ এটি করবে না।

— রবার্ট হার্ভে

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

— এমারসন কার্ডোসো

0

ক্লাব আর্কিটেকচার: রবার্ট সি মার্টিনস বই থেকে 10 ই সেপ্টেম্বর, 2017 এ প্রকাশিত সফটওয়্যার স্ট্রাকচার অ্যান্ড ডিজাইনের টু শিল্পকর্মীর গাইড , রবার্ট 62 পৃষ্ঠাগুলিতে নিম্নলিখিত লিখেছেন:

Orতিহাসিকভাবে, এসআরপি এইভাবে বর্ণনা করা হয়েছে:

একটি মডিউলে পরিবর্তিত হওয়ার কারণ থাকতে পারে এবং তার একমাত্র কারণ থাকতে হবে

সফ্টওয়্যার সিস্টেম ব্যবহারকারী এবং অংশীদারদের সন্তুষ্ট করার জন্য পরিবর্তন করা হয়; ঐ ব্যবহারকারীদের এবং অংশীদারদের হয় "পরিবর্তন করার কারণ"। যে নীতিটি কথা বলছে। প্রকৃতপক্ষে, আমরা এটি বলার নীতিটি পুনরায় ব্যাখ্যা করতে পারি:

একটি মডিউল একজন এবং শুধুমাত্র একজন, ব্যবহারকারী বা স্টেকহোল্ডারের কাছে দায়বদ্ধ হতে হবে

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

সুতরাং এসআরপির চূড়ান্ত সংস্করণটি হ'ল:

একটি মডিউল একজন এবং একজনকে অভিনেতা হিসাবে দায়বদ্ধ করা উচিত।

সুতরাং এই কোড সম্পর্কে নয়। এসআরপি প্রয়োজনীয়তা এবং ব্যবসায়ের প্রয়োজনগুলির প্রবাহকে নিয়ন্ত্রণ করতে চলেছে, যা কেবলমাত্র একটি সূর্য থেকে আসতে পারে।

— বেনি স্কগবার্গ
সূত্র

আপনি কেন "এটি কোড সম্পর্কে নয়" এই পার্থক্যটি তৈরি করছেন তা নিশ্চিত নই। অবশ্যই এটি কোড সম্পর্কে; এটি সফ্টওয়্যার বিকাশ।

— রবার্ট হার্ভে

@ রবার্ট হার্ভে আমার বক্তব্যটি হল প্রয়োজনীয়তার প্রবাহটি একটি উত্স থেকে আসে, অভিনেতা। ব্যবহারকারী এবং স্টেকহোল্ডার কোডগুলিতে নয়, তারা ব্যবসায়ের নিয়মে যা প্রয়োজন হিসাবে আমাদের কাছে আসে। সুতরাং এসআরপি হ'ল এই প্রয়োজনীয়তাগুলি নিয়ন্ত্রণ করার একটি প্রক্রিয়া, যা আমার কাছে কোড নয়। এটি সফ্টওয়্যার ডেভলপমেন্ট (!), তবে কোড নয়।

— বেনি স্কোগবার্গ