আমাদের ব্যক্তিগত ভেরিয়েবলগুলি কেন দরকার?

Question

আমাদের ক্লাসে প্রাইভেট ভেরিয়েবলের দরকার কী?

আমি পড়েছি প্রোগ্রামিংয়ের প্রতিটি বই বলে যে এটি একটি প্রাইভেট ভেরিয়েবল, আপনি এটি সংজ্ঞায়িত করে তবে সেখানে থামেন s

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

1. ব্যক্তিগত ভেরিয়েবলগুলি প্রতিরোধে কী সহায়তা করে?

2. কোনও নির্দিষ্ট সম্পত্তি ব্যক্তিগত হওয়া উচিত কিনা আপনি কীভাবে সিদ্ধান্ত নেবেন? যদি ডিফল্টরূপে প্রতিটি ক্ষেত্র ব্যক্তিগত হয় তবে কোনও শ্রেণিতে কেন পাবলিক ডেটা সদস্য রয়েছে?

3. কোন পরিস্থিতিতে একটি পরিবর্তনশীল প্রকাশ করা উচিত?

Comments

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

— জেমস

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

— কেবিএ

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

— নজর মেরজা

গেটস অ্যান্ড

— সিটারস

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

— gnasher729

Answer 1

এটি এতটা আস্থার বিষয় নয়, বরং জটিলতা পরিচালনার অন্যতম।

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

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

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

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

সুতরাং, কখন আপনার জিনিসগুলি ব্যক্তিগত করা উচিত: আমি বলব ডিফল্টরূপে সমস্ত কিছু ব্যক্তিগত করা, এবং তারপরে কেবলমাত্র সেই অংশগুলি প্রকাশ করা হবে যা একেবারে সর্বজনীন হতে হবে। আপনি যত বেশি বেসরকারী করতে পারবেন তত ভাল।

Comments

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

— জেফ্রি সুইভিনি

আধুনিক কম্পিউটিংয়ের পবিত্র গ্রিল জটিলতা কমিয়ে দিচ্ছে।

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

— আম্মোন

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

— ওয়েন ওয়ার্নার

@ অ্যাডামজার্নার প্রথম স্থানে গেটার / সেটার রাখার বিষয়ে "বলুন, জিজ্ঞাসা করবেন না" ( মার্টিনফোওয়ালার / বিলিকি / টেলডন্ট এএসকিচটিএমএল ) দেখুন - তবে অন্যথায় হ্যাঁ, কারণ আপনাকে যে কোনও সময় মানের অভ্যন্তরীণ প্রতিনিধিত্ব পরিবর্তন করতে মুক্ত থাকতে হবে? আপনি চান. সর্বদা হিসাবে, ব্যতিক্রম আছে ... (যেমন ডিটিও)

— ডাবল ইউ

Answer 2

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

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

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

Comments

আইএমও এটি লিব লেখক এবং লিব গ্রাহকের মধ্যে যোগাযোগ সম্পর্কে। জন ইন্টারফেস "এই ব্যবহার করুন" মত হল এবং আপনাকে আঘাত মত "ব্যবহার করবেন না যে," যে ব্যতীত জাভা, আপনি সত্যিই এটা দুর্ঘটনা দ্বারা ব্যবহার করতে পারবেন না এটি ব্যক্তিগত তাই এটা নিরাপদ এবং পরিষ্কার যে ভাবে কি না পারেন।

— চকৃত

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

@ ডেলান এই শব্দটিকে "দুর্ঘটনাক্রমে" নোট করুন হ্যাঁ আমার সম্ভবত এটি আরও পরিষ্কার হওয়া উচিত।

— চকৃত

@ চাচারিত হ্যাঁ, আমি বোঝাতে চাইনি যে আপনি ভুল ছিলেন। আমি শুধু এই পয়েন্ট প্রচার করতে চেয়েছিলেন।

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

— ব্রায়ান

Answer 3

এখানে কীওয়ার্ডটি এনক্যাপসুলেশন । OOP- এ আপনি আপনার অবজেক্ট / ক্লাসের যথাযথ এনক্যাপসুলেশন প্রয়োগ করতে প্রাইভেট ভেরিয়েবল ব্যবহার করতে চান।

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

