একজন নির্মাতা কতটা জটিল হওয়া উচিত


18

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

অন্যেরা কী ভাবেন? আমি সি # ব্যবহার করছি যদি এতে কোনও পার্থক্য আসে।

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

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


8
আমি একমত না নির্ভরতা বিপরীতার নীতিটি একবার দেখুন, অবজেক্ট এ এর ​​কনস্ট্রাক্টরের বৈধ অবস্থায় কোনও অবজেক্ট বিকে হস্তান্তর করা ভাল।
জিমি হোফা 18

5
আপনি কি জিজ্ঞাসা করছেন কতটা করা যায় ? কত করা উচিত ? বা আপনার নির্দিষ্ট পরিস্থিতি কতটা করা উচিত? এটি তিনটি খুব আলাদা প্রশ্ন।
ববসন

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

1
ববসন, আমি শিরোনামটি 'হ্যাড' এ পরিবর্তন করেছি। আমি এখানে সেরা অনুশীলনের জন্য বলছি।
তাইিন কিম

1
@ জিমিহোফা: সম্ভবত আপনার মন্তব্যটি একটি উত্তরে প্রসারিত করা উচিত।
কেভিন ক্লিন 21

উত্তর:


22

আপনার প্রশ্ন দুটি সম্পূর্ণ পৃথক অংশ থেকে গঠিত:

আমি কি কনস্ট্রাক্টর থেকে ব্যতিক্রম নিক্ষেপ করব, বা আমার পদ্ধতিটি ব্যর্থ হওয়া উচিত?

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

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

আমি কি কনস্ট্রাক্টরের কাছ থেকে "সিস্টেমের অন্যান্য অংশ যেমন ডিবি'র অ্যাক্সেস করতে পারি?

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


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

@ জিমিহোফা আমি কনস্ট্রাক্টর পদ্ধতি এবং নির্মাণের জন্য নির্দিষ্ট পদ্ধতির মধ্যে কোনও পার্থক্য দেখছি না।
ইওফোরিক

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

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

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

19

বিতৃষ্ণা।

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

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

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


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

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

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

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

1
@ জাত্রানা - হ্যাঁ, আরম্ভ করা ভাল নয়। কনস্ট্রাক্টর কিছু বুদ্ধিমান ডিফল্ট বা কারখানায় সূচনা করে বা তৈরি পদ্ধতি এটি তৈরি করে এবং ব্যবহারযোগ্য উদাহরণ দেয়।
তেলস্তিন

1

কনস্ট্রাক্টর - পদ্ধতির জটিলতা ভারসাম্য হ'ল ভাল স্টাইল সম্পর্কে আলোচনার বিষয়। বেশিরভাগ ক্ষেত্রে খালি কনস্ট্রাক্টর আরও জটিল জিনিসের জন্য Class() {}একটি পদ্ধতি Init(..) {..}ব্যবহার করা হয় with বিবেচনায় নেওয়া যুক্তিগুলির মধ্যে:

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

initপদ্ধতিটির আমার মতে সুবিধাটি হ'ল ব্যর্থতা হ্যান্ডল করা অনেক সহজ। বিশেষত, initপদ্ধতির রিটার্ন মান ইনিশিয়ালাইজেশন সফল কিনা তা নির্দেশ করতে পারে এবং পদ্ধতিটি বস্তুটি সর্বদা ভাল অবস্থায় থাকে তা নিশ্চিত করতে পারে।
pqnet
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.