ব্যক্তিগত বনাম সুরক্ষিত - দৃশ্যমানতা ভাল-অনুশীলন উদ্বেগ [বন্ধ]

Question

আমি অনুসন্ধান করছি এবং আমি তাত্ত্বিক পার্থক্য জানি।

• সর্বজনীন - যে কোনও শ্রেণি / ফাংশন পদ্ধতি / সম্পত্তি অ্যাক্সেস করতে পারে।
• সুরক্ষিত - কেবলমাত্র এই শ্রেণি এবং যে কোনও উপশ্রেণী পদ্ধতি / সম্পত্তি অ্যাক্সেস করতে পারে।
• ব্যক্তিগত - কেবল এই শ্রেণিটি পদ্ধতি / সম্পত্তি অ্যাক্সেস করতে পারে। এমনকি উত্তরাধিকারসূত্রে প্রাপ্ত হবে না।

এগুলি সব ঠিকঠাক, প্রশ্ন হল তাদের মধ্যে ব্যবহারিক পার্থক্য কী? আপনি কখন ব্যবহার করবেন privateএবং কখন ব্যবহার করবেন protected? এটির চেয়েও কি কোনও মানক বা গ্রহণযোগ্য ভাল অনুশীলন রয়েছে?

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

(দ্রষ্টব্য যে এই প্রশ্নটি আমার জন্য, তবে ভবিষ্যতের রেফারেন্সের জন্যও যেমন আমি এই এসও এর মতো কোনও প্রশ্ন দেখিনি)।

Comments

এটা কোন ব্যাপার? ওওপি সমর্থন সহ যে কোনও ভাষাতেই এই উদ্বেগ রয়েছে। আমি পিএইচপি-তে প্রোগ্রাম করতে পারি, তবে আমি মনে করি যে প্রশ্নটি কোনও ওওপি সমর্থনকারী ভাষার ক্ষেত্রে প্রযোজ্য।

— মাদারার ঘোস্ট

ঠিক আছে মোটামুটি, আপনি ট্যাগ করতে ভুলে গিয়েছিলেন কিনা তা ভেবে অবাক হচ্ছেন। এখন আমি ওওপ ট্যাগটি দেখতে পাচ্ছি।

— পল বেলোরা

আমি শ্রেণীর প্রতিটি সম্পত্তি জন্য দৃশ্যমানতা (ব্যক্তিগত / পাবলিক / সুরক্ষিত) সেট করতে হবে? বা তাদের মধ্যে কেবলমাত্র কিছুটির জন্য ভিজিবিলিটি টাইপ থাকা দরকার? যদি হ্যাঁ, তবে কীভাবে কোন সম্পত্তিটির শ্রেণির শীর্ষে একটি দৃশ্যমানতা স্থাপন করা দরকার তা কীভাবে সিদ্ধান্ত নেবেন?

— ব্যবহারকারী 4271704

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

— আইফেরিয়ান

internalসি # ভাষার আরও একটি অ্যাক্সেস স্পেসিফায়ার রয়েছে যা কোনও শ্রেণীর অ্যাক্সেস স্তর বা শারীরিক সমাবেশে এর সদস্যদের সীমাবদ্ধ করে। যদিও, আমি এর সমর্থন বা অন্যান্য ভাষায় অনুরূপ কিছু সম্পর্কে নিশ্চিত নই।

— আরবিটি

Answer 1

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

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

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

Comments

এখানে আসল প্রশ্নটি privateবনাম সম্পর্কে protectedআমি কখন একটি সম্পত্তি উত্তরাধিকার সূত্রে পেতে চাই এবং কখন করব না? ভবিষ্যতে কোনও ব্যবহারকারী কখনও কখনও আমার ক্লাস নিতে এবং এটি বাড়িয়ে দিতে চায় কিনা তা আমি সত্যিই বলতে পারি না ...

— মাদারার ঘোস্ট

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

— থারস্টন ডিটমার

