এমভিসি: কন্ট্রোলার কি একক দায়িত্বের নীতিটি লঙ্ঘন করে?


16

একক দায়িত্বের নীতিতে বলা হয়েছে যে "একটি শ্রেণীর পরিবর্তনের একটি কারণ থাকা উচিত"।

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

এই যে মানে:

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

এর অর্থ পরিবর্তনের দুটি কারণ রয়েছে : জিইউআইতে পরিবর্তন এবং বায়সনে যুক্তির পরিবর্তন।

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

এবং যদি মডেলটিতে ব্যবসায়ের যুক্তি পরিবর্তিত হয় তবে মডেলটিতে সঠিক পদ্ধতিগুলি চালনার জন্য কন্ট্রোলারকে পরিবর্তন করতে হতে পারে।

সুতরাং, নিয়ন্ত্রকের পরিবর্তনের দুটি সম্ভাব্য কারণ রয়েছে । এটি কি এসআরপি ভেঙে দেয়?


2
একটি নিয়ামক একটি 2-রাস্তার রাস্তা, এটি আপনার সাধারণ উপরে-ডাউন বা নীচে আপ পদ্ধতির নয়। এর কোনও নির্ভরতা বিমূর্ত করার কোনও সম্ভাবনা নেই কারণ নিয়ামক নিজেই বিমূর্ততা। প্যাটার্নের প্রকৃতির কারণে এখানে এসআরপি মেনে চলা সম্ভব নয়। সংক্ষেপে: হ্যাঁ, এটি এসআরপি লঙ্ঘন করে তবে এটি অনিবার্য।
জেরোইন ভেনেভেল

1
প্রশ্নটির মূল বক্তব্য কী? যদি আমরা সবাই উত্তর "হ্যাঁ, এটি করে", তবে কী হবে? উত্তরটি যদি "না" হয় তবে কী হবে? আপনি এই প্রশ্নটি দিয়ে সমাধান করার চেষ্টা করছেন আসল সমস্যাটি কী?
ব্রায়ান ওকলে

1
"পরিবর্তনের কারণ" এর অর্থ "কোড পরিবর্তন হয় না"। আপনি যদি ক্লাসটির জন্য আপনার পরিবর্তনশীল নামে সাতটি টাইপস তৈরি করেন তবে সেই শ্রেণীর এখন কি 7 টি দায়িত্ব আছে? না। আপনার যদি একাধিক ভেরিয়েবল বা একাধিক ফাংশন থাকে তবে আপনার এখনও কেবল একটি একক দায়িত্ব থাকতে পারে।
বব

উত্তর:


14

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

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


1
যেমন একটি যুক্ত নোট। আপনার যদি কন্ট্রোলারআরমেক্রেইকফাস্ট () এবং কন্ট্রোলারওয়াকআপ ফ্যামিলি () থাকে তবে সেই নিয়ামকটি এসআরপি ভেঙে ফেলবে, তবে এটি নিয়ামক নয় কারণ এটির একাধিক দায়িত্ব রয়েছে।
বব

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

1
হ্যাঁ, আমি একমত হতে পারি যে নিয়ামকের একাধিক দায়িত্ব রয়েছে। তবে এগুলি "নিম্ন" দায়িত্ব এবং এটি কোনও সমস্যা নয় কারণ সর্বোচ্চ বিমূর্ত স্তর পর্যায়ে এর কেবলমাত্র একটি দায়িত্ব থাকে (আপনার উল্লেখ করা নীচেরগুলি সংযুক্ত করে) এবং সুতরাং এটি এসআরপি লঙ্ঘন করে না।
ভ্যালেনটারি

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

এই উত্তরটি আমার কাছে বোধগম্য। ধন্যবাদ ভ্যালেনটারি
J86

9

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

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

