ব্যক্তিগত ক্ষেত্রগুলি কেন পর্যাপ্ত সুরক্ষিত নয়?

Question

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

আমি যখন ক্লাসটি সাবক্লাস করি তখন প্রথম জিনিসগুলির মধ্যে একটি হ'ল privateপদ্ধতিতে একগুচ্ছ পরিবর্তন করা protected। তবে বাইরের পৃথিবী থেকে বিশদ গোপন করা গুরুত্বপূর্ণ – সুতরাং আমাদের প্রয়োজন protectedএবং কেবল নয় public।

আমার প্রশ্নটি: আপনি কি কোনও গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে জানেন যেখানে privateপরিবর্তে protectedভাল সরঞ্জাম, বা দুটি বিকল্প " protectedও public" ওওপি ভাষার জন্য যথেষ্ট হবে?

Comments

ক্লিন কোড সুরক্ষিত ভেরিয়েবলগুলি এড়িয়ে যাওয়ার পরামর্শ দিচ্ছে কেন এর

— gnat

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

— Ixrec

উত্পন্ন ক্লাসগুলি বাইরের বিশ্বের অংশ।

— কোডসইনচায়োস

ভুলে যাবেন না যে সুরক্ষিত হওয়ার অর্থ সর্বদা অ্যাসেসের উত্তরাধিকারের শ্রেণিবিন্যাসে লক থাকে। জাভাতে এটি প্যাকেজ স্তরের অ্যাক্সেসও দেয়।

— berry120

আমার অধ্যাপক বলতেন যে "এমন কিছু জিনিস আছে যা আমি আমার বাচ্চাদের বলি না Those আমি যারা আমার ব্যক্তিগত ক্ষেত্র" "

— SáT

Answer 1

কারণ যেমনটি আপনি বলেছেন, protectedতবুও আপনাকে "বাস্তবায়ন সম্পূর্ণরূপে সংশোধন করার" ক্ষমতা দিয়ে ফেলেছে। এটি ক্লাসের ভিতরে কোনও কিছুই সত্যই রক্ষা করে না।

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

অনুশীলনে, protectedসদস্যরা মূলত একটি শ্রেণীর '' সাবক্লাসের জন্য সর্বজনীন এপিআই '' এবং publicসদস্যদের মতোই স্থিতিশীল এবং পিছনের দিকে সামঞ্জস্যপূর্ণ হওয়া প্রয়োজন need যদি সত্যিকারের privateসদস্য তৈরি করার ক্ষমতা আমাদের না থাকে , তবে বাস্তবায়নের কোনও কিছুই পরিবর্তন করা কখনই নিরাপদ হবে না, কারণ আপনি (দূষিত) ক্লায়েন্ট কোডটি কোনওভাবে নির্ভর করতে পেরেছেন এমন সম্ভাবনাটি অস্বীকার করতে সক্ষম হবেন না এটা।

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

Comments

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

— abluejelly

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

— অ্যাডাম লিবুয়া

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

— Ixrec

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

— জয়

আমি আপনাকে +1 এর চেয়ে বেশি টস করতে পারি যদি আমি => পারতাম তবে এটিই আমরা অনুগ্রহ করে @ ব্লুজেলি

— টমাস আইয়ুব

Answer 2

ওওপি-তে, শীঘ্রই বা পরে, আপনি একটি শ্রেণির একটি সাবক্লাস তৈরি করতে যাচ্ছেন

