একক দায়বদ্ধতা বা পরিবর্তনের একক কারণ কি করে এবং কী করে না সে নিয়ে বিতর্ক করা আজকের দিনে আমার পক্ষে কার্যকর মনে হচ্ছে না। আমি তার জায়গায় ন্যূনতম শোকের নীতি প্রস্তাব করব:
ন্যূনতম শোকের নীতি: কোডটি হয় পরিবর্তনের প্রয়োজনীয়তার সম্ভাবনা হ্রাস করতে বা পরিবর্তিত হওয়ার স্বাচ্ছন্দ্যকে সর্বাধিক করে তোলা উচিত।
এটা কেমন ছিল? রক্ষণাবেক্ষণের ব্যয় হ্রাস করতে কেন এটি সাহায্য করতে পারে এবং এটি আশা করা যায় যে এটি অন্তহীন বিতর্কের বিষয় হওয়া উচিত নয়, তবে সাধারণভাবে সলিডের মতো, এটি সর্বত্র অন্ধভাবে প্রয়োগ করার মতো কিছু নয় figure ট্রেড-অফগুলিকে সামঞ্জস্য করার সময় এটি বিবেচনা করার মতো কিছু to
পরিবর্তনের প্রয়োজনীয়তার সম্ভাবনা হিসাবে, এটি নীচে চলে যায়:
- ভাল পরীক্ষা (উন্নত নির্ভরযোগ্যতা)।
- নির্দিষ্ট কিছু করার জন্য কেবল বেয়ার ন্যূনতম কোডের সাথে জড়িত হওয়া (এর মধ্যে অ্যাফেরেন্ট কাপলিং হ্রাস অন্তর্ভুক্ত থাকতে পারে)।
- কোডটি খারাপ করে তোলে যা এটি করে (দেখুন Badass নীতিটি তৈরি করুন)।
পরিবর্তনগুলি করতে অসুবিধা হিসাবে, এটি অভিজাত কাপলিংয়ের সাথে উঠে যায়। পরীক্ষার মাধ্যমে অভিজাত যুগলদের পরিচয় হয় তবে এটি নির্ভরযোগ্যতা উন্নত করে। সম্পন্ন হয়েছে, এটি সাধারণত ক্ষতির চেয়ে আরও ভাল কাজ করে এবং সর্বনিম্ন গ্রহণযোগ্য এবং সর্বনিম্ন দুঃখের নীতি দ্বারা প্রচারিত।
Badass নীতিমালা করুন: অনেক জায়গায় ব্যবহৃত ক্লাসগুলি দুর্দান্ত হওয়া উচিত। এগুলি নির্ভরযোগ্য, দক্ষ হওয়া উচিত যদি এটি তাদের মানের সাথে সম্পর্কিত হয় ইত্যাদি ties
এবং মেক বাডাস প্রিন্সিপাল ন্যূনতম দুঃখের নীতির সাথে আবদ্ধ, যেহেতু বদস জিনিসগুলি যা করে তার থেকে স্তন্যপান করে এমন জিনিসগুলির চেয়ে পরিবর্তনের প্রয়োজনের কম সম্ভাবনা খুঁজে পাবে।
আমি উপরে উল্লিখিত প্যারাডক্সটির দিকে ইঙ্গিত করে শুরু করেছিলাম এবং তারপরে সূচিত করব যে এসআরপি আপনি যে গ্রানুলারিটির স্তর বিবেচনা করতে চান তার উপর নির্ভরশীল এবং আপনি যদি এটি যথেষ্ট পরিমাণে গ্রহণ করেন তবে একাধিক সম্পত্তি বা এক পদ্ধতিযুক্ত কোনও শ্রেণি লঙ্ঘন করে এটা।
একটি এসআরপি দৃষ্টিকোণ থেকে এমন একটি শ্রেণি যা সবেমাত্র কিছু করে তার অবশ্যই পরিবর্তন করার একমাত্র (কখনও কখনও শূন্য) কারণ থাকতে পারে:
class Float
{
public:
explicit Float(float val);
float get() const;
void set(float new_val);
};
বাস্তবে পরিবর্তনের কোনও কারণ নেই! এটি এসআরপি থেকে ভাল। এটা জেডআরপি!
আমি প্রস্তাব না দিলে এটি Make Badass নীতি লঙ্ঘনের মধ্যে রয়েছে। এটিও একেবারেই মূল্যহীন। যা কিছু খুব কম করে তা খারাপ হওয়ার আশা করতে পারে না। এটিতে খুব কম তথ্য রয়েছে (টিএলআই)। এবং স্বভাবতই যখন আপনার কাছে টিআইএল কিছু থাকে তবে এটি সত্যিকার অর্থে অর্থপূর্ণ কিছু করতে পারে না, এমনকি যে তথ্যটি তার দ্বারা আবৃত হয় তা দিয়েও নয়, সুতরাং বাইরের বিশ্বে এটিকে আশাবাদী এবং খারাপ কিছু করতে হবে এমন আশা করে এটিকে ফাঁস করতে হবে। এবং সেই ফাঁস হ'ল এমন কোনও কিছুর জন্য ঠিক আছে যা কেবলমাত্র ডেটাগ্রেট করা এবং আরও কিছু না বোঝার জন্য, তবে "প্রান্তিকতা" হিসাবে আমি "ডেটা" এবং "অবজেক্টস" এর মধ্যে যে পার্থক্যটি দেখি তার দ্বার হ'ল পার্থক্য।
অবশ্যই টিএমআই যা কিছু খারাপ তাও। আমরা আমাদের সম্পূর্ণ সফ্টওয়্যারকে এক শ্রেণিতে রেখে দিতে পারি। এমনকি এটিতে কেবল একটি runপদ্ধতি থাকতে পারে। এবং যে কেউ তর্ক করতে পারে যে এটির পরিবর্তনের এখন একটি বিস্তৃত কারণ রয়েছে: "সফ্টওয়্যারটির উন্নতির প্রয়োজন হলে কেবল এই শ্রেণিটি পরিবর্তন করা দরকার" " আমি মূর্খ হয়ে যাচ্ছি, তবে অবশ্যই আমরা এটির সাথে সমস্ত রক্ষণাবেক্ষণের বিষয়টি কল্পনা করতে পারি।
সুতরাং আপনার নকশা করা সামগ্রীর গ্রানুলারিটি বা খাঁটিতা সম্পর্কে একটি ভারসাম্যপূর্ণ কাজ রয়েছে। বাইরের বিশ্বে আপনার কতটা তথ্য ফাঁস হতে হবে এবং এটি কতটা অর্থবহ কার্যকরীতা সম্পাদন করতে পারে তা দ্বারা আমি প্রায়শই এটি বিচার করি। আমি প্রায়শই ন্যূনতম শোকের নীতিটি মিশ্রণের সময় ভারসাম্য বজায় রাখার জন্য ব্যাডাস নীতিটিকে সহায়ক মনে করি।