1. সুতরাং, ব্যক্তিগত ভেরিয়েবলগুলি নিশ্চিত করে যে সংশ্লিষ্ট পরিবর্তনশীল কেবলমাত্র সংজ্ঞায়িত শ্রেণিতেই থাকবে। আপনার যদি এটি পরিবর্তন করতে হয় তবে পরিবর্তনটি স্থানীয়ভাবে স্থানীয়।

2. সি ++ বা জাভা এর মতো traditionalতিহ্যবাহী ল্যাঙ্গুজেজে আপনি সাধারণত সমস্ত কিছু ব্যক্তিগত এবং কেবল প্রাসঙ্গিক এবং সেটটারদের দ্বারা অ্যাক্সেসযোগ্য করে তোলেন। সত্যিই খুব বেশি সিদ্ধান্ত নেওয়ার দরকার নেই।

3. কখনও কখনও, f.ex. একটি সি ++ স্ট্রাক্টে, আপনাকে বেশ কয়েকটি জিনিস একসাথে গ্রুপ করার উপায় হিসাবে আপনার ক্লাস প্রয়োজন। উদাহরণস্বরূপ, একটি ভেক্টর শ্রেণি বিবেচনা করুন যার কেবল একটি xএবং একটি yবৈশিষ্ট্য রয়েছে। এই ক্ষেত্রে, আপনি এই বৈশিষ্ট্যগুলিকে সর্বজনীন ঘোষণা করে সরাসরি অ্যাক্সেসের অনুমতি দিতে পারেন। বিশেষত, বাইরের কিছু কোড আপনার শ্রেণীর কোনও অবজেক্টকে সরাসরি নতুন মানগুলিতে লিখে xবা পরিবর্তিত করে সেদিকে আপনার নজর দেওয়া উচিত নয় y।

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

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

এটি অন্যান্য ক্ষেত্রগুলিকে অন্তর্ভুক্ত করার জন্য আপনার জ্ঞানকে কীভাবে প্রসারিত করে তা আপনাকে বিদ্যমান ধারণাগুলি সম্পূর্ণ নতুন উপায়ে দেখায়।

Comments

+1 "অন্য প্রোগ্রামাররা আপনাকে পাওয়ার জন্য বাইরে না থাকলেও তারা আপনার কোডের সাথে ইন্টারঅ্যাক্ট করে।" আপনার কোড ব্যবহার করে প্রোগ্রামাররা অন্তর্নিহিত খারাপ নয়। ব্যক্তিগত ভেরিয়েবলগুলি ব্যবহার করে আপনি নিশ্চিত হন যে কোডটি ব্যবহার করে তারা (এবং আপনি ভবিষ্যতে) ক্ষতিগ্রস্থ না হন। এটি আপনাকে আরও ভাল এপিআই ডিজাইন করতে এবং এটি ডকুমেন্ট করতে সহায়তা করে।

— szalski

Answer 4

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

উদাহরণস্বরূপ, জাভাস্ক্রিপ্টের মতো প্রোটোটাইপিক ভাষাগুলি ব্যবহারকারীদের যথাযথ দেখতে ভেরিয়েবলগুলিতে প্লাস্টার করার অনুমতি দিতে পারে:

