স্থির ভেরিয়েবলগুলিকে কেন মন্দ হিসাবে বিবেচনা করা হয়?

Question

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

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

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

পিএস: স্ট্যাটিক্স সম্পর্কে আমার অনুমানগুলি ভুল হলে দয়া করে আমাকে সংশোধন করুন।

Comments

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

— মরিসিও লিনহারেস

আপনার দেওয়া কমপক্ষে একটি বিবৃতি বরং কৌতূহলযুক্ত: "স্ট্যাটিকস কোডের অন্যান্য অংশের আন্তঃনির্ভরতা হ্রাস করে"। সাধারণভাবে তারা নির্ভরতা শক্ত করে। কলটি করা কোডটি কল কোডটির সাথে খুব দৃ .়ভাবে আবদ্ধ হয়। এর মধ্যে কোনও বিমূর্ততা নেই, প্রত্যক্ষ নির্ভরতা।

— আর্নে

ভাল প্রশ্ন ... একটি প্রোগ্রামার.এসই প্রশ্ন আরও?

— ওয়ার্নার সিডি

আপনার দ্বিতীয় অনুচ্ছেদটি সম্পূর্ণ ভিন্ন বিষয়ে, যেমন স্থির পদ্ধতি সম্পর্কে ।

— পল

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

— new123456

Answer 1

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

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

Comments

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

— এম প্ল্যাটভোয়েট

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

— জন স্কিটে

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

— জাস্টিন মরগান

@ এম প্ল্যাটভয়েট - টেস্টাবিলিটি পুনরায় ব্যবহারযোগ্যতাগুলিকেও প্রভাবিত করে, যেহেতু একটি ডিকপল্ড ক্লাস সাধারণত পুনরায় ব্যবহার করা সহজ।

— ট্রুয়েল উইল

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

— দাউদ ইবনে করিম

Answer 2

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

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

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

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

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

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

Comments

আমি আপনার উত্তরটি পছন্দ করি, আমি মনে করি এটি একচেটিয়া এবং সুযোগের মতো লাল রঙের হার্নিংয়ের চেয়ে কিছুটা স্ট্যাটিক্সের আশেপাশে বিবেচনা করার জন্য সঠিক ট্রেড অফকে কেন্দ্র করে। এবং সিলেটলেটের জন্য +1, স্ট্যাটিক ভেরিয়েবল / পদ্ধতি বনাম

— সিলেটলেটগুলি

যদিও সিঙ্গলটন নিজেই থ্রেড-নিরাপদ হতে পারে (উদাহরণস্বরূপ synchronizedপদ্ধতি ব্যবহার করে), এর অর্থ এই নয় যে কলিং কোডটি সিঙ্গলটন রাজ্যের ক্ষেত্রে রেস শর্ত মুক্ত।

— অ্যান্ড্রি ক্যারন

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

— অ্যান্ড্রি ক্যারন

তৃতীয় অনুচ্ছেদের শেষ লাইনে আপনার সমস্ত অ-স্থির ভেরিয়েবলগুলি পড়তে হবে , যদি আমি ভুল না করি aken

— স্টিভ

Object Lifetime, @ জেসিকা উল্লিখিত একটি অত্যন্ত গুরুত্বপূর্ণ বিষয়।

— অভিদীমন

Answer 3

মন্দ একটি বিষয়গত শব্দ।

আপনি সৃষ্টি এবং ধ্বংসের ক্ষেত্রে স্ট্যাটিক্স নিয়ন্ত্রণ করেন না। তারা প্রোগ্রাম লোডিং এবং আনলোড লোডের নির্দেশে বাস করে।

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

এগুলি আমার কাছে দুটি প্রধান সমস্যা।

Answer 4

না। গ্লোবাল রাজ্যগুলি প্রতি সেজে মন্দ নয়। আপনি আপনার কোডটি সঠিকভাবে ব্যবহার করেছেন কিনা তা দেখতে আমাদের কোড দেখতে হবে। এটা সম্ভব যে কোনও নবাগত বিশ্বব্যাপী রাজ্যগুলিকে আপত্তি জানায়; ঠিক সে যেমন প্রতিটি ভাষার বৈশিষ্ট্যকে গালি দেয়।

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

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

