"ম্যানেজার" শ্রেণীর ব্যবহার কীভাবে হ্রাস করবেন সে সম্পর্কে টিপস / পরামর্শ?

Question

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

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

Comments

প্রোগ্রামার্স.স্ট্যাকেক্সেঞ্জার.কম / সেকশনস /59866/… এর উত্তর আপনার পক্ষে কার্যকর হতে পারে।

— Tesserex

তারা বা কারা "পরিচালনা করছেন", সেই শ্রেণীর যুক্তি কী? নিজেকে এই প্রশ্নগুলি জিজ্ঞাসা করুন এবং আপনাকে এই শ্রেণীর যুক্তি যুক্ত করতে বা প্রসারিত করতে বা হ্রাস করতে সহায়তা করতে পারে।

— umlcat

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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