একক পদ্ধতি সহ ক্লাস - সেরা পদ্ধতির?

Question

বলুন আমার একটি ক্লাস রয়েছে যার অর্থ একটি একক ফাংশন সম্পাদন করা। ফাংশন সম্পাদন করার পরে, এটি ধ্বংস করা যেতে পারে। এই পদ্ধতির একটি পছন্দ করার কোনও কারণ আছে কি?

// Initialize arguments in constructor
MyClass myObject = new MyClass(arg1, arg2, arg3);
myObject.myMethod();

// Pass arguments to method
MyClass myObject = new MyClass();
myObject.myMethod(arg1, arg2, arg3);

// Pass arguments to static method
MyClass.myMethod(arg1, arg2, arg3);

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

Answer 1

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

পলিমরফিজ্ম
বলুন আমরা পদ্ধতি UtilityClass.SomeMethod যে সুখে বরাবর buzz গুলি আছে। হঠাৎ আমাদের কার্যকারিতা কিছুটা পরিবর্তন করতে হবে। বেশিরভাগ কার্যকারিতা একই, তবে তবুও আমাদের কয়েকটি অংশ পরিবর্তন করতে হবে। এটি কোনও স্থিতিশীল পদ্ধতি না থাকলে আমরা একটি ডাইরিভেট শ্রেণি তৈরি করতে পারি এবং প্রয়োজনীয় পদ্ধতি পদ্ধতির সামগ্রীটি পরিবর্তন করতে পারি। এটি একটি স্থিতিশীল পদ্ধতি হিসাবে, আমরা পারি না। অবশ্যই, যদি আমাদের কেবল পুরাতন পদ্ধতির আগে বা পরে কার্যকারিতা যুক্ত করতে হয় তবে আমরা একটি নতুন শ্রেণী তৈরি করতে পারি এবং এর মধ্যে পুরানোটিকে কল করতে পারি - তবে এটি কেবল স্থূল।

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

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

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

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

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

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

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

Comments

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

— থমাস ডাব্লু

"যেমন একটি সিস্টেম বৃদ্ধি পায় ..." আপনি অদ্বিতীয়?

— রডনি গিটসেল

@ user3667089 সাধারণ যুক্তি যা ক্লাসের পক্ষে যুক্তিযুক্তভাবে অস্তিত্বের জন্য প্রয়োজন, আমি সেগুলি কনস্ট্রাক্টারে পাস করব। এগুলি বেশিরভাগ / সমস্ত পদ্ধতিতে ব্যবহৃত হবে। আমি নির্দিষ্ট পদ্ধতিটিতে পাস করেছি নির্দিষ্ট যুক্তিগুলির পদ্ধতি।

— মার্ক এস রাসমুসেন

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

— প্রকৌশলী

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

— জাস্টিন জে স্টার্ক

Answer 2

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

যে ক্লাসগুলি কেবলমাত্র তাদের পদ্ধতির জন্য বিদ্যমান তা স্থির রেখে দেওয়া উচিত।

Comments

-1 "কেবলমাত্র তাদের পদ্ধতির জন্য বিদ্যমান ক্লাসগুলি স্থির রেখে দেওয়া উচিত।"

— রুকিয়ান

@ রুকিয়ান আপনি এর সাথে কেন একমত নন?

— jjnguy

উদাহরণ হ'ল সংগ্রহস্থল নিদর্শন। শ্রেণিতে কেবলমাত্র পদ্ধতি রয়েছে। আপনার পদ্ধতির অনুসরণ করে ইন্টারফেস ব্যবহার করার অনুমতি দেয় না। => সংযুক্তি বাড়ান

— রোকিয়ান

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

— jjnguy

একেবারে সঠিক :) আপনার সাধারণ উপকরণের পদ্ধতিগুলির জন্য আপনার কনডিটনের সাথে আমি আপনার সাথে সম্পূর্ণ একমত, তবে আপনি নিজের উত্তরে একটি সাধারণ নিয়ম তৈরি করেছিলেন যা ভুল ইমো is

— রুকিয়ান

Answer 3

যদি ফাংশনটি সম্পাদন করার জন্য শ্রেণীর কোনও উদাহরণ তৈরি করার কোনও কারণ না থাকে তবে স্থির বাস্তবায়নটি ব্যবহার করুন। যখন এই শ্রেণীর গ্রাহকরা যখন প্রয়োজন হয় না তখন কেন একটি দৃষ্টান্ত তৈরি করে।

Answer 4

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

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

Answer 5

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