X বসন্তের লোকদের মতো যারা এক্সএমএলে দুর্দান্তভাবে বিশ্বব্যাপী রাজ্যগুলি ঘোষণা করে এবং কোনওরকম এটি উচ্চতর বলে মনে করে।

@ জোন স্কিটিতে if I create a new instance of an objectএখন আপনার কাছে দুটি বিষয় যুক্তিযুক্ত রয়েছে - অবজেক্টের মধ্যে থাকা রাষ্ট্র এবং অবজেক্টটিকে হোস্টিংয়ের পরিবেশের অবস্থা।

Comments

"আমার কাছে যুক্তিযুক্ত দুটি বিষয় রয়েছে"। আমি যদি আমার পরীক্ষাটি কেবলমাত্র বস্তুর অবস্থার উপর নির্ভর করি না dependent যা সহজ, আমার কাছে কম বিশ্বব্যাপী রাষ্ট্র।

— ডিজে ক্লেওয়ার্থ

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

— ফ্লয়েজিপোকি

Answer 5

স্ট্যাটিক ভেরিয়েবলের সাথে 2 টি প্রধান সমস্যা রয়েছে:

• থ্রেড সুরক্ষা - স্থির সংস্থানগুলি সংজ্ঞায়িত হয় থ্রেড-নিরাপদ নয়
• কোড ইম্পিলিটি - কখনই স্ট্যাটিক ভেরিয়েবল ইনস্ট্যান্ট হয় এবং অন্য স্ট্যাটিক ভেরিয়েবলের আগে তা ইনস্ট্যান্ট করা হবে কিনা তা আপনি জানেন না

Comments

আমি মনে করি যে জোন স্কিটি আপনার পোস্ট করা একই মন্তব্যটিকে পুনরায় উল্লেখ করছে।

— আরজি -3

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

— Zmaster

@ জাস্টমাস্টার - যদিও এটি সত্য যে থ্রেড-সুরক্ষা স্থিতিশীল ভেরিয়েবলগুলির সাথে একচেটিয়া ইস্যু নয়, কারণ তাদের সংজ্ঞা অনুসারে এগুলি বিভিন্ন প্রসঙ্গে এবং তাদের কাছে ডাকা উচিত, তারা তাদের কাছে আরও ছাঁটাই করে

— স্টার্নার

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

— Zmaster

স্থির সংস্থানগুলির বৈধ থ্রেড নিরাপদ ব্যবহার রয়েছে, উদাহরণস্বরূপ। প্রাইভেট স্ট্যাটিক ফাইনাল লগার LOG = লগার.সেটলোগার (Foo.class); বেসরকারী স্থিতিশীল চূড়ান্ত পরমাণুInteger x = নতুন অ্যাটমিকআইন্টিজার (0); আমি এটি যেমন বুঝতে পারি, শ্রেণীর লোডার দ্বারা এই জাতীয় সংস্থার স্থির অ্যাসাইনমেন্টগুলি গ্যারান্টিযুক্ত থ্রেড-নিরাপদ। লগার উদাহরণটি যেখানে আপনি পয়েন্টারটিকে এটি নির্ধারণ করেছেন সেখানে স্বাধীনভাবে থ্রেড-নিরাপদ নয়। স্ট্যাটিক্সে রাষ্ট্র বজায় রাখা সম্ভবত একটি ভাল ধারণা নয়, তবে এটি থ্রেড-নিরাপদ না হওয়ার কোনও কারণ নেই।

— টেকনোপল

Answer 6

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

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

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

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

আপনি যদি আরও বিশদ চান, দয়া করে পড়ুন…

স্ট্যাটিকস কেন ব্যবহার করবেন না?

স্ট্যাটিক্সের সাথে অনেকগুলি বিষয় রয়েছে যেমন টেস্ট লেখার এবং সম্পাদন করার পাশাপাশি সূক্ষ্ম বাগগুলি যা তাত্ক্ষণিকভাবে সুস্পষ্ট নয়।

স্ট্যাটিক অবজেক্টের উপর নির্ভর করে এমন কোডগুলি সহজেই ইউনিট পরীক্ষা করা যায় না এবং স্ট্যাটিক্স সহজেই উপহাস করা যায় না (সাধারণত)।

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

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