function SomeObject() {
    this.a = 2; //Public (well, actually protected) variable

    this.showA = function() {
        alert(this.a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 3. Uh oh!

যদি সেই পরিবর্তনশীলটি ব্যক্তিগত হয় তবে এটি বাইরে থেকে পরিবর্তন করা সম্ভব হবে না:

function SomeObject() {
    var a = 2; //Private variable

    this.showA = function() {
        alert(a);
    }
}

//Some lines down...

var obj = new SomeObject();
obj.a = 3;
obj.showA(); //Will alert 2

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

বেসরকারী ভেরিয়েবলগুলি বহু পাবলিক ভেরিয়েবলগুলি কী করে ভারী ডকুমেন্টেশনের উপর নির্ভর না করে ভবিষ্যতে কোড প্রসারিত করা সহজ করে তোলে। যদি কম ভেরিয়েবলগুলি ওভাররাইট করা যায় তবে দুর্ঘটনাক্রমে কার্যকারিতা ভঙ্গ করার হুমকি কম রয়েছে।

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

Comments

3 জনকে সতর্ক করা কেন "আহা!" এক্ষেত্রে. প্রোগ্রামারটি সম্ভবত এটি ঘটতে চেয়েছিল।

— ইমিবিস

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

— জেফরি সুইনি

Answer 5

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

এটি এমন নয় যে গোপনীয়তা ব্যতীত ভাষাগুলি এ জাতীয় নকশাকে অসম্ভব করে তোলে, সম্ভবত কমই। এর মতো কিছু লেখার জন্য উত্সাহিত করার পরিবর্তে foo.getBar(), লোকেরা ভাবেন যে একজন প্রযোজক প্রয়োজনীয় নয়, কারণ এটি লেখার পক্ষে সহজ foo.bar, তবে আপনি যখন পরবর্তীকালের মতো নৈশবৈদ্যতা সহ শেষ করেন তখন সেই সিদ্ধান্তটির পুনর্বিবেচনা হয় না obj.container[baz].foo.bar। এমন প্রোগ্রামাররা যারা কখনও কঠোর ভাষায় কাজ করেনি তারা এটিকে কী দেখতে পারে তাও দেখতে পাবে না।

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

Answer 6

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

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

Comments

বিষয়টি বিষয় সম্পর্কে খুব সংকীর্ণ দৃষ্টিভঙ্গি। এমন কিছু ক্ষেত্রে রয়েছে যেখানে সর্বজনীন ক্ষেত্রের অ্যাক্সেসের ব্যবস্থা করা হয়, এমনকি পছন্দসই

— রোল্যান্ড টেপ

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

— ডেভিড কে

@ ডেভিডকে সম্ভবত বিবিবি বলতে যা বোঝায় তার অর্থ হ'ল "ব্যক্তিগত ভেরিয়েবলগুলি অন্যকে inুকে পড়ে এবং নির্বিচারে অবজেক্টের অবস্থা পরিবর্তন করতে বাধা দেয় ।" পাবলিক পদ্ধতিগুলি অবজেক্টের ব্যক্তিগত অবস্থা পরিবর্তন করতে পারে তবে কেবলমাত্র সেই উপায়ে যা প্রয়োজন এবং কার্যকারিতার জন্য সামঞ্জস্যপূর্ণ।

— সর্বোচ্চ ন্যানসি

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

— ডেভিড কে

Answer 7

• ব্যক্তিগত ভেরিয়েবলগুলি প্রতিরোধে কী সহায়তা করে?

কোন বৈশিষ্ট্য এবং পদ্ধতিগুলি ইন্টারফেস এবং কোনটি প্রকৃত মূল কার্যকারিতা তা পরিষ্কার করে দেয়। পাবলিক পদ্ধতি / বৈশিষ্ট্যগুলি অন্যান্য কোডগুলি প্রায়শই অন্যান্য বিকাশকারীর কোডগুলি আপনার অবজেক্ট ব্যবহার করে। আমি একই প্রকল্পে 100+ এর দলগুলিতে কখনও কাজ করি নি, তবে আমার লিখিত জিনিসগুলি ব্যবহার করে 20 টি পর্যন্ত আরও বিকাশকারী 3-5-এর টিমের আমার অভিজ্ঞতায় অন্যান্য উদ্বেগগুলি নির্বোধ বলে মনে হচ্ছে।

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

• কোনও নির্দিষ্ট সংস্থার ব্যক্তিগত হওয়া উচিত কিনা তা আপনি কীভাবে সিদ্ধান্ত নেবেন? যদি ডিফল্টরূপে প্রতিটি ক্ষেত্র ব্যক্তিগত হয় তবে কোনও শ্রেণিতে কেন পাবলিক ডেটা সদস্য রয়েছে?

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

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

• কোন পরিস্থিতিতে একটি পরিবর্তনশীল প্রকাশ করা উচিত?

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

Comments

আইএমএইচও, কোনও সার্বজনীন শ্রেণীর সাথে বিশেষত কোনও ভুল নেই যার একমাত্র উদ্দেশ্য পাবলিক ভেরিয়েবলগুলি প্রকাশ করা। বস্তুত, জেভিএম যে উদ্দেশ্যে বিল্ট-ইন ক্লাস একটি সংখ্যা আছে: int[], double[], Object[], ইত্যাদি একটি উচিত, কিন্তু, কিভাবে এক অনাবৃত যেমন একটি বর্গ দৃষ্টান্ত সম্পর্কে খুব সতর্কতা অবলম্বন করা আবশ্যক। void CopyLocationTo(Point p);[ Pointকলারের কাছ থেকে একজনকে গ্রহণ করার ] অর্থ এর থেকে পরিষ্কার Point location(), যেহেতু এটির অবস্থানের Point pt = foo.location(); pt.x ++;উপর কী প্রভাব ফেলবে তা পরিষ্কার নয় foo।

— 23:39

Answer 8

দেখুন ইত্যাদি একটি সম্পর্কিত প্রশ্নের খনি পোস্টটি ।

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

যথাযথ সদস্য স্কোপিং স্ব-ডকুমেন্টিং কোডে এইভাবে কী।

Answer 9

আমি একটি বাস্তব উদাহরণ ব্যবহার করে ভিন্ন দৃষ্টিকোণ থেকে এনক্যাপসুলেশনের মান সম্পর্কে কথা বলতে যাচ্ছি। বেশ কিছুদিন আগে (৮০ এর দশকের গোড়ার দিকে) রেডিও শ্যাক কালার কম্পিউটারের জন্য একটি খেলা রচনা করা হয়েছিল ড্যাগোরাথের ডানজনস নামে পরিচিত। কিছু বছর আগে, রিচার্ড হুনারল্যাচ একটি কাগজ এসেম্বলারের তালিকা থেকে সি / সি ++ ( http://mspencer.net/daggorath/dodpcp.html ) এ পোর্ট করেছিলেন । কিছু সময় পরে, আমি কোডটি পেয়েছি এবং আরও ভাল এনক্যাপসুলেশন দেওয়ার জন্য এটি পুনরায় ফ্যাক্টর করতে শুরু করেছি, ( http://dbp-consulting.com/stuff/ )।

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

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

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

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

Comments

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

— কুম্ভ শক্তি

খুব খারাপ রিফ্যাক্টর সংস্করণটি

— গিথুব এ নেই

Answer 10

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

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

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

Answer 11

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

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

যেমনটি আমরা জানি, সুরক্ষিত মানে এটি উত্তরাধিকারসূত্রে চলে যাওয়া শ্রেণীর দ্বারা অ্যাক্সেস করা যায়।

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

Answer 12

অন্যদের হিসাবে যেমন বলা হয়েছে, বেসরকারী ভেরিয়েবলগুলি মিস-ইউজগুলি এড়াতে ভাল যা অবজেক্টটিকে একটি বেমানান স্থিতিতে নিয়ে যায় এবং বাগগুলি এবং অপ্রত্যাশিত ব্যতিক্রমগুলি ট্র্যাক করা শক্ত।

তবে অন্যদিকে, অন্যদের দ্বারা যা বেশিরভাগ উপেক্ষা করা হয়েছে তা হ'ল সুরক্ষিত ক্ষেত্র।

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

সুতরাং, সর্বজনীন ক্ষেত্রগুলিকে ভাল হিসাবে বিবেচনা করা শক্ত, এবং তারিখের জন্য এগুলি ব্যবহার করার একমাত্র কারণ হ'ল কনফিগারেশন প্যারামিটার হিসাবে ব্যবহৃত ক্লাসগুলির জন্য (অনেকগুলি ক্ষেত্র এবং একটি যুক্তিযুক্ত একটি খুব সাধারণ শ্রেণি, যাতে ক্লাসটি একাকী প্যারামিটার হিসাবে পাস করা হয় কিছু পদ্ধতি)।

তবে অন্যদিকে, ব্যক্তিগত ক্ষেত্রগুলি অন্য কোডের কাছে আপনার কোডের নমনীয়তা হ্রাস করে।

নমনীয়তা বনাম ঝামেলা, উপকারিতা এবং কনস:

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

অন্যদিকে, আপনার কোড ব্যবহারকারীদের দ্বারা তাত্ক্ষণিকভাবে সুরক্ষিত ক্ষেত্রগুলি সহ আপনার শ্রেণীর প্রসারিত অবজেক্টগুলি তাদের দায়িত্ব, আপনার নয়।

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

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

সুতরাং, ব্যক্তিগত, সুরক্ষিত এবং পাবলিকের মধ্যে একটি ভাল ভারসাম্য হ'ল সত্যই গুরুত্বপূর্ণ।

এখন, ব্যক্তিগত এবং সুরক্ষিতের মধ্যে সিদ্ধান্ত নেওয়াটাই আসল সমস্যা।

সুরক্ষিত কখন ব্যবহার করবেন?

আপনি যখনই কোনও ক্ষেত্রটি বুঝতে পারবেন তবে এটি নমনীয় হতে পারে, তবে এটি সুরক্ষিত হিসাবে কোড করা উচিত। এই নমনীয়তাটি হ'ল: নাল হয়ে যাওয়া থেকে (যেখানে নাল সর্বদা যাচাই করা হয় এবং ব্যতিক্রমগুলি ছুঁড়ে না দিয়ে বৈধ রাষ্ট্র হিসাবে স্বীকৃত হয়), আপনার ক্লাসের প্রাক্তন দ্বারা ব্যবহারের আগে বাধা থাকা পর্যন্ত। > = 0, <100 ইত্যাদি, এবং সর্বাধিক সতর্কতা বার্তা নিক্ষেপ করে ওভার / আন্ডারফ্লোড মানগুলির জন্য স্বয়ংক্রিয়ভাবে স্থির।

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

Answer 13

imo @tdammers সঠিক নয় এবং আসলে বিভ্রান্তিকর।

প্রয়োগের বিশদটি গোপন করার জন্য ব্যক্তিগত ভেরিয়েবল বিদ্যমান। আপনার ক্লাসটি স্কোর সঞ্চয় Aকরতে ব্যবহার করতে পারে array। কাল আপনি একটি treeবা priority queueতার পরিবর্তে ব্যবহার করতে চাইতে পারেন । আপনার শ্রেণীর সমস্ত ব্যবহারকারীর প্রয়োজন স্কোর এবং নামগুলি ইনপুট করার addScore()একটি উপায় এবং শীর্ষস্থানীয় 10 কে তা খুঁজে বের করার উপায় getTop(n)।

তাদের অন্তর্নিহিত ডেটা কাঠামো অ্যাক্সেস করার দরকার নেই। শুনে ভালো লাগছে? ঠিক আছে, কিছু সাবধানবাণী আছে।

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

আপনি করতে পারেন সেরা কাজটি হ'ল আপনার প্রোগ্রামের পরিমাণের পরিমাণ সীমাবদ্ধ করা এবং সম্ভব হলে বিশুদ্ধ ফাংশনগুলি ব্যবহার করা।

Answer 14

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

Comments

এই কিছু সারগর্ভ প্রস্তাব উপর পয়েন্ট হয়েছে এবং পূর্বে 17 উত্তর ব্যাখ্যা বলে মনে হচ্ছে না

— মশা

Answer 15

আপনার প্রথমে অবজেক্ট ওরিয়েন্টেড প্রোগ্রামিংয়ের ধারণাটি বোঝা উচিত। এটি বিমূর্ততা, encapsulation ইত্যাদি আছে।

বিমূর্ততা - আপনি বাস্তবায়নের আন্ডারলাইন বিশদ জানতে প্রয়োজন ছাড়াই যুক্তি ধারণাটি পেতে পারেন।

এনক্যাপসুলেশন - আপনি অবজেক্টের আন্ডারলাইন বাস্তবায়ন দেখতে পাবেন না। কেবলমাত্র আপনি অবজেক্টের পাবলিক ইন্টারফেস দেখতে পারবেন।

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

ব্যক্তিগত - বাস্তবায়ন যা বাইরের বিশ্ব থেকে লুকানো উচিত। যাতে আপনি এটি পরিবর্তন করতে পারেন এবং আপনার শ্রেণীর ব্যবহারকারী প্রভাবিত হবে না।

সর্বজনীন - এটি এমন ইন্টারফেস যা দিয়ে কেউ আপনার অবজেক্ট ব্যবহার করতে পারে।

Comments

সুরক্ষিত - সাব-ক্লাস (এক্সটেন্ডার) (জাভা) দ্বারা সরাসরি অ্যাক্সেসযোগ্য।

— কুম্ভ শক্তি