এটা ভুল. প্রতিটি শ্রেণীর উপ-শ্রেণীবদ্ধ করে বোঝানো হয় না এবং কিছু স্ট্যাটিকালি টাইপ করা ওওপি ভাষাগুলির এমনকি এটি প্রতিরোধের বৈশিষ্ট্যও রয়েছে যেমন, final(জাভা এবং সি ++) বা sealed(সি #)।

এটি বোঝা ভাল এবং বাস্তবায়নটি সম্পূর্ণরূপে সংশোধন করতে সক্ষম হওয়ায়।

না এইটা না. কোনও শ্রেণীর পক্ষে তার সার্বজনীন ইন্টারফেসটি স্পষ্টভাবে সংজ্ঞায়িত করতে এবং তার আগ্রাসনকারীদের উত্তরাধিকার সূত্রে প্রাপ্ত হলেও সংরক্ষণ করতে সক্ষম হওয়া ভাল।

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

বা স্কট মেয়ার্সের শর্তে এটি রাখতে: একটি শ্রেণির ব্যক্তিগত অংশগুলি একটি সীমাবদ্ধ সংখ্যার কোড দ্বারা প্রভাবিত হয়: স্বয়ং ক্লাসের কোড।

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

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

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

Comments

"অসীম পরিমাণ কোড দ্বারা প্রভাবিত" এর তাত্ত্বিক দৃশ্যের জন্য +1

— ব্রোকেন_উইন্ডো

সম্ভবত এটি লক্ষণীয় যে সি # ডিজাইনাররা উত্তরাধিকারসূত্রে প্রাপ্ত পদ্ধতিটি যথাযথভাবে virtualএই উত্তরে বর্ণিত কারণগুলির জন্য চিহ্নিত না করা থাকলে তা নিষিদ্ধ করার সিদ্ধান্ত নিয়েছে ।

— উইসডেন

বা সহজভাবে বলতে গেলে: protectedপদ্ধতিগুলির জন্য, ডেটা সদস্যদের জন্য নয়।

— ম্যাথিউ এম।

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

— ড্যান নীলি

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

— সেবাস্তিয়ান রেডল

Answer 3

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

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

Comments

যে কোনও কিছুর জন্য "কোচ এবং ঘোড়া চালান" এর জন্য +1। এটি একটি দুর্দান্ত বাক্যাংশ যা আমি আশা করি আমি আরও শুনেছি।

— নিক হার্টলি

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

— অ্যাডাম লিবুয়া

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

— লুয়ান

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

— লুয়ান

অন্যের বেসরকারীদের স্পর্শ করা ঠিক আছে এর জন্য @ লুয়ান +1!

— নাইজেল টাচ

Answer 4

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

1. পদ্ধতিগুলি তাদের সাথে প্রাক এবং পোস্টের শর্তাদি (চুক্তি) যুক্ত করে।
2. বস্তুগুলি তাদের সাথে আক্রমণকারীদের যুক্ত হয়েছে।

কোনও অবজেক্ট সম্পর্কে মডিউলার যুক্তি নিম্নরূপে এগিয়ে চলেছে (প্রথমে কমপক্ষে একটি আনুমানিক)

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

কল্পনা করুন যে আমরা object Aউপরের পদ্ধতির ব্যবহার করে যাচাই করেছি । আর এখন যাচাই করতে ইচ্ছুক method gএর object Bযা কল method fএর object A। মডুলার যুক্তি method gবাস্তবায়নের বিষয়ে পুনর্বিবেচনা না করেই আমাদের যুক্তি জানাতে দেয় method f। প্রদত্ত যদি আমরা কল সাইটটিতে object Aআক্রমণকারী এবং পূর্বশর্ত প্রতিষ্ঠা করতে পারি তবে আমরা পদ্ধতি কলের আচরণের সারাংশ হিসাবে পোস্টের শর্তটি গ্রহণ করতে পারি । তদুপরি আমরা আরও জানব যে কলটি ফিরে আসার পরেও তার অদম্য।method fmethod g,method fA

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

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

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

সুরক্ষিত ক্ষেত্র

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

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

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

Answer 5

privateএকটি শ্রেণীর মধ্যে ভেরিয়েবলগুলি protectedএকই কারণে যে breakকোনও switchব্লকের ভিতরে একটি goto labelবিবৃতি একটি স্টেটমেন্টের চেয়ে ভাল than যা হ'ল মানব প্রোগ্রামাররা ত্রুটি-প্রবণ।

protectedভেরিয়েবলগুলি অ-উদ্দেশ্যমূলক আপত্তি (প্রোগ্রামার ভুল) হিসাবে gotoনিজেকে ধার দেয় , ঠিক যেমন বিবৃতি স্প্যাগেটি কোড তৈরিতে toণ দেয়।

protectedক্লাস ভেরিয়েবলগুলি ব্যবহার করে কি বাগ-ফ্রি কোডটি লেখা সম্ভব ? হ্যা অবশ্যই! যেমনটি ব্যবহার করে বাগ-ফ্রি কোড ব্যবহার করা সম্ভব goto; তবে ক্লিচটি "যেহেতু আপনি পারবেন, তার মানে এই নয় যে আপনার করা উচিত!"

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

বেস ক্লাসগুলি থেকে উত্পন্ন ক্লাস সম্পর্কে সম্পূর্ণ জ্ঞান নেই। যতটা বেস ক্লাসের সাথে সম্পর্কিত, protectedআসলে আপনাকে আর কোনও সুরক্ষা দেয় না public, কারণ ডাইরেক্ট ক্লাসটি publicগেটর / সেটার তৈরি করা থেকে বিরত থাকে না যা পিছনের অংশের মতো আচরণ করে।

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

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

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

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

Comments

ডাউনভোটার - এই উত্তর সম্পর্কে কী পরিবর্তন / উন্নত হতে পারে?

— বেন কটরেল

আমি ভোটটি নামি নি, তবে ব্রেক / গোটোর সাথে অ্যাক্সেস স্তরের তুলনা করছি?

— imel96

@ আইমেল ৯6 না, কারণগুলি এড়িয়ে যাওয়ার কারণ তুলনা করে এবং "সেরা অনুশীলন" (বিশেষত নতুন কোড লেখার জন্য ) দ্বারা নিরুৎসাহিত হয়েছেন । অর্থাত্ একটি দক্ষ প্রোগ্রামার publicবাস্তবায়ন বিবরণ এড়াতে পারবেন কারণ এটি নিজেকে অবিশ্বাস্য কোডে ndsণ দেয়। একজন সক্ষম প্রোগ্রামার এড়াতে পারে gotoকারণ এটি নিজেকে অবিশ্বাস্য কোডে ধার দেয়। তবে আসল বিশ্বটি এমন যে কখনও কখনও আপনি উত্তরাধিকারের কোডের ভয়াবহ জগতে হারিয়ে গিয়েছিলেন এবং ব্যবহার ছাড়া উপায় নেই gotoএবং একই কারণে আপনার মাঝে মাঝে পাবলিক / সুরক্ষিত প্রয়োগের বিবরণ ব্যবহার করা ছাড়া কোনও উপায় থাকে না।

— বেন কট্রেল

তীব্রতার চেয়ে তীব্রতা আলাদা, এটি অতুলনীয়। আমি এমন কোডের সাথে বেঁচে থাকতে পারি যেখানে কেবলমাত্র publicবৈশিষ্ট্য / ইন্টারফেস রয়েছে তবে কেবল যে কোড ব্যবহার করে তা নয় goto।

— imel96

@ আইমেল ৯6 আপনি কি কখনও কোডটিতে কাজ করেছেন যা ব্যবহার করে gotoবা এটি আপনি এর মতো নিবন্ধগুলি পড়েছেন বলেই হয়? আমি বুঝতে পারি কেন goto মন্দ কারণ আমি 2 বছর অতিবাহিত করেছি প্রাচীন কোডে কাজ করে যা এটি ব্যবহার করে; এবং আমি কোডগুলিতে আরও দীর্ঘ সময় ব্যয় করেছি যেখানে "ক্লাসগুলি" তাদের প্রয়োগের বিশদ সর্বত্র ফাঁস হয়ে গেছে publicএবং friendস্পেসিফায়ারদের দ্রুত / সহজ / নোংরা হ্যাক হিসাবে ব্যবহার করেছে। আমি এই যুক্তিটি গ্রহণ করি না যে "প্রকাশ্যে প্রয়োগের বিবরণ প্রকাশ্যে প্রকাশ করা" তীব্রতার একই স্তরে কোনও আন্ত-দ্বিযুক্ত স্প্যাগেটি জগাখিচুড়ি সৃষ্টি করতে পারে না কারণ gotoএটি একেবারেই পারে।

— বেন কট্রেল

Answer 6

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

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

উদাহরণ হিসাবে, List<T>.NET ব্যাকিং স্টোরটিকে ব্যক্তিগত করে তোলে; যদি এটি সুরক্ষিত থাকে তবে উদ্ভূত প্রকারগুলি কিছু দরকারী দরকারী কাজ করতে পারে যা অন্যথায় সম্ভব নয়, তবে ভবিষ্যতের সংস্করণগুলি List<T>চিরতরে এর লক্ষণীয় একক ব্যাকিং স্টোর ব্যবহার করতে হবে এমনকি কয়েক মিলিয়ন আইটেমের তালিকা থাকা জন্য। ব্যাকিং স্টোরটিকে ব্যক্তিগত করে তোলা ভবিষ্যতের সংস্করণগুলিকে List<T>উত্পন্ন ক্লাসগুলি না ভেঙে আরও দক্ষ ব্যাকিং স্টোর ব্যবহারের অনুমতি দেয় ।

Answer 7

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

যদি সেই অনুমানটি প্রত্যাখাত হয় তবে কেবল দুটি মামলা বিবেচনা করতে হবে।

1. এটি কেন বাড়ানো যেতে পারে তার জন্য মূল শ্রেণীর লেখকের খুব স্পষ্ট ধারণা ছিল (যেমন এটি একটি বেসফু এবং রাস্তার নিচে বেশ কয়েকটি কংক্রিট ফু বাস্তবায়ন হবে)।

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

2. শিশু শ্রেণির লেখক একটি অভিভাবক শ্রেণিতে কিছু আচরণে হ্যাক করার চেষ্টা করছেন।

এই কেসটি বিরল হওয়া উচিত (আপনি তর্ক করতে পারেন এটি বৈধ নয়) এবং মূল কোড বেসে কেবলমাত্র মূল ক্লাসটি পরিবর্তন করার পক্ষে পছন্দ করা হয় না। এটি খারাপ ডিজাইনের লক্ষণও হতে পারে। এই ক্ষেত্রে আমি আচরণে হ্যাকিং করা ব্যক্তিকে পছন্দ করব কেবলমাত্র অন্য হ্যাক বন্ধুদের (সি / সি ++) এবং setAccessible(true)(জাভা) ব্যবহার করুন।

আমি মনে করি যে এই ধারণাটি প্রত্যাখ্যান করা নিরাপদ।

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

Answer 8

তিনটি অ্যাক্সেস স্তরের তাদের ব্যবহারের ক্ষেত্রে রয়েছে, ওওপিগুলির কোনওটিরই অভাব হবে। সাধারণত আপনি করেন

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

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

Answer 9

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

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

Answer 10

এখানে অনেক ভাল উত্তর, তবে যাইহোক আমি আমার দুটি সেন্ট নিক্ষেপ করব। :-)