গ্রাহকদাওকে তাত্ক্ষণিকভাবে তৈরি করা এবং এটি নির্মাণের পরে কাস্টমারফিল্টারে পাস করা আরও ভাল পদ্ধতির। (এর চেয়েও ভাল উপায় হ'ল বসন্ত বা নিয়ন্ত্রণের কাঠামোর অন্য কোনও বিপরীতমুখী ব্যবহার করা।

একবার আপনি এটি করার পরে, আপনি দ্রুত আপনার গ্রাহক ফিল্টারটেষ্টে একটি বিকল্প ডিএওর উপহাস বা স্টক করতে পারেন, যা আপনাকে পরীক্ষার উপর আরও নিয়ন্ত্রণ রাখতে দেয়,

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

কার্যকর পরীক্ষা

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

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

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

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

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

সবচেয়ে খারাপ, ব্যর্থতা পরীক্ষা করা হয়েছিল সেই আদেশের ভিত্তিতে হতে পারে।

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

সূক্ষ্ম বাগ

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

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

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

আনসাইড: স্ট্যাটিক ফাইনাল

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

সারসংক্ষেপ

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

Answer 7

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

স্ট্যাটিকস কোডের অন্যান্য অংশের আন্তঃ নির্ভরতা হ্রাস করে। তারা নিখুঁত রাষ্ট্রধারীদের হিসাবে কাজ করতে পারে

আমি আশা করি আপনি লক ব্যবহার এবং বিতর্ক মোকাবেলা করতে প্রস্তুত।

* আসলে প্রীত সংঘ উল্লেখ করেছেন।

Comments

ইনস্ট্যান্স ভেরিয়েবলের স্ট্যাটিক্সের তুলনায় কোনও থ্রেড-সুরক্ষা সুবিধা নেই, এগুলি সকলেই অরক্ষিত ভেরিয়েবল। পরিবর্তে, আপনি কীভাবে সেই কোডগুলিকে অ্যাক্সেস করে সেই কোডটি কীভাবে সুরক্ষিত করবেন সেদিকে এটি সমস্ত কিছু নেমে আসে।

— স্টাডিজিক

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

— জাস্টিন এম কিজ 21

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

— সুপারক্যাট

Answer 8

জাভাতে স্থির পদ্ধতি ব্যবহারের কয়েকটি বুনিয়াদি সুবিধা এবং অসুবিধাগুলির সংক্ষিপ্তসার:

সুবিধাদি:

1. বিশ্বব্যাপী অ্যাক্সেসযোগ্য অর্থাৎ কোনও নির্দিষ্ট বস্তুর উদাহরণের সাথে আবদ্ধ নয়।
2. জেভিএম প্রতি একটি উদাহরণ।
3. শ্রেণীর নাম ব্যবহার করে অ্যাক্সেস করা যেতে পারে (কোনও বস্তুর প্রয়োজন নেই)।
4. সমস্ত দৃষ্টান্তের জন্য একক মান প্রযোজ্য।
5. জেভিএম স্টার্টআপে লোড আপ হয় এবং জেভিএম বন্ধ হয়ে গেলে মারা যায়।
6. তারা অবজেক্টের স্থিতি পরিবর্তন করে না।

অসুবিধা:

1. স্থির সদস্যরা ব্যবহারে থাকুক বা না থাকুক সর্বদা স্মৃতির অংশ।
2. আপনি স্থিতিশীল ভেরিয়েবলের সৃষ্টি এবং ধ্বংস নিয়ন্ত্রণ করতে পারবেন না। কার্যকরভাবে এগুলি প্রোগ্রাম লোডিং-এ তৈরি করা হয়েছে এবং প্রোগ্রামটি আনলোড করার সময় (বা জেভিএম বন্ধ হয়ে গেলে) ধ্বংস করা হয়েছে।
3. আপনি সিঙ্ক্রোনাইজ ব্যবহার করে স্ট্যাটিক্স থ্রেডকে নিরাপদ করতে পারেন তবে আপনার কিছু অতিরিক্ত প্রচেষ্টা দরকার।
4. যদি কোনও থ্রেড স্থিতিশীল ভেরিয়েবলের মান পরিবর্তন করে যা সম্ভবত অন্যান্য থ্রেডের কার্যকারিতা ভঙ্গ করতে পারে।
5. এটি ব্যবহারের আগে আপনাকে অবশ্যই "স্থির" জানতে হবে।
6. আপনি স্থিতিশীল পদ্ধতিগুলিকে ওভাররাইড করতে পারবেন না।
7. সিরিয়ালাইজেশন তাদের সাথে ভাল কাজ করে না।
8. তারা রানটাইম পলিমারফিজমে অংশ নেয় না।
9. যদি প্রচুর সংখ্যক স্থিতিশীল ভেরিয়েবল / পদ্ধতি ব্যবহার করা হয় তবে একটি মেমোরি সমস্যা রয়েছে (কিছুটা হলেও আমি অনুমান করি না)। কারণ প্রোগ্রাম শেষ না হওয়া পর্যন্ত এগুলি আবর্জনা সংগ্রহ করা হবে না।
10. স্থিতিশীল পদ্ধতিগুলিও পরীক্ষা করা শক্ত।

Comments

6, 7, 8 এবং 10 এর অসুবিধাগুলি ব্যবহৃত ভাষা / ফ্রেমওয়ার্কগুলির অসুবিধাগুলি এবং সাধারণভাবে স্থির পরিবর্তনশীলগুলির অসুবিধা নয়। 1, 4 এবং 5 এর অসুবিধাগুলি অন্য সমাধানগুলির জন্যও রয়েছে, যেমন কিছু ফ্রেমওয়ার্কের দ্বারা সরবরাহিত কিছু সিঙ্গলটন প্যাটার্ন। (আমি উত্তরে ভোট

— দিইনি

Answer 9

যদি আমাকে কোনও ক্লাসের মধ্যে একটি ফাংশনে 10,000 কল করতে হয়, আমি পদ্ধতিটি স্থির করে তুলতে পেরে খুশি হব এবং ক্লাসের 10,000 টি উদাহরণের সাথে স্মৃতিশক্তি নাশকতার পরিবর্তে এটিতে একটি সরল শ্রেণির জন্য ব্যবহার করুন।

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

তবুও স্ট্যাটিকস কোডের অন্যান্য অংশের আন্তঃ নির্ভরতা হ্রাস করে।

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

অন্যান্য উত্তরগুলি স্ট্যাটিক্সের অতিরিক্ত ব্যবহারের বিরুদ্ধে ভাল কারণও সরবরাহ করে।

Answer 10

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

বলা হচ্ছে, নিয়মিত স্ট্যাটিক ভেরিয়েবল (সাধারণত খারাপ বলে বিবেচিত) এবং চূড়ান্ত স্ট্যাটিক ভেরিয়েবল (একে একে কনস্ট্যান্ট; এতটা খারাপ নয়) এর মধ্যে পার্থক্য করা গুরুত্বপূর্ণ।

Comments

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

— জেরেড আপডেটে

"স্ট্যাটিক ভেরিয়েবলগুলি উদাহরণস্বরূপ রাজ্যকে উপস্থাপন করে" এটি উল্লেখ করার একটি আরও ভাল উপায়। আমি আমার উত্তর সম্পাদনা করেছি।

— জ্যাক এডমন্ডস

Answer 11

আমার মতে এটি পারফরম্যান্স সম্পর্কে খুব কমই হয়, এটি ডিজাইন সম্পর্কে। স্ট্যাটিক ভেরিয়েবলের ব্যবহার হিসাবে প্রস্তাবিত হিসাবে আমি স্থির পদ্ধতির ব্যবহারকে ভুল বলে বিবেচনা করি না (তবে আমার ধারণা আপনি আসলে পদ্ধতি কল সম্পর্কে কথা বলছেন)।

এটি সহজভাবে যুক্তিগুলি কীভাবে বিচ্ছিন্ন করতে এবং এটিকে একটি ভাল স্থান দেওয়া যায় সে সম্পর্কে। কখনও কখনও এটি স্থির পদ্ধতিগুলির ব্যবহারকে ন্যায়সঙ্গত করে তোলে যার java.lang.Mathএকটি ভাল উদাহরণ। আমি মনে করি আপনি যখন আপনার ক্লাসগুলির বেশিরভাগ নামকরণ করেন XxxUtilবা Xxxhelperআপনি আপনার নকশাকে পুনর্বিবেচনা করতে চান।

Comments

খাঁটি পার্শ্ব প্রতিক্রিয়া বিনামূল্যে স্থিতিশীল পদ্ধতি পুরোপুরি সূক্ষ্ম IMO। তবে বিশ্বব্যাপী পরিবর্তনীয় রাষ্ট্র খুব কমই হয় এবং আমি ওপিটিকে গ্লোবাল স্টেট সম্পর্কে কথা বলে ব্যাখ্যা করি।

— কোডসইনচায়োস 11:58 এ 11:56

@ কোডইনচাউস সম্পূর্ণ একমত আমি দেখতে পেয়েছি যে স্থির পদ্ধতি এবং ভারগুলির মধ্যে পার্থক্য সম্পর্কে ওপি সম্পূর্ণরূপে পরিষ্কার নয়।

— এম প্ল্যাটভয়েট

Answer 12

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

স্কেলিং: জেভিএম প্রতি আমাদের স্ট্যাটিক ভেরিয়েবলের হুবহু এক উদাহরণ রয়েছে। মনে করুন আমরা একটি লাইব্রেরি ম্যানেজমেন্ট সিস্টেম বিকাশ করছি এবং আমরা প্রতি বইটিতে কেবল একটি হিসাবে বইয়ের নাম একটি স্ট্যাটিক ভেরিয়েবল রাখার সিদ্ধান্ত নিয়েছি। তবে যদি সিস্টেমটি বৃদ্ধি পায় এবং আমরা একাধিক জেভিএম ব্যবহার করি তবে আমরা কোন বইটি নিয়ে কাজ করছি তা বের করার কোনও উপায় নেই?

থ্রেড-সুরক্ষা: মাল্টি থ্রেড এনভায়রনমেন্টে ব্যবহৃত হলে ভেরিয়েবল এবং স্ট্যাটিক ভ্যারিয়েবল উভয়ই নিয়ন্ত্রণ করতে হবে। তবে উদাহরণের পরিবর্তনশীলের ক্ষেত্রে এটির সুরক্ষার প্রয়োজন হয় না যদি না এটি সুস্পষ্টভাবে থ্রেডগুলির মধ্যে ভাগ করা হয় তবে স্থির পরিবর্তনশীলের ক্ষেত্রে এটি সর্বদা প্রক্রিয়াটির সমস্ত থ্রেড দ্বারা ভাগ করা হয়।

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

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

সিরিয়ালাইজেশন: সিরিয়ালাইজেশনও তাদের সাথে ভাল কাজ করে না।

সৃষ্টি ও ধ্বংস: স্থির ভেরিয়েবলের সৃষ্টি এবং ধ্বংস নিয়ন্ত্রণ করা যায় না। সাধারণত এগুলি প্রোগ্রাম লোডিং এবং আনলোড করার সময়ে তৈরি এবং ধ্বংস হয়। এর অর্থ তারা মেমরি পরিচালনার জন্য খারাপ এবং শুরুতে আরম্ভের সময়টি যোগ করে।

তবে আমাদের যদি সত্যিই তাদের প্রয়োজন হয়?

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

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

Answer 13

আমার কাছে মনে হচ্ছে আপনি স্ট্যাটিক ভেরিয়েবল সম্পর্কে জিজ্ঞাসা করছেন তবে আপনি আপনার উদাহরণগুলিতে স্থির পদ্ধতিগুলিও নির্দেশ করেছেন।

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

স্থিতিশীল পদ্ধতি ওরফে ইউটিলিটি পদ্ধতি। এগুলি ব্যবহার করা সাধারণত কোনও খারাপ অভ্যাস নয় তবে প্রধান উদ্বেগ হ'ল তারা পরীক্ষায় বাধা সৃষ্টি করতে পারে ।

দুর্দান্ত জাভা প্রকল্পের উদাহরণ হিসাবে যা প্রচুর স্ট্যাটিক্স ব্যবহার করে এবং এটি সঠিক উপায়ে করেন দয়া করে প্লেটি দেখুন ! ফ্রেমওয়ার্ক । এসওতে এটি নিয়েও আলোচনা রয়েছে ।

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

সুতরাং স্ট্যাটিক ভেরিয়েবল (এবং পদ্ধতিগুলি) ভাল তবে সেগুলি বুদ্ধিমানের সাথে ব্যবহার করুন!

Answer 14

স্ট্যাটিক ভেরিয়েবলগুলি গুরুত্বপূর্ণভাবে ডেটা সুরক্ষার সাথে সমস্যা তৈরি করে (যে কোনও সময় পরিবর্তিত হয়, যে কেউ পরিবর্তন করতে পারে, অবজেক্ট ছাড়াই সরাসরি অ্যাক্সেস ইত্যাদি) with

আরও তথ্যের জন্য এই ধন্যবাদ পড়ুন।

Answer 15

এটি প্রস্তাবিত হতে পারে যে বেশিরভাগ ক্ষেত্রে যেখানে আপনি একটি স্ট্যাটিক ভেরিয়েবল ব্যবহার করেন, আপনি সত্যই সিঙ্গলটন প্যাটার্নটি ব্যবহার করতে চান ।

বৈশ্বিক রাজ্যগুলির সমস্যাটি হ'ল কখনও কখনও যা সাধারণ প্রসঙ্গে বৈশ্বিক হিসাবে বোধ করে, ব্যবহারিক প্রসঙ্গে কিছুটা নমনীয় হওয়া দরকার এবং এটিই সিঙ্গলটন প্যাটার্নটি কার্যকর হয়ে ওঠে।

Answer 16

তবুও আরেকটি কারণ: ভঙ্গুরতা।

আপনার যদি কোনও ক্লাস থাকে তবে বেশিরভাগ লোকেরা এটি তৈরি করতে এবং ইচ্ছামত এটি ব্যবহার করতে সক্ষম হতে পারে বলে আশা করে।

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

আপনি যদি স্ট্যাটিক ভেরিয়েবল ব্যবহার করছেন তবে তা ভেঙে যাবে। বাগগুলি ব্যয়বহুল।

সম্ভাব্য ক্লুলেস বিকাশকারীদের দ্বারা পরিবর্তনের জন্য .0001% পারফরম্যান্সের উন্নতি এবং দৃust়তার মধ্যে, অনেক ক্ষেত্রে দৃust়তা হ'ল পছন্দ।

Answer 17

আমি স্থিতিশীল ভেরিয়েবলগুলি আরও সুবিধাজনক বলে মনে করি। এবং আমি অনুমান করি যে তারাও দক্ষ এর পরিবর্তে ক্লাসের 10,000 টি উদাহরণ দিয়ে স্মৃতি গোলমাল করার পরিবর্তে?

আপনি যা মনে করেন তা আমি দেখতে পাচ্ছি, তবে একটি সাধারণ একক প্যাটার্ন 10 000 অবজেক্ট ইনস্ট্যান্ট না করেই এটি করবে।

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

উদা:

public class WaterContainer {
    private int size;
    private int brand;
    ...etc

    public static int convertToGallon(int liters)...

    public static int convertToLiters(int gallon)...

}

Comments

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

— কোডসইনচাউস

নিশ্চিত না আমি আপনার মন্তব্য বুঝতে পেরেছি! আমি 10 000 অবজেক্ট ইনস্ট্যান্স করার বিষয়ে ইটালিকে কী বলেছিলাম সে সম্পর্কে আমি ওপিকে সাড়া দিচ্ছিলাম। আমি বুঝতে পারছি না আপনি কেন একটি সিঙ্গলটন এবং একটি স্ট্যাটিক ভেরিয়েবলের তুলনা করছেন? আপনি যা লিখেছেন তা থেকে আমি যা বুঝতে পারি তা হ'ল সিঙ্গলটন খারাপ নকশা ...! আমার ধারণা, আমি আপনাকে ভুল বুঝেছি, যেহেতু স্প্রিং ফ্রেমওয়ার্ক ডিফল্টভাবে সমস্ত মটরশুটি সিঙ্গলটন করে ;-)

— Cygnusx1

একটি ক্লাসিক সিঙ্গলটন (এতে রয়েছে Class.Instance) যা পরিবর্তনীয় স্থিতি বহন করে তা হ'ল খারাপ নকশা আইএমও। সেক্ষেত্রে আমি দৃ a়ভাবে এমন একটি নকশাকে পছন্দ করি যেখানে আমি যে সিঙ্গেলনগুলি পাই সেগুলি ক্লাসে প্যারামিটার হিসাবে পাস করা উচিত যা তাদের ব্যবহার করে (সাধারণত ডিআই এর সাহায্যে)। লজিক্যালি অপরিবর্তনীয় ক্লাসিক সিলেটলেটগুলি আইএমও ভাল।

— কোডসইনচাউস

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

— এডউইন বাক

Answer 18

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

আমি স্থিতিশীল ভেরিয়েবলগুলি আরও সুবিধাজনক বলে মনে করি। এবং আমি অনুমান করি যে তারাও দক্ষ

পরিসংখ্যানগুলি ভেরিয়েবল / ক্লাসগুলির জন্য আদর্শ এবং দক্ষ পছন্দ যা কখনও পরিবর্তন হয় না ।

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

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

Comments

"সময় বিশ্বব্যাপী" - কম্পিউটারে সিস্টেমের সময়কে মডেল করার অন্যান্য উপায় রয়েছে যা কিছু নিজস্ব, বৈশ্বিক জিনিস যা নিজে থেকে পরিবর্তিত হয়। cf. এই সমীক্ষা: "কম্পিউটিংয়ে মডেলিংয়ের সময়: একটি ট্যাক্সোনমি এবং একটি তুলনামূলক সমীক্ষা" @ @ xxiv.org

— জারেড আপডেটে

Answer 19

আমার 0 .02 হ'ল এর মধ্যে বেশ কয়েকটি উত্তর "স্ট্যাটিকস খারাপ" বলার পরিবর্তে বিষয়টি বিভ্রান্ত করছে, আমি স্কোপিং এবং উদাহরণগুলি সম্পর্কে কথা বলা ভাল বলে মনে করি।

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

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

আমি অন্যান্য উত্তরের কিছু দিক কেন মনে করি সে সম্পর্কে কিছু চিন্তাভাবনা প্রশ্নটির মূল নয় ...

পরিসংখ্যান "গ্লোবাল" নয়। জাভাতে স্কোপিং স্থির / উদাহরণ থেকে আলাদাভাবে নিয়ন্ত্রিত হয়।

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

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

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

Answer 20

আপনার পোস্টে দুটি প্রধান প্রশ্ন আছে।

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

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

উপসংহারে: স্ট্যাটিক ভেরিয়েবলের ব্যবহার এড়িয়ে চলুন এবং স্ট্যাটিক বা অ স্থির পদ্ধতিগুলির সাথে ডিল করার সময় সঠিক পারফরম্যান্স ভারসাম্য সন্ধান করুন।

পিএস: আমার ইংলিশের জন্য দুঃখিত।

Answer 21

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

Answer 22

ক) প্রোগ্রাম সম্পর্কে কারণ।

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

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

খ) আপনার কি সত্যই দরকার?

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

