প্রতিটি শ্রেণীর একটাই দায়িত্ব রয়েছে তা নিশ্চিত করুন কেন?

37

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

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

— বাসটিয়েন ভন্ডমমে
সূত্র

2

সম্পর্কিত: এসআরপি (একক দায়িত্বের নীতি) উদ্দেশ্য কি?

— gnat

1

আমার একটি প্রশ্ন ছিল যা আপনি সম্পর্কিতও হতে পারেন: কোনও শ্রেণির আসল দায়িত্ব কী?

— পিয়ের আরলাড

3

একক দায়িত্বের সমস্ত কারণ কি সঠিক হতে পারে না? এটি রক্ষণাবেক্ষণকে আরও সহজ করে তোলে। এটি পরীক্ষা সহজতর করে তোলে। এটি শ্রেণিকে আরও দৃ rob় করে তোলে (সাধারণভাবে)

— মার্টিন ইয়র্ক

2

একই কারণে আপনার সমস্ত ক্লাস রয়েছে।

— Žদ্রো

2

আমার এই বক্তব্যটি বরাবরই একটি সমস্যা ছিল। "একক দায়িত্ব" কী তা নির্ধারণ করা খুব কঠিন difficult "কর্পোরেট ব্যাংকিং অ্যাকাউন্টগুলিতে এবং বাইরে অর্থ প্রদানের সমস্ত অর্থের নিখুঁত লগ বজায় রাখতে" "যাচাই করে দেখুন যে 1 + 1 = 2" থেকে কোনও একক দায়িত্ব রেঞ্জ করতে পারে।

— ডেভ নায়

57

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

এসআরপি ক্লাসে যেমন ফাংশনগুলির জন্য ঠিক তেমনি প্রযোজ্য তবে মূলধারার ওওপি ভাষাগুলি একসাথে আঠালো ফাংশনে তুলনামূলকভাবে দুর্বল।

— Doval
সূত্র

12

বিমূর্ততা রচনার নিরাপদ উপায় হিসাবে কার্যকরী প্রোগ্রামিং উল্লেখ করার জন্য +1।

— লগ করুন

> তবে মূলধারার ওওপি ভাষাগুলি একসাথে আঠালো ফাংশনে তুলনামূলক কম <

— জেফ হাবার্ড

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

— ডোভাল

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

— জেফ হাবার্ড

মূলত, যদি আপনার ভাষা ওওপিটিকে আরও সহজ / আরও ভাল / দ্রুত / শক্তিশালী করার বিষয়ে হয় তবে ফাংশনগুলি একসাথে আঠালো হওয়া বা না করা আপনি ফোকাস করছেন তা নয়।

— জেফ হাবার্ড

30

আরও ভাল রক্ষণাবেক্ষণ, সহজ পরীক্ষা, দ্রুত বাগ-ফিক্সিং এসআরপি প্রয়োগের ঠিক (খুব মনোরম) ফলাফল। মূল কারণ (রবার্ট সি মতিন যেমন রেখেছেন) হ'ল:

একটি শ্রেণীর একটি এবং একটি মাত্র পরিবর্তন হওয়ার কারণ থাকতে হবে।

অন্য কথায়, এসআরপি পরিবর্তিত লোকেশন উত্থাপন করে ।

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

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

— ম্যাকিয়েজ চ্যাপাপুক
সূত্র

1

এসআরপিকে ডিআরওয়ির সাথে সংযুক্ত করার জন্য +1।

— মাহদী

21

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

যা একটি সঠিক: তাদের তিনটিই। এগুলি হ'ল একক দায়বদ্ধতা ব্যবহারের সমস্ত উপকারিতা এবং আপনার এটি ব্যবহার করা উচিত।

তাদের অর্থ কী:

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

নীতিটি অনুসরণ করে কিছুক্ষণের জন্য কোড তৈরি করার চেষ্টা করুন এবং কিছু পরিবর্তন করার জন্য সেই কোডটি পরে আবার ঘুরে দেখুন। আপনি এটি সরবরাহ করে এমন বিশাল সুবিধা দেখতে পাবেন।