বিশ্বব্যাপী ডেটা খারাপ হওয়ায় একই কারণে ব্যক্তিগত ব্যক্তিগত ভাল।

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

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

Answer 11

আমি মনে করি এটি কিছু মতবিরোধ মতামত উল্লেখ করা মূল্যবান।

তত্ত্বের ক্ষেত্রে, অন্যান্য উত্তরে উল্লিখিত সমস্ত কারণে অ্যাক্সেসের স্তর নিয়ন্ত্রণ করা ভাল।

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

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

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

তাহলে কতজন প্রোগ্রামার মনে করেন এটি কোনও ঝামেলা? ঠিক আছে, কয়জন ব্যক্তিগত প্রোগ্রামিং ভাষা ব্যবহার করছেন? অবশ্যই, লোকেরা কেবল সেই ভাষাগুলি ব্যবহার করছে না কারণ তাদের ব্যক্তিগত স্পেসিফার নেই, তবে এটি ভাষাগুলি সহজতর করতে সহায়তা করে এবং সরলতা গুরুত্বপূর্ণ important

ইমো এটি ডায়নামিক / স্ট্যাটিক টাইপিংয়ের সাথে খুব মিল। তত্ত্বের ক্ষেত্রে, স্ট্যাটিক টাইপিং খুব ভাল। অনুশীলনে, এটি কেবল 2% ত্রুটি যেমন গতিশীল টাইপিংয়ের অযৌক্তিক কার্যকারিতা ... রোধ করে । ব্যক্তিগত ব্যবহার সম্ভবত ততোধিক ত্রুটি প্রতিরোধ করে।

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