কেবলমাত্র কম বা অল্প ব্যবহারযোগ্য কোড যা দীর্ঘসময় ধরে নিবিড় উপায়ে অনেক লোক ব্যবহার করবে না স্থির ভেরিয়েবলগুলির সাথে ভাল যেতে পারে।

Answer 23

সমস্ত কিছু (তার :) এর উদ্দেশ্য থাকতে পারে, যদি আপনার কাছে থ্রেডের গুচ্ছ থাকে যা ডেটা ভাগ করতে / ক্যাশে করতে এবং সমস্ত অ্যাক্সেসযোগ্য মেমরির প্রয়োজন হয় (যাতে আপনি একটি জেভিএমের মধ্যে প্রসঙ্গে বিভক্ত হন না) স্থির পক্ষে সেরা পছন্দ

-> অবশ্যই আপনি বাধ্য করতে পারেন শুধু একটি উদাহরণ, কিন্তু কেন?
আমি এই থ্রেডের কিছু মন্তব্য খারাপ দেখতে পাই, স্ট্যাটিক্সকে নয়;)

Answer 24

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

উদাহরণস্বরূপ সম্পর্কিত মানগুলি ধরে রাখার জন্য স্থিতিশীল ভেরিয়েবলগুলি ব্যবহার করার চেষ্টা করার সময় সমস্যাগুলি উপস্থিত হয়।