সুরক্ষিত ক্ষেত্রগুলি উত্তরাধিকারের খারাপ অভ্যাস! । দয়া করে এটি থেকে সাবধান থাকুন। এখানে কেন

— আরবিটি

উত্তরাধিকার হিসাবে ব্যক্তিগত ক্ষেত্রগুলি অনুশীলনে খারাপ !. (অতিরিক্ত বাড়াবাড়ি করে) দয়া করে আমার উত্তরটি পড়ুন।

— ল্যারি

সাধারণ নিয়ন্ত্রণ-অদ্ভুত মতামত।

— ব্রুনো desthuilliers

Answer 2

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

পুরানো জ্ঞান

"আপনার ব্যক্তিগত না করার উপযুক্ত কারণ না থাকলে এটিকে ব্যক্তিগত হিসাবে চিহ্নিত করুন"

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

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

তুমি কি কখনো:

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

ডিফল্টরূপে ব্যক্তিগত চিহ্নিতকরণের পদ্ধতিগুলির জন্য আমি এই তিনটি বৃহত্তম যৌক্তিকতা শুনেছি:

যুক্তিযুক্তকরণ # 1: এটি অনিরাপদ এবং একটি নির্দিষ্ট পদ্ধতি ওভাররাইড করার কোনও কারণ নেই

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

ডিফল্টরূপে সুরক্ষিত পদ্ধতি চিহ্নিত করা আধুনিক এসডাব্লু বিকাশের অন্যতম প্রধান সমস্যার হ্রাস: কল্পনাশক্তি ব্যর্থ।

যুক্তিযুক্তকরণ # 2: এটি সর্বজনীন এপিআই / জাভাদোকসকে পরিষ্কার রাখে

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

যুক্তিযুক্তকরণ # 3: আমার সফ্টওয়্যারটি বাণিজ্যিক এবং আমার এটির ব্যবহার সীমাবদ্ধ করতে হবে।

এটিও যুক্তিসঙ্গত, তবে একজন গ্রাহক হিসাবে আমি প্রতিবারে কম প্রতিরোধী প্রতিযোগী (কোনও উল্লেখযোগ্য মানের পার্থক্য বিদ্যমান না ধরে) নিয়ে যাব।

কখনও না বল না

আমি বলছি না কখনই পদ্ধতিগুলিকে ব্যক্তিগত হিসাবে চিহ্নিত করো না। আমি বলছি থাম্বের সর্বোত্তম নিয়ম হ'ল "যদি না করার কোনও ভাল কারণ না থাকে তবে পদ্ধতিগুলিকে সুরক্ষিত করা"।

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

Comments

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

— RBT

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

— নিক

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

— shinkou

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

— রন ডান

Answer 3

ব্যক্তিগত ক্ষেত্রগুলিতে গালি দেওয়া বন্ধ করুন !!!

এখানে মন্তব্যগুলি ব্যক্তিগত ক্ষেত্রগুলি ব্যবহারের ক্ষেত্রে অপ্রতিরোধ্যভাবে সহায়ক বলে মনে হচ্ছে। ঠিক আছে, তাহলে আমার বলতে কিছু আলাদা আছে।

নীতিগতভাবে ব্যক্তিগত ক্ষেত্রগুলি কি ভাল? হ্যাঁ. তবে আপনি যে নিশ্চিতরূপে ভুল তা নিশ্চিত নন যখন বলা হচ্ছে যে একটি সোনালি নিয়ম সমস্ত কিছু ব্যক্তিগত করে দেওয়া হয় ! আপনি কোনওটিতে প্রবেশ না করা পর্যন্ত আপনি সমস্যাটি দেখতে পাবেন না। আমার মতে, আপনি নিশ্চিত না হলে আপনার ক্ষেত্রগুলি সুরক্ষিত হিসাবে চিহ্নিত করা উচিত ।

আপনি একটি শ্রেণি প্রসারিত করতে চান এমন দুটি মামলা রয়েছে:

• আপনি একটি বেস শ্রেণিতে অতিরিক্ত কার্যকারিতা যুক্ত করতে চান
• আপনি বর্তমান প্যাকেজের বাইরে বিদ্যমান ক্লাসটি সংশোধন করতে চান (কিছু লাইব্রেরিতে সম্ভবত)

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

একটি সাধারণ লাইব্রেরি বিবেচনা করুন যা গাড়িগুলির মডেল করে:

class Car {
    private screw;
    public assembleCar() {
       screw.install();
    };
    private putScrewsTogether() {
       ...
    };
}

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

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

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

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

আমি নিকের উত্তরটিকে অনেক সমর্থন করি।

Comments

ব্যক্তিগত ক্ষেত্রগুলি ব্যবহার করে বেশিরভাগই বলা হয় যে কোনও শ্রেণি / অবজেক্টের (যদি সচেতনভাবে ব্যবহার করা হয়) নির্দিষ্ট আচরণের পরিবর্তন করার জন্য উত্তরাধিকার হ'ল ভুল বিমূর্তি। পরিবর্তন এপিআই পরিবর্তন না করে আচরণ পরিবর্তিত হওয়ায় সাধারণত নীরবে নিঃশব্দে LSP লঙ্ঘন করে। দুর্দান্ত উত্তর, +1।

— মাদারার ঘোস্ট

প্রচার! মাইনক্রাফ্ট মোডগুলি লেখার চেষ্টা করার সময় প্রাইভেট হ'ল আমার অস্তিত্ব ane এটি ঠিক করতে রিফ্লেকশন বা এএসএম ব্যবহার করা ছাড়া আর বিরক্তিকর কিছুই নয়।

— পুনরাবৃত্তি এক্সেপশন এক্সেপশন

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

— sean662

Answer 4

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

1. সমস্ত ক্লাস চূড়ান্ত করুন যতক্ষণ না আপনার এখনই সাবক্লাসের প্রয়োজন to
2. আপনার যদি অবিলম্বে সাবক্লাস এবং ওভাররাইড করার প্রয়োজন না হয় সমস্ত পদ্ধতি চূড়ান্ত করুন।
3. সমস্ত পদ্ধতির প্যারামিটারগুলি চূড়ান্ত করুন যতক্ষণ না আপনার যদি পদ্ধতিটির মূল অংশের মধ্যে সেগুলি পরিবর্তন করতে হয় তবে এটি বেশিরভাগ সময়ই বিশ্রী।

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

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

দাবি অস্বীকার: আমি জাভায় তেমন প্রোগ্রাম করি না :)

Comments

স্পষ্ট করার জন্য: final classজাভাতে এ একটি শ্রেণি যা উত্তরাধিকার সূত্রে প্রাপ্ত হতে পারে না। একটি final methodঅ ভার্চুয়াল, একটি উপশ্রেণী দ্বারা অর্থাত overridable না (জাভা পদ্ধতি ডিফল্টরূপে ভার্চুয়াল হয়) হয়। এ final field/parameter/variableহ'ল এক অপরিবর্তনীয় পরিবর্তনশীল রেফারেন্স (এই অর্থে যে এটি শুরু করার পরে এটি পরিবর্তন করা যায় না)।

— এম স্ট্রামম

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

— গর্ডনএম

আপনি কি আপনার প্রোগ্রামিং ক্যারিয়ারের এমন একটি মামলার নাম রাখতে পারেন যেখানে কোনও পদ্ধতি প্যারামিটার "ফাইনাল" চিহ্নিত করে আপনার বোঝার ক্ষেত্রে পার্থক্য রয়েছে? (সংকলক দ্বারা প্রয়োজন ছাড়া অন্য)

— user949300

Answer 5

আপনি কখন ব্যবহার করবেন privateএবং কখন ব্যবহার করবেন protected?

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

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

Comments

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

— shawnhcorey

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

— আরবিটি

Answer 6

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