Answer 6

আমি পরিস্থিতিটি এখানে আসলে কী তা জানি না, তবে আমি এটিকে আর্গ 1, আর্গ 2 বা আরজি 3 এর সাথে সংযুক্ত একটি শ্রেণিতে একটি পদ্ধতি হিসাবে এটিকে রাখার দিকে তাকিয়ে দেখব - যদি আপনি শব্দার্থভাবে বলতে পারেন যে এই শ্রেণীর একটির মালিকানা ছিল পদ্ধতি।

Answer 7

আমি পরামর্শ দিচ্ছি যে সরবরাহ করা তথ্যের ভিত্তিতে এর কঠিন উত্তর দেওয়া উচিত।

আমার অন্ত্রটি হ'ল যদি আপনি কেবল একটি পদ্ধতি নিয়ে চলেছেন এবং আপনি অবিলম্বে ক্লাসটি ফেলে দিতে চলেছেন, তবে এটি একটি স্ট্যাটিক ক্লাস করুন যা সমস্ত পরামিতি নেয়।

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

উদাহরণস্বরূপ, ক্লাসটি প্লাগযোগ্য হতে হবে। তারপরে আপনি আপনার একটি পদ্ধতির জন্য একটি ইন্টারফেস তৈরি করতে চান এবং তারপরে আপনি সমস্ত প্যারামিটারগুলি কনস্ট্রাক্টরের পরিবর্তে ইন্টারফেসে পাস করতে চান, তবে আপনি এটি স্থির রাখতে চান না।

Answer 8

আপনার ক্লাস স্থির করা যেতে পারে?

যদি তা হয় তবে আমি এটি একটি 'ইউটিলিটিস' শ্রেণি তৈরি করব যা আমি আমার সমস্ত এক-ফাংশন ক্লাসে রেখে দেব।

Comments

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

— পল টমবলিন

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

— জন রুডি 18

এক শ্রেণি- এক স্বাচ্ছন্দ্য।

— আন্দ্রেয় পিটারসন 18

Answer 9

যদি এই পদ্ধতিটি রাষ্ট্রবিহীন হয় এবং আপনার এটিকে পাশ কাটাতে হবে না, তবে এটি স্থির হিসাবে সংজ্ঞায়িত করার পক্ষে সবচেয়ে সার্থকতা তৈরি হয়। আপনার যদি পদ্ধতিটি পাস করার প্রয়োজন হয় তবে আপনি অন্য প্রস্তাবিত পদ্ধতির পরিবর্তে কোনও প্রতিনিধি ব্যবহারের কথা বিবেচনা করতে পারেন ।

Answer 10

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

• সেবা
  • একটি I[ServiceName]Serviceইন্টারফেস দ্বারা সংজ্ঞায়িত ।
  • ইন্টারফেস ধরণ দ্বারা রফতানি এবং আমদানি করা।
  • একক বাস্তবায়ন হোস্ট অ্যাপ্লিকেশন দ্বারা সরবরাহ করা হয় এবং অভ্যন্তরীণভাবে এবং / অথবা এক্সটেনশন দ্বারা গ্রাস করা হয়।
  • পরিষেবা ইন্টারফেসের পদ্ধতিগুলি থ্রেড-নিরাপদ।

স্বীকৃত উদাহরণ হিসাবে:

public interface ISettingsService
{
    string ReadSetting(string name);

    void WriteSetting(string name, string value);
}

[Export]
public class ObjectRequiringSettings
{
    [Import]
    private ISettingsService SettingsService
    {
        get;
        set;
    }

    private void Foo()
    {
        if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
        {
            // whatever
        }
    }
}

Answer 11

আমি কেবল কনস্ট্রাক্টরের সব কিছু করব। তাই ভালো:

new MyClass(arg1, arg2, arg3);// the constructor does everything.

অথবা

MyClass my_object(arg1, arg2, arg3);

Comments

আপনি যদি মাই ক্লাস টাইপের কোনও অবজেক্ট ছাড়াও কোনও কিছু ফেরত দিতে চান?

— বিল

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

— mstrobl

বিল, আপনার যদি ফেরতের মানের প্রয়োজন হয়, তবে ret ভ্যালুতে রেফারেন্স দিন: মাই ক্লাস মাইওবজেক্ট (আরজি 1, আরজি 2, আরজি 3, রিটভ্যালু); mstrobl, যদি বস্তুর প্রয়োজন না হয় তবে কেন এটি তৈরি করবেন? এবং এই কৌশলটি আপনাকে বাস্তবে কিছু ক্ষেত্রে সহায়তা করতে পারে।