Answer 25

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

Comments

তবে কিছু সংঘাতের মানক দৃষ্টান্ত অনুসরণ করার জন্য আপনার কোডটিকে কঠোরভাবে বিবেচনা করা আসলে কোডটি আরও ভাল করে তোলে, বা আমরা কেবল কোডটি লেখার জন্য কাজ করে যা অভিযোগ করে?

— জোয়

হ্যাঁ এটি এটিকে আরও ভাল করে তোলে, কারণ এটি ভবিষ্যতে এটি আরও পরিচালিত করে তোলে, বোঝা আরও সহজ এবং আরও স্পষ্ট।

— ব্লকহেড

ওও কোড না লেখাই কেন খারাপ? এবং কেন বাজার্ন স্ট্রস্ট্রপ আপনার সাথে একমত নয়? একটি মাত্র নাম রাখুন ...

— মার্কিনিস লর্ন

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

— ব্লকহেড

Answer 26

এখানে প্রচুর ভাল উত্তর রয়েছে, এটি যুক্ত করে,

মেমোরি: স্ট্যাটিক ভেরিয়েবলগুলি যতক্ষণ শ্রেণি লোডার বেঁচে থাকে ততক্ষণ বেঁচে থাকে [সাধারণভাবে ভিএম মারা যায়] তবে এটি কেবল স্থির হিসাবে সঞ্চিত বাল্ক অবজেক্ট / রেফারেন্সের ক্ষেত্রে।