আপনি প্রতিটি শ্রেণীর সাথে একই কাজ করেন এবং আরও এসআরপি মেনে চলতে আরও ক্লাস শেষ করেন। এটি সংযোগের দৃষ্টিকোণ থেকে কাঠামোটিকে আরও জটিল করে তোলে তবে প্রতিটি শ্রেণীর সরলতা এটিকে ন্যায্যতা দেয়।

— মিয়ামোতো আকিরা
সূত্র

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

2

আপনি সব ক্লাসে একই করেন। আপনি আরও ক্লাস দিয়ে শেষ করেছেন, সমস্ত এসআরপি মেনে চলে। এটি সংযোগের দৃষ্টিকোণ থেকে কাঠামোটিকে আরও জটিল করে তোলে। তবে প্রতিটি শ্রেণীর সরলতা এটি ন্যায়সঙ্গত করে। যদিও আমি @ দোভালের উত্তর পছন্দ করি।

— মিয়ামোটো আকিরা

আমি মনে করি যে এটি আপনার উত্তরে যুক্ত করা উচিত।

4

এখানে যুক্তিগুলি যা আমার দৃষ্টিতে দাবিটি সমর্থন করে যে একক-দায়বদ্ধতা নীতিটি একটি ভাল অনুশীলন। আমি আরও সাহিত্যের লিঙ্কগুলি সরবরাহ করি, যেখানে আপনি আরও বিশদ যুক্তিগুলি পড়তে পারেন - এবং আমার থেকে আরও স্পষ্টবাদী:

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

— logc
সূত্র

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

— বাসটিয়েন ভান্ডামমে

@ বি ৪৪১: আমার অর্থ এই নয় যে কোনও পরিবর্তনই একক শ্রেণিতে একক পরিবর্তনকে বোঝায়। একক ব্যবসায়ের পরিবর্তন মেনে চলার জন্য সিস্টেমটির অনেক অংশের পরিবর্তনের প্রয়োজন হতে পারে। তবে সম্ভবত আপনার একটি বক্তব্য রয়েছে এবং আমার উচিত "যখনই সিস্টেমের কার্যকারিতা পরিবর্তন করতে হবে" লেখা উচিত ছিল।

— লগ্যাক 21

3

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

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

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

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

একটি কাজ করে এমন শ্রেণীর পরীক্ষা করা খুব সহজ। আপনার যাচাই করতে হবে না যে ক্লাসটি প্রতিটি পরীক্ষার জন্য দ্বিতীয় শ্রেণীর কাজটি করে বা না ঘটে। আপনাকে এই ভাঙ্গা শর্তগুলিও ঠিক করতে হবে না এবং এই পরীক্ষাগুলির মধ্যে একটি ব্যর্থ হলে পুনরায় পরীক্ষা করতে হবে।

— BillThor
সূত্র

2

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

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

— CodeART
সূত্র

1

আমি ভেবেছিলাম অনুসরণ করুন: 1 Class = 1 Job।

একটি ফিজিওলজি অ্যানালগি ব্যবহার করে: মোটর (নিউরাল সিস্টেম), রেসপিরেশন (ফুসফুস), হজম (পেট), ঘ্রাণকারী (পর্যবেক্ষণ) ইত্যাদি etc. এগুলির প্রত্যেকেরই নিয়ামকগুলির একটি উপসেট থাকে তবে তাদের প্রত্যেকেরই কেবল 1 টি দায়িত্ব থাকে এটি পরিচালনা করতে হবে কিনা তাদের নিজ নিজ সাবসিস্টেমগুলির যেভাবে কাজ করে বা তারা এন্ড-পয়েন্ট সাবসিস্টেম কিনা এবং কেবলমাত্র 1 টি কার্য সম্পাদন করে যেমন আঙুল তুলে বা চুলের ফলিকেল বৃদ্ধি করা।

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

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