Comments

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

— ছোট্ট সান্তি

Answer 12

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

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

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

Comments

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

— স্যাম

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

— ফিল লেলো

Answer 13

ব্যক্তিগত পদ্ধতি / ভেরিয়েবলগুলি সাধারণত একটি সাবক্লাস থেকে লুকানো থাকে। এটি একটি ভাল জিনিস হতে পারে।

একটি ব্যক্তিগত পদ্ধতি প্যারামিটারগুলি সম্পর্কে অনুমানগুলি তৈরি করতে পারে এবং কল্যাণদাতা চেক করে কলারের কাছে ছেড়ে যায়।

একটি সুরক্ষিত পদ্ধতিতে চেক ইনপুট পরীক্ষা করা উচিত ।

Answer 14

"ব্যক্তিগত" অর্থ: ক্লাস ব্যতীত অন্য কারও দ্বারা পরিবর্তন বা অ্যাক্সেস করার উদ্দেশ্যে নয় intended সাবক্লাস দ্বারা পরিবর্তন বা অ্যাক্সেস করার উদ্দেশ্যে নয়। উপশ্রেণী? কি সাবক্লাস? আপনার এটি সাবক্লাস করার কথা নয়!

"সুরক্ষিত" এর অর্থ: কেবলমাত্র ক্লাস বা উপশ্রেণী দ্বারা পরিবর্তন বা অ্যাক্সেস করার উদ্দেশ্যে। আপনার সাবক্লাস করার কথা বলে সম্ভবত সম্ভাব্য ছাড়পত্র, অন্যথায় "সুরক্ষিত" এবং "ব্যক্তিগত" নয় কেন?

