একক দায়িত্বের নীতি - আমি কি এটি অতিরিক্ত ব্যবহার করছি?

Question

রেফারেন্সের জন্য - http://en.wikedia.org/wiki/Single_ দায়িত্বজ্ঞান_নীতি

আমার একটি পরীক্ষার দৃশ্য রয়েছে যেখানে অ্যাপ্লিকেশনটির একটি মডিউলে খাত্তর এন্ট্রি তৈরির জন্য দায়বদ্ধ। তিনটি বুনিয়াদি কাজ সম্পাদন করা যেতে পারে -

• সারণী বিন্যাসে বিদ্যমান খাত্তর এন্ট্রি দেখুন।
• তৈরি বোতামটি ব্যবহার করে নতুন খাত্তর এন্ট্রি তৈরি করুন।
• সারণীতে একটি খাত্তর এন্ট্রি ক্লিক করুন (প্রথম পয়েন্টারে উল্লিখিত) এবং এর বিশদটি পরবর্তী পৃষ্ঠায় দেখুন। আপনি এই পৃষ্ঠায় একটি খাত্তর এন্ট্রি বাতিল করতে পারেন।

(প্রতিটি পৃষ্ঠায় আরও কয়েকটি অপারেশন / বৈধতা রয়েছে তবে সংক্ষিপ্ততার জন্য আমি এগুলিতে সীমাবদ্ধ রাখব)

সুতরাং আমি তিনটি পৃথক ক্লাস তৈরি করার সিদ্ধান্ত নিয়েছি -

• LedgerLandingPage
• CreateNewLedgerEntryPage
• ViewLedgerEntryPage

এই ক্লাসগুলি সেই পরিষেবাগুলি সরবরাহ করে যা সেই পৃষ্ঠাগুলিতে সম্পাদিত হতে পারে এবং সেলেনিয়াম পরীক্ষাগুলি এই ক্লাসগুলি এমন একটি राज्यात প্রয়োগের জন্য প্রয়োগ করে যেখানে আমি নির্দিষ্ট দৃ as়তা জানাতে পারি।

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

Comments

আইএমএইচও দুটি বিষয় না জেনে সাধারণভাবে আপনার প্রশ্নের জবাব দেওয়ার চেষ্টা করার কোনও অর্থ নেই: এই শ্রেণিগুলি (পদ্ধতি গণনা এবং এলওসি দ্বারা) কত বড়? এবং তারা কত বড় / আরও জটিল প্রত্যাশিত ভবিষ্যতে বৃদ্ধি প্রত্যাশা করা হয়?

— প্যাটার টারিক

10 টি পদ্ধতি হ'ল আইএমএইচও 30 টি পদ্ধতি সহ একটি শ্রেণিতে কোডটি না রাখার একটি স্পষ্ট ইঙ্গিত।

— ডক ব্রাউন

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

— পিটার টারিক

@ পেটারট্রিক - আমি সম্মত না হই যদি না কোডটি এমন এক শ্রেণীর মধ্যে সংশোধন করা যায় যা স্বজ্ঞাতভাবে ব্যবহার করা যায় যা ডুপ্লিকেট কার্যকারিতার পরিবর্তে কোডটিকে পুনরায় ব্যবহার করে যেমন আমি আশা করি যে ওপি রয়েছে।

— SoylentGray

সম্ভবত এমভিসি প্রয়োগ করা এগুলি পুরোপুরি পরিষ্কার করে দেবে: তিনটি মতামত, একটি মডেল (লেজার) এবং সম্ভবত তিনটি নিয়ামক।

— কেভিন ক্লিন

Answer 1

এখানে @ ইন্নিসআরিজোস উদ্ধৃত :

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

প্রোগ্রামিংয়ের প্রায় 30 বছরের অভিজ্ঞতার পরে, আমি এখনই অসম্মত। ছোট ক্লাসগুলি IMHO প্রায় প্রতিটি ক্ষেত্রেই বজায় রাখা ভাল তবে আমি এই জাতীয় ক্ষেত্রে যেমন ভাবতে পারি । আপনি একটি শ্রেণিতে যত বেশি ফাংশন রাখবেন, আপনার কম কাঠামো হবে এবং আপনার কোডের মান হ্রাস পাবে - প্রতিদিন কিছুটা bit আমি যখন তরুনকে সঠিকভাবে বুঝতে পেরেছি তখন এই 3 টি অপারেশনের প্রতিটি

