কোনও কনস্ট্রাক্টরে আইনী "আসল কাজ"?


23

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

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

তবে আমি পড়া চালিয়ে যাচ্ছি যে কোনও নির্মাণকারীর কোনও আসল কাজ করা উচিত নয় (যেমন দোষ: কনস্ট্রাক্টর রিয়েল ওয়ার্ক করে )। এটি "সত্যিকারের কাজ" এর অর্থ ভারী ওজন নির্ভর অবজেক্টগুলি তৈরি করা যা পরে পরবর্তীতে পরীক্ষার জন্য বাইরে যেতে চাইলে তা আমার কাছে সঠিক ধারণা দেয় sense (এগুলি ডিআই এর মাধ্যমে পাস করা উচিত))

তবে এই নোড গাছের মতো হালকা-ওজনমূল্যের জিনিসগুলির কী হবে? গাছটি কোথাও তৈরি করতে হবে, তাই না? মডেলডিফের নির্মাণকারীর মাধ্যমে কেন নয় (বলুন, একটি বিল্ডনোডট্রি () পদ্ধতি)?

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

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


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

উত্তর:


26

এবং রস প্যাটারসনের পরামর্শ ছাড়াও এই অবস্থানটি বিবেচনা করুন যা হুটো বিপরীত:

  1. সর্বাধিক গ্রহণ করুন যেমন "তুমি তোমার নির্মাতাদের কোনও সত্যিকারের কাজ করবে না" লবণের দানা দিয়ে।

  2. একজন কনস্ট্রাক্টর হ'ল স্থির পদ্ধতি ব্যতীত আর কিছুই নয়। সুতরাং, কাঠামোগতভাবে, এর মধ্যে সত্যিই খুব বেশি পার্থক্য নেই:

    ক) একটি সাধারণ নির্মাতা এবং জটিল স্ট্যাটিক কারখানার পদ্ধতিগুলির একটি গুচ্ছ এবং

    খ) একটি সাধারণ কনস্ট্রাক্টর এবং আরও জটিল নির্মাতাদের একগুচ্ছ।

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

আমার অভিমত হ'ল আপনি যদি কেবল newকনস্ট্রাক্টর ব্যবহার করা থেকে বিরত থাকেন, (যেমন নির্ভরতা ইনজেকশন নিযুক্ত করার আপনার উদ্দেশ্যটি ইঙ্গিত করে) আপনার ভাল হওয়া উচিত। "কনস্ট্রাক্টরের শর্তসাপেক্ষ বা লুপিং লজিক একটি ত্রুটির একটি সতর্কতা লক্ষণ" এর মত বিবৃতিতে আমি হাসি।

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

সংশোধন

আমি অনুমান করি যে আপনার যদি এমন কোনও পদ্ধতি থাকে ModelDefযার বাইরে ModelDefএক্সএমএল তৈরি হয় তবে আপনাকে কিছু গতিশীল অস্থায়ী গাছের ডেটা কাঠামো ইনস্ট্যান্ট করতে হবে, এটি আপনার এক্সএমএলকে বিশ্লেষণ করে পপুলেট করতে হবে এবং তারপরে আপনার ModelDefকাঠামোটি কনস্ট্রাক্টর প্যারামিটার হিসাবে তৈরি করতে হবে । সুতরাং, এটি সম্ভবত "নির্মাতা" প্যাটার্নের একটি অ্যাপ্লিকেশন হিসাবে ভাবা যেতে পারে। আপনি যা করতে চান তার String& StringBuilderজুটির মধ্যে খুব ঘনিষ্ঠ সাদৃশ্য রয়েছে । তবে, আমি এই প্রশ্নোত্তর খুঁজে পেয়েছি যা মনে হয় না বলে মনে হয়, যে কারণে আমার কাছে স্পষ্ট নয়: স্ট্যাকওভারফ্লো - স্ট্রিংবিল্ডার এবং বিল্ডার প্যাটার্ন । সুতরাং, StringBuilder"বিল্ডার" প্যাটার্নটি করে বা না তা বাস্তবায়ন করে না সে সম্পর্কে দীর্ঘ বিতর্ক এড়াতে , আমি বলতে চাই যে কীভাবে অনুপ্রাণিত হয়ে নির্দ্বিধায়StrungBuilder আপনার প্রয়োজন অনুসারে এমন একটি সমাধান নিয়ে কাজ করে যা এই সংক্ষিপ্ত বিবরণ নিষ্পত্তি না হওয়া পর্যন্ত এটিকে "নির্মাতা" প্যাটার্নের একটি অ্যাপ্লিকেশন বলা স্থগিত করে।

এই একেবারে নতুন প্রশ্নটি দেখুন: প্রোগ্রামারস এসই: "স্ট্রিংবিল্ডার" কি বিল্ডার ডিজাইন প্যাটার্নের একটি অ্যাপ্লিকেশন?