এখানে একটি স্পষ্ট পার্থক্য আছে। আমি যদি কিছু ব্যক্তিগত করে রাখি তবে আপনি নিজের নোংরা আঙ্গুলগুলি এটি বন্ধ করে রাখবেন বলে মনে করা হচ্ছে। এমনকি আপনি যদি একটি সাবক্লাস হন।

Answer 15

আমি যখন ক্লাসটি সাবক্লাস করি তখন প্রথম জিনিসগুলির মধ্যে একটি হ'ল সুরক্ষিত করার জন্য ব্যক্তিগত গোষ্ঠীগুলির গুচ্ছ পরিবর্তন করা

privateবনাম protected পদ্ধতি সম্পর্কে কিছু যুক্তি :

privateপদ্ধতিগুলি পুনরায় ব্যবহারকে বাধা দেয়। একটি সাবক্লাস ব্যক্তিগত পদ্ধতিতে কোডটি ব্যবহার করতে পারে না এবং এটি আবার প্রয়োগ করতে পারে - বা মূলত ব্যক্তিগত পদ্ধতি ও সি এর উপর নির্ভরশীল পদ্ধতি (গুলি) পুনরায় প্রয়োগ করতে পারে।

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

এটা কি খারাপ জিনিস? - আমি তাই মনে করি না.

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

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

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

এই পদ্ধতিগুলি যৌক্তিকভাবে ওভাররাইড / উন্নত করা যাবে না, যদিও প্রযুক্তিগতভাবে এটি (সংকলক) সুস্পষ্ট করার মতো কিছুই নেই।

প্রসারযোগ্যতা এবং উত্তরাধিকার চান? আপনার পদ্ধতি তৈরি করবেন না private।

আপনার শ্রেণীর নির্দিষ্ট আচরণ পরিবর্তন করা চান না? আপনার পদ্ধতি তৈরি করুন final।

সত্যিই আপনার পদ্ধতিটি কোনও নির্দিষ্ট, সু-সংজ্ঞায়িত প্রসঙ্গের বাইরে কল করা যায় না? আপনার পদ্ধতিটি তৈরি করুন privateএবং / অথবা আপনি কীভাবে অন্য একটি protectedমোড়কের পদ্ধতির মাধ্যমে পুনঃব্যবহারের জন্য প্রয়োজনীয় সু-সংজ্ঞায়িত প্রসঙ্গটি উপলব্ধ করতে পারেন সে সম্পর্কে ভাবেন ।

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

ক্ষেত্রগুলির জন্য, privateসত্যিই খারাপ নয়। যতক্ষণ না ক্ষেত্র (গুলি) যথাযথ পদ্ধতিগুলির মাধ্যমে যুক্তিসঙ্গতভাবে "ব্যবহৃত" হতে পারে (এটি নয় getXX() বা setXX()!)।

Comments

-1 এটি privateবনাম protectedমূল প্রশ্নের সমাধান করে না , ভুল পরামর্শ দেয় (" privateস্পষ্টভাবে ব্যবহার করুন "?) এবং ওও ডিজাইনে সাধারণ sensকমত্যের বিপরীতে যায়। ব্যবহার privateপঙ্কিল কোড গোপন সঙ্গে কিছুই করার আছে।

— আন্দ্রেস এফ।

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

— বেন কট্রেল

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

— বেন কটরেল

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

— জিমিবি

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

— জেডিগোগস

Answer 16