LedgerLandingPage

CreateNewLedgerEntryPage

ViewLedgerEntryPage

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

যদি আপনার এই 3 টি শ্রেণির মধ্যে সাধারণ কার্যকারিতা থাকে তবে সেগুলি হয় একটি সাধারণ বেস শ্রেণিতে, Ledgerবর্গ নিজেই (আমি ধরে নিই যে CRUD ক্রিয়াকলাপের জন্য আপনার কমপক্ষে একটি রয়েছে) বা পৃথক সহায়ক শ্রেণিতে অন্তর্ভুক্ত।

প্রচুর ছোট ছোট ক্লাস তৈরির জন্য যদি আপনার আরও যুক্তি প্রয়োজন হয় তবে আমি রবার্ট মার্টিনের "ক্লিন কোড" বইটি দেখার পরামর্শ দিই ।

Comments

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

— তরুন

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

— পিডিআর

@ পিডিআর, ওপি বলেছে যে এই শ্রেণীর মধ্যে কোনও সাধারণ কার্যকারিতা নেই, সুতরাং (আমার জন্য) কোনও একক পরিবর্তন করার জন্য যখন আপনাকে একের বেশি স্পর্শ করতে হবে তখন কোনও পরিস্থিতির কল্পনা করা শক্ত hard

— পিটার টারিক

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

— ডক ব্রাউন

@ পিডিআর: বিটিডাব্লু, আপনি কি আসলে "ক্লিন কোড" পড়েছেন? ছোট্ট ইউনিটগুলিতে কোড ভাঙার ক্ষেত্রে বব মার্টিন খুব দূরে।

— ডক ব্রাউন

Answer 2

একক দায়িত্ব নীতি বা অন্য কোনও নীতির একটি নির্দিষ্ট প্রয়োগ নেই isn't কী কী পরিবর্তন হতে পারে তার ভিত্তিতে আপনার সিদ্ধান্ত নেওয়া উচিত।

যেমন @ কার্পি পূর্বের উত্তরে লিখেছেন :

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

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

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

ডিজাইনের নীতিগুলি অত্যধিক ব্যবহারের বিষয়ে একই ধরণের প্রশ্ন, যা আমি মনে করি যে আপনি আকর্ষণীয় খুঁজে পাবেন: ডিজাইনের নিদর্শন: কখন ব্যবহার করবেন এবং কখন নিদর্শন ব্যবহার করে সবকিছু করা বন্ধ করবেন?

Comments

আমার বোঝার কাছে এসআরপি আসলে কোনও ডিজাইনের ধরণ নয়।

— ডক ব্রাউন

@ ডকব্রাউন অবশ্যই কোনও ডিজাইনের ধরণ নয়, তবে প্রশ্নটির উপর আলোচনাটি অত্যন্ত প্রাসঙ্গিক ... তবে ভাল উত্তর

— ধরুন

Answer 3

আসুন এই ক্লাসগুলি পরীক্ষা করুন:

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

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

• ক্রিয়েটলিজারএন্ট্রিপেজ: যদি ViewLedgerEntryPageসম্পূর্ণ সম্পাদনার ক্ষমতা থাকে তবে এই শ্রেণীর দায়িত্ব সম্ভবত একটি "ফাঁকা প্রবেশ" সম্পাদনা করার মাধ্যমে পূরণ করা যেতে পারে, যা বোধগম্য বা বোধগম্য নয়।

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

---

এসআরপি অতিরিক্ত ব্যবহারের মতো জিনিস রয়েছে : কোনও ফাইলের বিষয়বস্তু পড়তে যদি আপনার এক ডজন ক্লাসের প্রয়োজন হয় তবে ধরে নেওয়া নিরাপদ যে আপনি এটি করছেন।

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

Comments