3
@ রিচার্ড লিভাসিউর আমি কেবল এটি মনে করেছি নব্বইয়ের দশকের গোড়ার দিকে সি ++ প্রোগ্রামারদের মধ্যে এটি উদ্বেগ এবং বিতর্কের বিষয় হিসাবে পরিণত হয়েছিল। আপনি যদি এই পোস্টটি দেখুন: getw.ca/gotw/066.htm আপনি দেখতে পাবেন যে এটি মোটামুটি জটিল এবং মোটামুটি জটিল জিনিসগুলি বিতর্কিত হতে থাকে। আমি নিশ্চিতভাবে জানি না, তবে আমি মনে করি যে নব্বইয়ের দশকের গোড়ার দিকে সেই স্টাফের অংশটি এখনও মানসম্মত হয়নি। তবে দুঃখিত, আমি একটি ভাল রেফারেন্স দিতে পারি না।
মাইক নকিস

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

1
@ গুর্তজ তাই, আমি সম্ভবত তাদেরকে মূল "অ্যাপ্লিকেশন" শ্রেণির উদাহরণগুলি তৈরি করব, বা যদি এটি খুব বেশি ঝামেলা হয় তবে কিছু সহায়ক শ্রেণীর স্থির পদ্ধতিগুলি রস প্যাটারসনের পরামর্শের সাথে একেবারেই অনুরূপ।
মাইক নকিস

1
@ গুর্তজ "বিল্ডার" পদ্ধতির আগে বিশেষভাবে সম্বোধন না করার জন্য দুঃখিত। আমি আমার উত্তর সংশোধন করেছি।
মাইক নাকিস

3
@ গুর্তজ এটি সম্ভব তবে একাডেমিক কৌতূহলের বাইরে এটি কোনও বিষয় নয়। "প্যাটার্ন অ্যান্টি-প্যাটার্ন" এ চুষবেন না। অন্যদের কাছে সুবিধার্থে সাধারণ / দরকারী কোডিং কৌশলগুলি বর্ণনা করার জন্য প্যাটার্নগুলি সত্যই কেবল নাম। আপনার যা করতে হবে তা করুন, আপনার যদি এটির বর্ণনা দেওয়ার দরকার হয় তবে পরে এটিতে একটি লেপ চাপুন। যতক্ষণ না আপনার কোডটি বোঝায় ততক্ষণ "এমনভাবে বিল্ডার প্যাটার্নের মতো, কোনওভাবে, সম্ভবত" এমন কোনও কিছু কার্যকর করা ঠিক OK নতুন কৌশলগুলি শেখার সময় নিদর্শনগুলিতে ফোকাস করা যুক্তিসঙ্গত, কেবল আপনি যে কিছু করেন তা অবশ্যই কিছু নামকৃত প্যাটার্ন হতে হবে এমন ভেবে কোনও ফাঁদে পড়বেন না।
জেসন সি

9

আপনি ইতিমধ্যে নির্মাতায় এই কাজ না করার সর্বোত্তম কারণ প্রদান করেছেন ModelDef:

  1. কোনও এক্সএমএল ডকুমেন্টকে নোড ট্রিতে পার্স করার বিষয়ে "লাইটওয়েট" কিছুই নেই।
  2. এ সম্পর্কে স্পষ্ট কিছু নেই ModelDefযা বলে যে এটি কেবলমাত্র একটি এক্সএমএল নথি থেকে তৈরি করা যেতে পারে।

এটা তোলে শোনাচ্ছে আপনার বর্গ মতো স্ট্যাটিক বিভিন্ন পদ্ধতি থাকা উচিত ModelDef.FromXmlString(string xmlDocument), ModelDef.FromXmlDoc(XmlDoc parsedNodeTree), ইত্যাদি


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

3
ভিতরে বসার জন্য আমাকে ক্ষমা করুন, তবে হ্যাঁ, রস বলতে যা বোঝায় তা হ'ল স্থির কারখানার পদ্ধতি যা সম্পূর্ণরূপে নির্মিত দৃষ্টান্তগুলিতে ফিরে আসে। পুরো প্রোটোটাইপ কিছু হবে public static ModelDef createFromXmlString( string xmlDocument )। এটি মোটামুটি সাধারণ অনুশীলন। মাঝে মাঝে আমি এটাও করি। আমার পরামর্শ আপনি যে কেবল নির্মাতারা করতে পারেন তা আমার এমন একটি স্ট্যান্ডার্ড ধরণের প্রতিক্রিয়া, যেখানে আমার সন্দেহ হয় যে বিকল্প কারণগুলি কোনও কারণ ছাড়াই "কোশার নয়" হিসাবে বরখাস্ত করা হয়েছে।
মাইক নকিস

1
@ মাইক-নাকিস, স্পষ্ট করার জন্য ধন্যবাদ। সুতরাং এই ক্ষেত্রে স্থির কারখানা পদ্ধতি নোড ট্রি তৈরি করবে এবং তারপরে মডেলডেফের কনস্ট্রাক্টরের (সম্ভবত ব্যক্তিগত) প্রেরণ করবে। ধারণা তৈরী কর. ধন্যবাদ।
গুরুটজ

নিখুঁতভাবে
রস প্যাটারসন

5

আমি আগে "নিয়ম" শুনেছি। আমার অভিজ্ঞতায় এটি সত্য এবং মিথ্যা উভয়ই।

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

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

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

তাহলে কে ঠিক আছে?

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

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


এটি একটি দুর্দান্ত উত্তর।
জড়হালি

0

এই নিয়মের সাথে একটি মৌলিক সমস্যা আছে এবং এটিই, "আসল কাজ" কে কী গঠন করে?

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

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

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

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

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

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