আপনি কি এমন গুরুত্বপূর্ণ ব্যবহারের ক্ষেত্রে জানেন যেখানে সুরক্ষার পরিবর্তে ব্যক্তিগত একটি ভাল সরঞ্জাম, বা ওওপি ভাষাগুলির জন্য দুটি বিকল্প "সুরক্ষিত এবং পাবলিক" যথেষ্ট হবে?

ব্যক্তিগত : যখন আপনার কাছে এমন কিছু রয়েছে যা কোনও সাবক্লাসের জন্য কল বা ওভাররাইড করার জন্য কখনই কার্যকর হবে না।

সুরক্ষিত : যখন আপনার কাছে এমন কিছু থাকে যা একটি সাবক্লাস-নির্দিষ্ট প্রয়োগ / ধ্রুবক থাকে।

একটি উদাহরণ:

public abstract Class MercedesBenz() extends Car {
  //Might be useful for subclasses to know about their customers
  protected Customer customer; 

  /* Each specific model has its own horn. 
     Therefore: protected, so that each subclass might implement it as they wish
  */
  protected abstract void honk();

  /* Taken from the car class. */
  @Override
  public void getTechSupport(){
     showMercedesBenzHQContactDetails(customer);
     automaticallyNotifyLocalDealer(customer);
  }

  /* 
     This isn't specific for any subclass.
     It is also not useful to call this from inside a subclass,
     because local dealers only want to be notified when a 
     customer wants tech support. 
   */
  private void automaticallyNotifyLocalDealer(){
    ...
  }
}

Comments

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

— অ্যাডাম লিবুয়া

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

— অর্ণব দত্ত

Answer 17

এই বিষয়টি বুঝতে আমার পক্ষে কষ্টসাধ্য ছিল, তাই আমি আমার অভিজ্ঞতার একটি অংশ ভাগ করে নিতে চাই:

• কি সুরক্ষিত ক্ষেত্র? এটা আর কিছুই একটি ক্ষেত্র, যে একটি বর্গ বাইরে অ্যাক্সেস করা যাবে না, অর্থাত্ তুলনায় প্রকাশ্যে ভালো: $classInstance->field। এবং যে কৌশলটি এটি "এটি এটি এটি"। আপনার শ্রেণীর বাচ্চাদের এতে সম্পূর্ণ অ্যাক্সেস থাকবে, কারণ এটি তাদের যথাযথ অভ্যন্তরীণ অংশ।
• কি ব্যক্তিগত ক্ষেত্র? এটি আপনার নিজস্ব শ্রেণির জন্য এবং এই শ্রেণীর নিজস্ব বাস্তবায়নের জন্য " সত্যিকারের বেসরকারী " । "বাচ্চাদের নাগালের বাইরে রাখুন" ঠিক যেমন ওষুধের বোতলে। আপনার গ্যারান্টি থাকবে যে এটি আপনার শ্রেণীর 'ডেরিভেটিভস' দ্বারা অকার্যকর, আপনার পদ্ধতিগুলি - যখন ডাকা হয় - ঠিক কী হবে তা ঘোষণা করবে

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

Comments

দুক্ষিত বন্ধুরা! কেবল তাদের জড়ান - আমার উত্তর আপডেট করে =) ধন্যবাদ! আমি তাড়াহুড়ো করেছিলাম এবং ভুল টাইপ করেছি =)

— আলেক্সি ভেসিনিন

আমি মনে করি ওপি দুটি সুরক্ষা স্তরের মধ্যে পার্থক্য সম্পর্কে সচেতন, তবে কেন অন্যটির উপরে অন্যটি ব্যবহার করা উচিত সে সম্পর্কে আগ্রহী।

— স্যাম

@ স্যাম দয়া করে আমার উত্তরটি আরও গভীরভাবে পড়ুন। এগুলি সম্পূর্ণ ভিন্ন ধরণের ক্ষেত্র! শুধুমাত্র জিনিস যা তারা প্রচলিত আছে তারা উভয় প্রকাশ্যে রেফারেন্সড করা যাবে না

— আলেক্সি Vesnin

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

— স্যাম

@ সাম আমার মনে হয় আমি আপনার পয়েন্ট পেয়েছি - আমার বাস্তব অনুশীলন / অভিজ্ঞতা থেকে একটি ব্যবহারিক কেস যুক্ত করেছে। এটা কি আপনার পয়েন্ট হারিয়েছে?

— আলেক্সি ভেসিনিন