আমি অনুমান করি এমনকি আমি এই ক্লাসগুলির দায়িত্ব আপনার চেয়ে আরও ভাল করে বর্ণনা করতে পারিনি।

— তরুণ

Answer 4

এই ক্লাসগুলির কি পরিবর্তনের একমাত্র কারণ আছে?

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

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

পুরো বিষয়টি হ'ল:

• পরিবর্তনের জন্য চালকদের দিকে নজর রাখুন।
• একটি নমনীয় নকশা চয়ন করুন, যা রিফ্যাক্টর করা যেতে পারে।
• অ্যাক্টিং কোড প্রস্তুত।

আপনার যদি এই মানসিকতা থাকে তবে আপনি অনুমানমূলক নকশা / ওভার ইঞ্জিনিয়ারিংয়ের খুব ভয় ছাড়াই কোডটি গঠন করবেন।

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

Answer 5

শ্রেণি বিভক্ত করার কারণ হিসাবে এসআরপিকে অনুরোধ করার তিনটি কারণ রয়েছে:

• যাতে ভবিষ্যতে প্রয়োজনীয়তার পরিবর্তনগুলি কিছু ক্লাস অপরিবর্তিত রাখতে পারে
• যাতে কোনও বাগ আরও দ্রুত বিচ্ছিন্ন করা যায়
• ক্লাস আরও ছোট করা

শ্রেণি বিভক্ত করতে অস্বীকার করার তিনটি কারণ রয়েছে:

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

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

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

Comments

একটি ভিন্ন দৃষ্টিকোণ দেখতে ভাল

— তরুণ

Answer 6

আমি মনে করি যে ডিগ্রিটি যদি ডিবিতে একটি টেবিল হত তবে আমি এই থ্রেস টাস্কটিকে এক শ্রেণিতে রাখার পরামর্শ দিই (যেমন ডিএও) the (দুটি বা থ্রেস ক্লাস হতে পারে) এবং কেবল গ্রাহকের জন্য একটি মুখোমুখি ক্লাস সরবরাহ করে।

Comments

ওয়েল, খাত্তি ইউআই-তে একটি বৈশিষ্ট্য এবং এর সাথে সম্পর্কিত অনেকগুলি অপারেশন রয়েছে যা বিভিন্ন পৃষ্ঠা থেকে করা যেতে পারে।

— তারুন

Answer 7

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

খাতায় সম্পাদনার জন্য কোনও শ্রেণিতে রাজ্য লুকানোর কিছু ঘটনা রয়েছে।

আপনি এসআরপিকে গালি দিচ্ছেন বা না করুন, আপনি আরও কিছু মৌলিক গালাগাল করছেন: আপনি বিমূর্তিটিকে অতিরিক্ত ব্যবহার করছেন। এটি একটি সাধারণ সমস্যা, পৌরাণিক ধারণা দ্বারা উত্সাহিত করা ওও একটি বুদ্ধিমান বিকাশের দৃষ্টান্ত।

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

Answer 8

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

Comments

আমার কাছে '... ম্যানেজার' শ্রেণি সাধারণত দেখায় যে আপনি এটিকে আরও ভেঙে ফেলার বিরক্ত করতে পারবেন না। ক্লাস ম্যানেজিং কি? উপস্থাপনা, অধ্যবসায়?

— সেবাস্তেঞ্জিগার

-1। 3 বা ততোধিক ব্যবহারের কেস 1 ক্লাসে স্থাপন করা ঠিক সেই জিনিসটি যা এসআরপি এড়াতে চাইছে - এবং ভাল কারণে।

— ডক ব্রাউন

@sebastiangeiger সুতরাং ওপি'র তিনটি শ্রেণি কী করছে? উপস্থাপনা না জেদ?

— সেভেনসিয়াট

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

— সেবাস্তেঞ্জিগার

প্রকৃতপক্ষে, ব্যবহারকারীদের খুশি করার একক দায়বদ্ধতার সাথে আপনার পুরো অ্যাপ্লিকেশনটির জন্য কেবল একটি শ্রেণির প্রয়োজন ;-)

— পিটার টারিক