যদি কোনও জিনিসের কোনও রাজ্য থাকে না, অর্থাত্ কোনও ভার্স না থাকে তবে তা তাত্ক্ষণিকভাবে কোনও বরাদ্দ উত্পাদন করতে পারে না - গাদা বা স্ট্যাকেরও নয়। আপনি সি ++ তে অবজেক্ট সম্পর্কে ভাবতে পারেন ঠিক যেমন সি ফাংশন কল হিসাবে কোনও লুকানো প্রথম প্যারামিটারের সাথে কোনও কাঠামোর দিকে নির্দেশ করে।

— mstrobl

তবে, এটি স্টেরয়েডগুলিতে এসি ফাংশন পছন্দ করে কারণ আপনি ব্যক্তিগত ফাংশনগুলি সংজ্ঞায়িত করতে পারেন যা কর্টর ব্যবহার করতে পারেন। আপনি ব্যক্তিগত ফাংশনে ডেটা প্রেরণে সহায়তা করতে শ্রেণীর সদস্য ভেরিয়েবলগুলিও ব্যবহার করতে পারেন।

Answer 12

আরও একটি গুরুত্বপূর্ণ বিষয় বিবেচনা করার বিষয়টি হ'ল সিস্টেমটি কোনও বহু-বিস্তৃত পরিবেশে চলবে কিনা এবং স্থির পদ্ধতি বা ভেরিয়েবলগুলি থ্রেড-নিরাপদ হবে কিনা ...

আপনার সিস্টেমের অবস্থানে মনোযোগ দেওয়া উচিত।

Answer 13

আপনি একসাথে পরিস্থিতি এড়াতে সক্ষম হতে পারেন। রিফ্যাক্টর চেষ্টা করুন যাতে আপনি পান arg1.myMethod1(arg2, arg3)। আরগ 2 বা আরগ 3 এর সাথে আরগ 1 পরিবর্তন করুন যদি এটি আরও অর্থবোধ করে more

আরজি 1 এর ক্লাসে আপনার যদি নিয়ন্ত্রণ না থাকে তবে এটি সাজাই:

class Arg1Decorator
    private final T1 arg1;
    public Arg1Decorator(T1 arg1) {
        this.arg1 = arg1;
    }
    public T myMethod(T2 arg2, T3 arg3) {
        ...
    }
 }

 arg1d = new Arg1Decorator(arg1)
 arg1d.myMethod(arg2, arg3)

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

Answer 14

আমি মনে করি, যদি আপনার শ্রেণীর বৈশিষ্ট্য বা শ্রেণীর উদাহরণগুলি নির্মাণকারী বা আপনার পদ্ধতিগুলিতে ব্যবহার না করা হয় তবে পদ্ধতিগুলি 'স্ট্যাটিক' ধরণের মতো নকশাকৃত হওয়ার পরামর্শ দেওয়া হয় না। স্থির পদ্ধতিটি সর্বদা 'সহায়তা' উপায়ে চিন্তা করা উচিত।

Answer 15

আপনি কেবল কিছু করতে বা করতে চান এবং এই কাজটি করতে পারেন এমন কিছু ফিরিয়ে দিতে চান তা নির্ভর করে:

public abstract class DoSomethingClass<T>
{
    protected abstract void doSomething(T arg1, T arg2, T arg3);
}

public abstract class ReturnSomethingClass<T, V>
{
    public T value;
    protected abstract void returnSomething(V arg1, V arg2, V arg3);
}

public class DoSomethingInt extends DoSomethingClass<Integer>
{
    public DoSomethingInt(int arg1, int arg2, int arg3)
    {
        doSomething(arg1, arg2, arg3);
    }

    @Override
    protected void doSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        // ...
    }
}

public class ReturnSomethingString extends ReturnSomethingClass<String, Integer>
{
    public ReturnSomethingString(int arg1, int arg2, int arg3)
    {
        returnSomething(arg1, arg2, arg3);
    }

    @Override
    protected void returnSomething(Integer arg1, Integer arg2, Integer arg3)
    {
        String retValue;
        // ...
        value = retValue;
    }
}

public class MainClass
{
    static void main(String[] args)
    {
        int a = 3, b = 4, c = 5;

        Object dummy = new DoSomethingInt(a,b,c);  // doSomething was called, dummy is still around though
        String myReturn = (new ReturnSomethingString(a,b,c)).value; // returnSomething was called and immediately destroyed
    }
}