যদি জিইউআইতে একটি নতুন বোতাম যুক্ত হয় তবে কন্ট্রোলারটি কেবল তখনই পরিবর্তন করতে হবে যদি সেই নতুন বোতামটি কোনও নতুন বৈশিষ্ট্য উপস্থাপন করে (যেমন পর্দার 1 এ বিদ্যমান একই বোতামটির বিপরীতে তবে পর্দার 2 তে এখনও উপস্থিত ছিল না, এবং এটি তখন স্ক্রিন 2 এ যুক্ত)। এই নতুন কার্যকারিতা / বৈশিষ্ট্য সমর্থন করার জন্য, মডেলটিতেও একই রকম নতুন পরিবর্তন হওয়া দরকার। নিয়ন্ত্রকের এখনও কিছু জিইআইআই-চালিত ইভেন্টের প্রতিক্রিয়া হিসাবে ডোমেন / মডেলটি চালিত করার দায়িত্ব রয়েছে।

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

যদি নিয়ামককে পরিবর্তন করতে হয় কারণ, বলুন, অধ্যবসায় স্তরটি একটি ফ্ল্যাট ফাইল থেকে একটি ডাটাবেসে পরিবর্তিত হয়, তবে নিয়ামক অবশ্যই এসআরপি লঙ্ঘন করছেন। যদি নিয়ামক সর্বদা বিমূর্ততার একই স্তরে কাজ করে তবে তা এসআরপি অর্জনে সহায়তা করতে পারে।


4

নিয়ামক এসআরপি লঙ্ঘন করে না। আপনি যেমন বলেছিলেন, মডেলগুলি এবং দর্শনগুলির মধ্যে মধ্যস্থতা করা এর দায়িত্ব।

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

ভিউতে একটি বোতাম টিপানোর অর্থ, কিছু করা কিন্তু যা সহজেই যা ঘটতে পারে তা অন্য যে কোনও সংখ্যায় বা এমনকি ভিউয়ের মাধ্যমে না হয়ে ট্রিগার করা যেতে পারে।

এসআরপি সম্পর্কে উইকিপিডিয়া নিবন্ধ থেকে

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

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

কল করার জন্য কোনও অবজেক্টের একটি পদ্ধতি রয়েছে তা জানা এবং এর কার্যকারিতা জানার মতো নয়।


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

1
যদি আমি একটি বোতাম টিপুন এবং এর অর্থটির মধ্যে সম্পূর্ণ পৃথকীকরণের ধারণাটি খাঁজ করি (যার ফলস্বরূপ নিয়ামকটির মতো পদ্ধতি রয়েছে specificButtonPressed()) তবে প্রকৃতপক্ষে নিয়ামকটি এতটা জিইউআইয়ের সাথে আবদ্ধ হবে না। আমি specificButtonPressed()পদ্ধতিগুলি খাদের উচিত ? এই পদ্ধতিগুলি ব্যবহার করে আমি যে সুবিধাটি অনুভব করি তা কি আপনার বোঝার জন্য? বা buttonPressed()নিয়ামক থাকা পদ্ধতিগুলি কি ঝামেলার পক্ষে নয়?
আভিভ কোহনে

1
অন্য কথায় (দীর্ঘ মন্তব্যের জন্য দুঃখিত): আমি মনে করি যে specificButtonPressed()কন্ট্রোলারে পদ্ধতি থাকার সুবিধাটি হ'ল এটি ভিউটিকে এর বোতাম টিপানোর অর্থ থেকে সম্পূর্ণ আলাদা করে দেয় । যাইহোক, অসুবিধাটি হ'ল এটি একটি অর্থে নিয়ামককে জিইউআইয়ের সাথে যুক্ত করে। কোন পদ্ধতির ভাল?
আভিভ কোহন

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

1

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

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

ভিউতে ইউআই প্রদর্শন করার এসআরপি রয়েছে এবং সেই ইউআইয়ের একটি অংশে একটি বোতাম রয়েছে যা অ্যাডটোকার্ট বলে says

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

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

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

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


0

কন্ট্রোলারদের কেবলমাত্র একটি দায়িত্ব থাকে: ব্যবহারকারীর ইনপুটের ভিত্তিতে অ্যাপ্লিকেশনগুলির স্থিতি পরিবর্তন করে।

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

source: wikipedia

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

তারপরে আবারও, রেল-স্টাইল অ্যাপ্লিকেশনগুলি শুরু করার জন্য সত্যিই এমভিসি নয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.