ম্যানেজার ক্লাসগুলি কি খারাপ স্থাপত্যের লক্ষণ হতে পারে?

Question

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

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

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

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

ম্যানেজার ক্লাসগুলি কি সত্যই খারাপ স্থাপত্যের লক্ষণ?

Comments

আমি মনে করি Of course, mangers can be good. An obvious example is an EventManagerএটি ঠিক এখানে ব্যাখ্যা করে। ধারণার অপব্যবহার হ'ল খারাপ স্থাপত্য, তবে বৈধ ব্যবহারের ক্ষেত্রে রয়েছে। একই জিনিস বেশিরভাগ ক্ষেত্রেই সত্য।

অকল্পনীয় নামকরণের চিহ্ন হতে পারে বলে মনে হয়।

— পিডিআর

EventManagerএকটি শ্রেণীর জন্য ভয়ঙ্কর নাম। এটি অবশ্যই ঘটনাসহ কিছু করে, তবে কী ?

— ক্রিস্টোফার হামার্সট্রিম

এখানে সমস্যার অন্যতম একটি ভাষা সীমাবদ্ধতা steve-yegge.blogspot.com/2006/03/... ম্যানেজার শ্রেণীর nounifying ক্রিয়া কারণে প্রায়ই, মুক্ত ফাংশন কি সত্যিই চেয়েছিলেন হয়

— জে।

পরিচালকদের প্রায়শই প্রচুর শক্তি (দায়িত্ব) থাকে এবং তারা কোনও ব্যাবসা হতে পারে - যেমন কোনও অফিসের পরিবেশের মতো;) ইভেন্ট ম্যানেজারের অর্থ কিছুই নেই means ইভেন্টডিসপাচার এটি কী করে তা বর্ণনা করে।

— কোডার্ট

Answer 1

ব্যবস্থাপক ক্লাসগুলি কয়েকটি কারণে খারাপ স্থাপত্যের লক্ষণ হতে পারে:

• অর্থহীন শনাক্তকারী

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

• ভগ্নাংশ সংক্রান্ত দায়িত্ব

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

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

• কাঠামোগত বিমূর্ততা

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

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

আমরা একটি লিখতে Dispatcherএর Eventমূলত একই কারণে আমরা লিখতে জন্য দৃষ্টান্ত GarbageCollectorবা Factory:

একজন ম্যানেজার জানেন যে এর পেডলোডটি জানা উচিত নয়।

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

Comments

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

— ডিএক্সএম

হ্যাঁ হ্যাঁ, EventDispatcherআমি কিছুক্ষণের জন্য একটি ভাল নাম খোঁজার চেষ্টা করছি। : পি

— পল

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

— আর স্মিটজ

Answer 2

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

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

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

Answer 3

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

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

Answer 4

সংক্ষিপ্ত উত্তর: এটি নির্ভর করে ।

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

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

Comments

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

— user949300

Answer 5

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

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

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

Answer 6

ম্যানেজার ক্লাসগুলি কি খারাপ স্থাপত্যের লক্ষণ হতে পারে?

আপনি আপনার প্রশ্নের উত্তর দিয়েছেন: এগুলি কোনও খারাপ ডিজাইনের চিহ্ন হতে হবে না।

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

তবে, আপনি যদি কোনও ধারণার অপব্যবহার করেন তবে এটি একটি খারাপ নকশা এবং সম্ভবত স্থাপত্যের লক্ষণ।

Comments

প্রশ্ন-সংস্থায় - "আপনার ডিজাইনে প্রচুর পরিচালকের ক্লাস করা খারাপ জিনিস"। আমি বিশ্বাস করি ওপি সত্যই এটি জানতে চায়।

— ওডে

Answer 7

ক্লাসটির নামে যখন "ম্যানেজার" থাকে, তখন godশ্বর শ্রেণীর সমস্যা থেকে সাবধান থাকুন (অনেক বেশি দায়িত্বের সাথে একজন)। কোনও শ্রেণীর নামের সাথে কী কী দায়বদ্ধ তা বর্ণনা করা যদি অসুবিধা হয় তবে এটি একটি ডিজাইনের সতর্কতা চিহ্ন।

খারাপ ম্যানেজারের ক্লাসগুলি বাদ দিয়ে, আমি যে সবচেয়ে খারাপ নামটি দেখেছি তা হ'ল "ডেটা কন্টেইনারএডাপ্টার"

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

Answer 8

ম্যানেজার ক্লাসগুলি - যেমন "-er" দিয়ে শেষ হওয়া প্রায় কোনও ক্লাস যেমন খারাপ - তেমনি OOP এর সাথে কোনও সম্পর্ক নেই। সুতরাং আমার জন্য এটি খারাপ স্থাপত্যের লক্ষণ।

কেন? "-Er" নামটি বোঝায় যে একটি কোড ডিজাইনার কিছু পদক্ষেপ নিয়েছিল এবং এটিকে শ্রেণিতে রূপান্তর করেছে। ফলস্বরূপ আমাদের একটি কৃত্রিম সত্তা রয়েছে যা কোনও বাস্তব ধারণাকে প্রতিফলিত করে না, তবে কিছু ক্রিয়া করে। এটি খুব প্রক্রিয়াজাতীয় শোনায়।

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

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

এই জাতীয় অবজেক্টগুলিকে নিয়ন্ত্রণ করার দরকার নেই। তারা কী করতে হবে এবং কীভাবে করতে হবে তা জানে। সুতরাং ম্যানেজার ক্লাসগুলি ওওপি নীতিগুলি দু'বার ভঙ্গ করে। "-Er" শ্রেণি হওয়া ছাড়াও এটি অন্যান্য অবজেক্টগুলিকে নিয়ন্ত্রণ করে। তবে এটি যদিও ম্যানেজারের উপর নির্ভর করে। এটি তিনি নিয়ন্ত্রণ করেন - তিনি একজন খারাপ পরিচালক। যদি তিনি সমন্বয় করেন - তবে তিনি একজন ভাল পরিচালক। এজন্য এমভিসিতে একটি "সি" চিঠিটি "সমন্বয়কারী" হিসাবে বানান করা উচিত।

Comments

আপনি একটি আকর্ষণীয় বিষয় তৈরি করেছেন তবে আমি এখনও অবাক হয়েছি আপনি কীভাবে একটি "সত্তা পরিচালক" বিভাগ করবেন? আমার ব্যক্তিগত ব্যাকগ্রাউন্ড থেকে, একটি <entity> পরিচালক কোনও নির্দিষ্ট <entity> এর CRUD অপারেশনের জন্য বোঝানো হয়। এটি কি ডোমেন মডেলকে রক্তাল্পতা হতে পরিচালিত করে? আমি তা মনে করি না, শুধু না "সক্রিয় রেকর্ড"। তদুপরি আমরা কোনও "সত্তা পরিচালক" সত্তার সামগ্রিক যৌগিক CRUD সমন্বয় যুক্তিকে রাখতে পারি না? আমি এর জন্য আরও ভাল জায়গা দেখতে পাচ্ছি না। সুতরাং এটিকে কোনওভাবে

— সিআরইউডি

সকল আমি ORM এর concep সম্পর্কে বলার পারে medium.com/@wrong.about/you-dont-need-an-orm-7ef83bd1b37d

— Zapadlo

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

— ক্লেমিসি

Answer 9

এই প্রশ্নের সঠিক উত্তর হ'ল:

1. এটা নির্ভর করে.

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