মডুলারাইজেশন: আইওসি, নির্ভরতা-প্রকৃতি, প্রক্সি ইত্যাদি মত ধারণাগুলি বিবেচনা করুন All সবই দৃ completely়ভাবে সংযুক্তকরণ / স্থির বাস্তবায়নের বিরুদ্ধে against

অন্যান্য কনস: থ্রেড সুরক্ষা, পরীক্ষাযোগ্যতা

Answer 27

ভাবুন যে আপনার যদি অনেক ব্যবহারকারীর সাথে একটি অ্যাপ্লিকেশন থাকে এবং আপনি একটি স্থিতিশীল ফর্মটি সংজ্ঞায়িত করেন তবে প্রতিটি ব্যবহারকারী অন্যান্য ব্যবহারকারীর অন্যান্য সমস্ত ফর্মও সংশোধন করবে।

Answer 28

আমি মনে করি স্ট্যাটিক কীওয়ার্ড সহ গ্লোবাল ভেরিয়েবলের অত্যধিক ব্যবহারগুলি অ্যাপ্লায়ার ক্ষেত্রে উদাহরণস্বরূপ মেমরির ফুটো হতে পারে

Answer 29

আমার দৃষ্টিকোণ থেকে staticভেরিয়েবলটি কেবলমাত্র ডেটা বা কনভেনশন দ্বারা নির্মিত ভেরিয়েবলগুলি পড়তে হবে ।

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

Answer 30

আমি স্ট্যাটিক্সের সাথে অনেক খেলেছি এবং আমি আপনাকে কিছুটা আলাদা উত্তর দিতে পারি - অথবা এটি দেখার জন্য কিছুটা আলাদা উপায় হতে পারে?

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

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

এখন, সমস্যাটিকে কিছুটা সংশোধন করুন: আপনি যদি নিজের শ্রেণিকে এমন এক শ্রেণিতে বিভক্ত করেন যেখানে সবকিছু স্থির থাকে এবং অন্যটি যা কেবল একটি "সাধারণ শ্রেণি" এবং "সাধারণ শ্রেণি" সম্পর্কে ভুলে যায় তবে আপনার প্রশ্নটি বিশুদ্ধ স্ট্যাটিক ক্লাস বনাম সিঙ্গলটন হয়ে যায় যা এখানে দৈর্ঘ্যে সম্বোধন করা হয় (এবং সম্ভবত আরও কয়েক ডজন প্রশ্ন)।