যখন কোনও শ্রেণি / অবজেক্ট এই ধরণের ভূমিকাগুলির 1 টিরও বেশি ভূমিকা পালন করে, আপনি দেখতে পাবেন যে সামগ্রিক প্রক্রিয়াটিতে পারফরম্যান্স সমস্যা, বা বোতল-ঘাড়ে প্রক্রিয়া শুরু হবে।

— GoldBishop
সূত্র

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

— সুপারক্যাট

হ্যাঁ সেই ক্ষেত্রে ফুসফুসটি ম্যানেজার, যদিও ভিলি সুপারভাইজার হবেন, এবং শ্বাসকষ্টের প্রক্রিয়াটি রক্ত প্রবাহে বায়ু কণাকে স্থানান্তর করার জন্য শ্রমজীবী হবে be

— গোল্ডবিশপ

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

— সুপারক্যাট

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

— গোল্ডবিশপ

@ গোল্ডবিশপ: আমি আশা করি একটি "ইফেমেরাল" প্রকার ঘোষণার কিছু উপায় ছিল, যেমন বাইরের কোড সদস্যদের অনুরোধ করতে পারে বা টাইপটির নিজস্ব পদ্ধতিতে এটি প্যারামিটার হিসাবে পাস করতে পারে, তবে অন্য কিছুই ছিল না। একটি কোড সংগঠন দৃষ্টিকোণ থেকে, subdividing শ্রেণীর জ্ঞান করে তোলে, এবং এমনকি পদ্ধতি এক স্তর নিচে (যেমন ডাকা বাহিরে কোড থাকার Fred.vision.lookAt(George)জ্ঞান করে তোলে, কিন্তু বলতে কোড অনুমতি someEyes = Fred.vision; someTubes = Fred.digestionকিনতে হত বলে মনে হয় যেহেতু এটি মধ্যে সম্পর্ক অস্পষ্ট someEyesএবং someTubes।

— supercat

1

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

সে কারণগুলির কয়েকটি হতে পারে:

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

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

— euphoric
সূত্র

... test is not affected by other responsibilities the class has, আপনি কি দয়া করে এই সম্পর্কে বিস্তারিত বলতে পারেন?

— মাহদি

1

এই নীতিগুলির গুরুত্ব বোঝার সর্বোত্তম উপায় হ'ল প্রয়োজন।

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

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

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

তবে, ঠিক আপনার মতোই, আমি এখনও "সহজ পরীক্ষা" সম্পর্কে অনিশ্চিত, কারণ আমার এখনও ইউনিট পরীক্ষায় নামার দরকার হয়নি।

— harsimranb
সূত্র

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

— ম্যাকিয়েজ চ্যাপাপুক

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

— হার্সিমরণব

1

উত্তরটি, যেমন অন্যরা উল্লেখ করেছে, সেগুলি সবই সঠিক, এবং এগুলি একে অপরের সাথে খাওয়ানো হয়, পরীক্ষার জন্য সহজতর রক্ষণাবেক্ষণকে সহজ করে তোলে কোডকে আরও দৃust়তর করে তোলে রক্ষণাবেক্ষণকে আরও সহজ করে তোলে এবং আরও ...

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

আমি মনে করি এটি একটি কথায় সংক্ষিপ্ত করা যেতে পারে: সুযোগ। নিদর্শনগুলির সুযোগের দিকে মনোযোগ দিন, কোনও অ্যাপ্লিকেশনের কোনও নির্দিষ্ট পয়েন্টে স্কোপের কয়েকটি জিনিসই ভাল।

বিস্তৃত সুযোগ = আরও জটিলতা = জিনিসগুলি ভুল হওয়ার আরও বেশি উপায়।

— jmoreno
সূত্র

1

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

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

তবে "কেবল একটি দায়বদ্ধতার" একটি সাধারণ নিয়ম থাকা আপনার যখন নতুন ক্লাসের প্রয়োজন তখন তা জানা সহজ করে তোলে ।

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

— ইয়ান
সূত্র